undefined reference to '__ctype_b'

[Altera_Forum]

hi, 

 Has any body ever encountered the problem of "undefined reference to __ctype_b" when linking with NIOS IDE before?  I got the following error while linking using nios-elf g++  Note: the reason why it's reporting __ctype_b_loc instead of __ctype_b is because I went into Microtronix uCLinux include directory, and changed all ctype_b to ctype_b_loc in ctype.h as suggested by this: http://www.molpro.net/molpro-user/archive/all/msg01417.html (http://www.molpro.net/molpro-user/archive/all/msg01417.html)  I also tried using a bigger libc.a as well (which was not in microtronix uCLibc directory), but it didnt help.   Any help would be greatly appreciated! Thanks!  ERROR MESSAGE: Unable to reach __ctype_b_loc (at 0x00000000) from the global pointer (at 0x000a95e0) because the offset (-693728) is out of the allowed range, -32678 to 32767.[Debug/libAutoClip.a(clp_obj.o)(.text+0xa4):../../../../C_RT/Source/clp_obj.c]  undefined reference to `__ctype_b_loc'[../../../../C_RT/Source/clp_obj.c]  *169: undefined reference to `__ctype_b_loc' ../../../../C_RT/Source/clp_obj.c:169: Unable to reach __ctype_b_loc (at 0x00000000) from the global pointer (at 0x000a95e0) because the offset (-693728) is out of the allowed range, -32678 to 32767. libAutoClip.a  FROM CONSOLE: nios2-elf-g++ -nostdinc -D__linux__ -O0 -g -I"c:/altera/kits/nios2_51/bin/eclipse/plugins/com.microtronix.nios2linux.uClibc_1.4.0"/include -I/cygdrive/c/altera/kits/nios2_51/bin/nios2-gnutools/H-i686-pc-cygwin/bin/../lib/gcc/nios2-elf/3.4.1/include -fno-optimize-sibling-calls -mhw-mul -mhw-mulx -I Connective_Logic_Systems/CLIP/BSP/Posix/Include -I Connective_Logic_Systems/CLIP/C_RT/Include -I Connective_Logic_Systems/CLIP/CPP_RT/Include -I Connective_Logic_Systems/CLIP/Operating_System/Posix/Include -I Connective_Logic_Systems/CLIP/Protocol/TCP_for_Posix/Include -I FFTW/fftw/Include -I PROSAS_Source/DataClasses/Include -I PROSAS_Source/Harnesses/Include -I PROSAS_Source/Infrastructure/Circuits/Include -I PROSAS_Source/Infrastructure/CxnPrototypes/Include -I PROSAS_Source/InputOutput/Devices/Include -I PROSAS_Source/Interfaces/Include/ -I PROSAS_Source/Processing/Include/ -I PROSAS_Source/ProjectHeaders/Include -I PROSAS_Source/Topics/ClpConfigDev -I PROSAS_Source/Topics/ClpList -D_DEBUG -c PROSAS_Source/InputOutput/Devices/Source/WatchDogDev.cpp -o Debug/WatchDogDev.o  nios2-elf-g++ Debug/ProcAFEstData.o Debug/ProcAzFftData.o Debug/ProcAzIFftData.o Debug/ProcAzMocompData.o Debug/ProcData.o Debug/ProcInputData.o Debug/ProcOutputData.o Debug/ProcRgMocompData.o Debug/ProcRmaData.o Debug/ProcRpAdjData.o Debug/ProcTRData.o Debug/ProSASData.o Debug/ProcAFEstAdjCellMthd.o Debug/ProcAFEstAFLineMthd.o Debug/ProcAFEstCellProcessMthd.o Debug/ProcAFEstFFTMthd.o Debug/ProcAFEstIFFTMthd.o Debug/ProcAFEstPointMthd.o Debug/ProcAFEstRMAMthd.o Debug/ProcAFEstSetupMthd.o Debug/ProcAzFftAzFftMthd.o Debug/ProcAzFftCopyBackMthd.o Debug/ProcAzFftSetupMthd.o Debug/ProcAzIFftAzIFftMthd.o Debug/ProcAzIFftCopyBackMthd.o Debug/ProcAzIFftSetupMthd.o Debug/ProcAzMocompAzMocompMthd.o Debug/ProcAzMocompCopyBackMthd.o Debug/ProcAzMocompSetupMthd.o Debug/ProcInputFepRxThrd.o Debug/ProcInputReadThrd.o Debug/ProcOutputWriteThrd.o Debug/ProcRgMocompCopyBackMthd.o Debug/ProcRgMocompRgMocompMthd.o Debug/ProcRgMocompSetupMthd.o Debug/ProcRmaCopyBackMthd.o Debug/ProcRmaRmaMthd.o Debug/ProcRmaSetupMthd.o Debug/ProcRpAdjcopyBackMthd.o Debug/ProcRpAdjRpAdjMthd.o Debug/ProcRpAdjSetupMthd.o Debug/ProcTRTRMthd.o Debug/ProcAFEstCct.o Debug/ProcAzFftCct.o Debug/ProcAzIFftCct.o Debug/ProcAzMocompCct.o Debug/ProcCct.o Debug/ProcInputCct.o Debug/ProcOutputCct.o Debug/ProcRgMocompCct.o Debug/ProcRmaCct.o Debug/ProcRpAdjCct.o Debug/ProcTRCct.o Debug/ProcAFEstCpt.o Debug/ProcAzFftCpt.o Debug/ProcAzIFftCpt.o Debug/ProcAzMocompCpt.o Debug/ProcCpt.o Debug/ProcInputcpt.o Debug/ProcOutputCpt.o Debug/ProcRgMocompCpt.o Debug/ProcRmaCpt.o Debug/ProcRpAdjCpt.o Debug/ProcTRCpt.o Debug/BittwareAPI.o Debug/dspDev.o Debug/GenDspDev.o Debug/LedDev.o Debug/ProSAS.o Debug/WatchDogDev.o -o Debug/MISER_SCH.exe Debug/libAutoClip.a Debug/libClip_pp.a Debug/libClip_PP_Process.a Debug/libAutoClip.a(clp_obj.o)(.text+0xa4): In function `obj_init': ../../../../C_RT/Source/clp_obj.c:169: undefined reference to `__ctype_b_loc' Debug/libAutoClip.a(clp_obj.o)(.text+0xa4):../../../../C_RT/Source/clp_obj.c:169: Unable to reach __ctype_b_loc (at 0x00000000) from the global pointer (at 0x000a95e0) because the offset (-693728) is out of the allowed range, -32678 to 32767.

