On Tue, 2010-08-17 at 15:27 +0200, Gilles Chanteperdrix wrote:
> 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().

;) not only. see the short code.

> 
> > 
> >>> 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.
> 

/usr/lib/libc.so can't be compared with /lib/libc.so.6.

i included libc.so from /usr for reference.






-- 
Krzysztof Blaszkowski

Attachment: libc.so
Description: application/sharedlib

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to