20.2.2012 15:51, spam.spam.spam.spam@xxxxxxx kirjoitti:
This is the result of these commands on the computer where there are problems : /usr/lib/gcc/i686-linux-gnu/4.6.1/collect2 --build-id --no-add-needed
> --as-needed --eh-frame-hdr -m elf_i386 --hash-style=gnu > -dynamic-linker /lib/ld-linux.so.2 -z relro -o xmlparsefile > /usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/crt1.o > /usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/crti.o > /usr/lib/gcc/i686-linux-gnu/4.6.1/crtbegin.o > -L/auto/pierre/software/libxml2-2.7.8/lib > -L/usr/lib/gcc/i686-linux-gnu/4.6.1 > -L/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu > -L/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../lib > -L/lib/i386-linux-gnu -L/lib/../lib -L/usr/lib/i386-linux-gnu > -L/usr/lib/../lib -L. -L/usr/lib/gcc/i686-linux-gnu/4.6.1/./../.. > -lxml2 -lm xmlparsefile-main.o The linking order in the last row is wrong, the order should be : xmlparsefile-main.o -lxml2 -lm because the self-compiled object may need to solve symbols from 'libxml2' and 'libm'. This is the problem / result from something.
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
> -lgcc_s --no-as-needed > /usr/lib/gcc/i686-linux-gnu/4.6.1/crtend.o > /usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/crtn.o
xmlparsefile-main.o: In function `parseDoc': main.c:(.text+0xd): undefined reference to `xmlParseFile' main.c:(.text+0x51): undefined reference to `xmlCleanupParser' main.c:(.text+0x63): undefined reference to `xmlFreeDoc' main.c:(.text+0x68): undefined reference to `xmlCleanupParser' collect2: ld returned 1 exit status
What can you see intresting to resolve my problem?
As I can see it, your compile & link command originally has : -L/.../software/libxml2-2.7.8/lib -lxml2 -lm Then 'gcc' splits this, putting the other '-L' arguments before the '-lxml2 -lm', but not the object name, then gives the full command to 'collect2'. It would be interesting to see whether the 'gcc' on the other really gives the arguments in the same order to 'collect2'. What I think defining these things is the 'specs' file. The not working 'gcc' tells "Using built-in specs.". Maybe the other 'gcc' uses a bug-fixed 'specs', ie a patched GCC? This was only my guess but in any case it is the GCC driver, 'gcc', which gives the arguments / parameters to the subprocesses...
