Re: [Xenomai-core] xenomai 2.5.3/native, kernel 2.6.31.8 and fork()

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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.