[Altera_Forum]

Maybe the problem is not linked to the LibC, but to the application having too much small data, because the first error message is "Unable to reach __ctype_b_loc (at 0x00000000) from the global pointer"... 

 Try with a dummy application without too much data... does it works? If yes, that's probably the reason...  Paolo

[Altera_Forum]

Hi Paolo, 

 It does work when I link to a dummy application. However, is there a way to increase the size though for global pointer though? Because we tried compiling and linking the same project under Fedora Core 4 with the gcc version 3.4.1, and it linked in just fine.  Thus, we suspect this is a NIOS-II-specific problem?  What does everybody think?  Thanks!  Shivesh   --- Quote Start ---  originally posted by paolo.gai@Jan 13 2006, 04:06 AM maybe the problem is not linked to the libc, but to the application having too much small data, because the first error message is "unable to reach __ctype_b_loc (at 0x00000000) from the global pointer"...  try with a dummy application without too much data... does it works? if yes, that&#39;s probably the reason...  paolo <div align='right'><{post_snapback}> (index.php?act=findpost&pid=12171)  --- quote end ---    --- Quote End ---  

[Altera_Forum]

--- Quote Start ---  originally posted by shachris23@Jan 14 2006, 03:37 AM it does work when i link to a dummy application. however, is there a way to increase the size though for global pointer though? because we tried compiling and linking the same project under fedora core 4 with the gcc version 3.4.1, and it linked in just fine.  thus, we suspect this is a nios-ii-specific problem?  what does everybody think? <div align='right'><{post_snapback}> (index.php?act=findpost&pid=12190)  --- quote end ---    --- Quote End ---    Yes, because the Nios compiler uses a register to speedup data access. In general you cannot increase the amount of GP-relative memory, but there are two ways:  You can either  - compile using the -G0 option  or,  - put your small data (global ints, global chars, ...) inside a struct, or allocate them in another section...  you can try something like  int foo __attribute__ ((section (".data"))) = 57; int bar __attribute__ ((section (".bss"))); // initialized to 0  the section attribute must stay both in the declaration and on the definition of the variables.  There is also a section about that in the ERIKA Enterprise manual, section 4.8.4, available for free at the evidence literature page (http://www.evidence.eu.com/nios2/literature.asp)  bye  Paolo

[Altera_Forum]

