Re: The order of arguments differs

20.2.2012 15:51, [EMAIL PROTECTED] 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...