Hi,



I am building GCC-4.4.2 ( open embedded recipe using bitbake version-1.8 ) for an x86 based system.

The configure options are as under:



"--enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap"


It builds successfully after some minor changes and libstdc++.so.6.0.13 library is getting created.



My aim is to run Citrix receiver on an x86 based target. For this, I run storebrowse as follows:



./usr/lib/ICAClient/storebrowse



But I get the following errors:



./storebrowse: /usr/lib/libxml2.so.2: no version information available (required by ./storebrowse)
./storebrowse: relocation error: ./storebrowse: symbol _ZTISt15basic_streambufIwSt11char_traitsIwEE, version

GLIBCXX_3.4 not defined in file libstdc++.so.6 with link time reference.



libxml2 error can be resolved by deleting and creating a new symbolic link to libxml, but, I am unable to resolve the symbol error (_ZTISt15basic_streambufIwSt11char_traitsIwEE). I am compiling using default gcc_4.4.2.bb recipe.

Do I need to make any changes in configure options..? Or is there anything else that needs to be changed..? Please help me in this regard.


Thanks,
Sam

The configure line doesn't look quite right.
? Why would you "--disable-bootstrap" ?


As a once configured gcc cannot be reused, suggest :
Start from scratch with :
$ tar xvf gcc-4.4.2.tar.bz2
$ mkdir build-gcc442
$ cd build-gcc442/
$ ../gcc-4.4.2/configure --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib

This is a minimum configure line for a working gcc / g++.
If you have another gcc on the target, you will also have to add like:
--prefix=/usr/gcc442 --program-suffix=44

-

???? obviously the troll is this ...

./storebrowse: /usr/lib/libxml2.so.2: no version information available (required by ./storebrowse)

find out why. if one does this

$ nm /usr/lib/libxml2.so.2

you'd likely get that error on the cmdline since usu. libxml2 wont have symbols unless you compiled it with gcc default options (default is not strip(1)ped)

so install libxml2 proper and go on to see what next error message is

> libxml2 error can be resolved by deleting and creating a new symbolic link to libxml

no, no way. who told you deleting and creating symbolic links changes anything ? that's just not so. perhaps you changed a timestamp. but during make(1) that's illegal to do. you have to completely rebuild after foo'ing timestamps to be safe.

> GLIBCXX_3.4 not defined in file libstdc++.so.6 with link time reference

your right to think you need a newer glibc (++) for ld(1) ld.so to load. there are C functions in the .so which the software is missing and 3.4 has - your not going anywhere with missing C functions of course.

** iff its libxml2 that wants GLIBC-3.4 you might use an older libxml2 which doesnt - only catch is your software may require newest libxml2 (ughgh). on the other hand who prepared your libxml2 ? it may be and older libxml2 which "needs" glibc-3.4 because it was compiled with new gcc.

whatever your doing: new things you compile with new-gcc may require new-glibc. dont install them yet and dont let your PATH use them until your done compiling. you have to chroot(1) or "log in" to a / with /lib that has new libc and works before attempting to run (some coreutils, some libs, whatever your building)

_ZTISt15basic_streambufIwSt11char_traitsIwEE

is non gnu, is non linux, is non gcc

whoever bitbake is - the instructions are incomplete and possibly the process as a whole has never worked for end users a 1st time: that is your problem

i often find "compiling" advice for major works that have major / critical things missing (ie, gsrc to compile gnu wares is:

* missing: --with-gnu-ld for building coreutils

i know these people never used gsrc a 1st time without that option for anything gnu: default is OFF and using gnu or about any linux distro: use of gnu-ld is quite necessary and expected (ie, your not HPUX using gnu with .so loaded by proprietary ld)

point: i see that continually one after another. even on "linux from scratch". people that say they did things in linux that absolutely could not have been done.

http://www.linuxquestions.org/questi...-error-783012/

likely when you get your "tool chain" in order and build options right

_ZTISt15basic_streambufIwSt11char_traitsIwEE dissapears without effort

but your likely to find a few or 100 things they didn't tell you first