http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif Hi Paolo and everybody, 

 The problem is solved. The error happened because of the link flags that I passed when the program was linking.  At first, I didn&#39;t strictly follow Microtronix&#39;s linking flags, and just used  $(CC) -o <program> $(MYLIBS) $(LDLIBS)  And when I changed to  $(CC) $(LDFLAGS) -o <program> -lpthread $(MYLIBS) $(LDLIBS)  Voila, the program links with no problem.  So I guess the lesson learned is if it aint broke, dont mess with it.  But thanks Paolo so much for your detailed response. I sure learned new things, and I will try it next time I encountered problems like this again. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif     --- Quote Start ---  originally posted by paolo.gai+jan 14 2006, 03:21 am--><div class='quotetop'>quote (paolo.gai @ jan 14 2006, 03:21 am)</div>  --- quote start ---  <!--quotebegin-shachris23@Jan 14 2006, 03:37 AM it does work when i link to a dummy application. however, is there a way to increase the size though for global pointer though? because we tried compiling and linking the same project under fedora core 4 with the gcc version 3.4.1, and it linked in just fine.  thus, we suspect this is a nios-ii-specific problem?  what does everybody think? <div align='right'><{post_snapback}> (index.php?act=findpost&pid=12190)  --- quote end ---    --- Quote End ---    Yes, because the Nios compiler uses a register to speedup data access. In general you cannot increase the amount of GP-relative memory, but there are two ways:  You can either  - compile using the -G0 option  or,  - put your small data (global ints, global chars, ...) inside a struct, or allocate them in another section...  you can try something like  int foo __attribute__ ((section (".data"))) = 57; int bar __attribute__ ((section (".bss"))); // initialized to 0  the section attribute must stay both in the declaration and on the definition of the variables.  There is also a section about that in the ERIKA Enterprise manual, section 4.8.4, available for free at the evidence literature page (http://www.evidence.eu.com/nios2/literature.asp)  bye  Paolo <div align='right'><{post_snapback}> (index.php?act=findpost&pid=12193)</div> [/b]  --- Quote End ---  

[Altera_Forum]

Sorry. To be more accurate: g++ under Windows or Linux? I knowed that g++ didn&#39;t work under Linux. Right? 

   --- Quote Start ---  originally posted by shachris23@Jan 17 2006, 01:16 AM http://forum.niosforum.com/work2/style_emoticons/<#emo_dir#>/smile.gif hi paolo and everybody,  the problem is solved. the error happened because of the link flags that i passed when the program was linking.  at first, i didn&#39;t strictly follow microtronix&#39;s linking flags, and just used  $(cc) -o <program> $(mylibs) $(ldlibs)  and when i changed to  $(cc) $(ldflags) -o <program> -lpthread $(mylibs) $(ldlibs)  voila, the program links with no problem.  so i guess the lesson learned is if it aint broke, dont mess with it.  but thanks paolo so much for your detailed response. i sure learned new things, and i will try it next time i encountered problems like this again.  http://forum.niosforum.com/work2/style_emoticons/<#emo_dir#>/smile.gif     --- quote start ---  originally posted by paolo.gai+jan 14 2006, 03:21 am--><div class='quotetop'>quote (paolo.gai @ jan 14 2006, 03:21 am)  --- quote end ---    --- quote start ---  <!--quotebegin-shachris23@jan 14 2006, 03:37 am It does work when I link to a dummy application. However, is there a way to increase the size though for global pointer though? Because we tried compiling and linking the same project under Fedora Core 4 with the gcc version 3.4.1, and it linked in just fine.  Thus, we suspect this is a NIOS-II-specific problem?  What does everybody think? <div align='right'><{post_snapback}> (index.php?act=findpost&pid=12190)  --- Quote End ---  [/b]  --- Quote End ---    Yes, because the Nios compiler uses a register to speedup data access. In general you cannot increase the amount of GP-relative memory, but there are two ways:  You can either  - compile using the -G0 option  or,  - put your small data (global ints, global chars, ...) inside a struct, or allocate them in another section...  you can try something like  int foo __attribute__ ((section (".data"))) = 57; int bar __attribute__ ((section (".bss"))); // initialized to 0  the section attribute must stay both in the declaration and on the definition of the variables.  There is also a section about that in the ERIKA Enterprise manual, section 4.8.4, available for free at the evidence literature page (http://www.evidence.eu.com/nios2/literature.asp)  bye  Paolo <div align='right'><{post_snapback}> (index.php?act=findpost&pid=12193)</div> [/b]  --- Quote End ---   <div align='right'><{post_snapback}> (index.php?act=findpost&pid=12228)</div> [/b]  --- Quote End ---