Krzysztof Błaszkowski wrote: > On Tue, 2010-08-17 at 15:06 +0200, Gilles Chanteperdrix wrote: >> Krzysztof Błaszkowski wrote: >>> On Tue, 2010-08-17 at 14:40 +0200, Gilles Chanteperdrix wrote: >>>> No. As witnessed by the message: >>>> ./xeno-shmem-fork: relocation error: ./xeno-shmem-fork: symbol getpid, >>>> version GLIBC_2.0 not defined in file libc.so.6 with link time reference >>> >>> have you seen that main process started ? and linker didn't complain >>> about wrong symbol version. This happened only in child process after >>> line 88, have you seen output from line 89 ? >>> >>> furthermore you can find commented out line in makefile which compiles >>> userland without linking with xenomai libraries. >>> >>> this executable works as expected. >> As I said since we went from libc5 to libc6, all libcs have been >> backward ABI compatible. So, it makes perfect sense that the binary works. >> >> Since you are calling getpid() after fork, it is normal that the error >> is not signalled before, symbols are only resolved at run-time, when >> they are use. > > indeed so i think you should ask yourself how it was possible that main > process could resolve it but child couldn't.
That is easy to answer: only the child calls getpid(). > >>> these libcs are same and i wonder whats wrong with you. >>> How many times do i need to make you sure that these libcs are binary >>> same ? >> As long as you are comparing the wrong binaries. What I ask you to >> compare is libc.so.6 with the result of gcc -print-file-name=libc.so >> gcc being the exact compiler use for compilation of the test program. >> >> If these libraries are the same, then I will look at your test program, >> otherwise I will not waste more time on this issue. > > so at the box i compile code gcc gives: > CHroot linux-e9um:/lib # gcc -print-file-name=libc.so > /usr/lib/gcc/i586-suse-linux/4.3/../../../libc.so > > > and i do not have gcc installed at target box (atest). i also double > checked if there could be "libc.so" file in whole rootfs which is abt > 258M long and i did not found it. > > also /usr/lib/gcc/i586-suse-linux/4.3/../../../libc.so > ie /usr/lib/libc.so is just a linker script of 238 bytes. > > ld-linux.so.2 are binary same on these two boxes too. What are the contents of this linker script? I did not ask to compare gcc -print-file-name=libc.so with the same file on the target. I asked to compare: gcc -print-file-name=libc.so (or if it is a linker script, the libc.so.6 it references) with /lib/libc.so.6 In other words: the libc used by the compiler with the libc used at run-time, as my very first answer was asking. -- Gilles. _______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core