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 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 with the result of gcc
>> 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
> /usr/lib/gcc/i586-suse-linux/4.3/../../../
> and i do not have gcc installed at target box (atest). i also double
> checked if there could be "" file in whole rootfs which is abt
> 258M long and i did not found it.
> also /usr/lib/gcc/i586-suse-linux/4.3/../../../
> ie /usr/lib/ is just a linker script of 238 bytes.
> are binary same on these two boxes too.

What are the contents of this linker script? I did not ask to compare
gcc with the same file on the target. I asked
to compare:
gcc (or if it is a linker script, the
it references)
with  /lib/

In other words: the libc used by the compiler with the libc used at
run-time, as my very first answer was asking.


Xenomai-core mailing list

Reply via email to