[Bug 770623] netclock-replay tool breaks cross compile

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770623

--- Comment #16 from Alistair Buxton <a.j.buxton at gmail.com> ---
I now fully understand the cause of this problem. It is a well known problem
with libtool, which does not properly resolve indirect linkage when using a
sysroot. It isn't even related to cross compiling, as even a native build will
fail if the sysroot is not "/".

The problem can be more easily demonstrated with simple gcc commands:

1. Build a shared library:
arm-linux-gnueabihf-gcc -fPIC -c libfoo.c
arm-linux-gnueabihf-gcc libfoo.o -shared -o libfoo.so

2. Build another shared library which links to the first one: 
arm-linux-gnueabihf-gcc -fPIC -c libbar.c
arm-linux-gnueabihf-gcc libbar.o libfoo.so -shared -o libbar.so

3. Build an exe which links to the second shared library:
arm-linux-gnueabihf-gcc -c exe.c
arm-linux-gnueabihf-gcc -o exe exe.o libbar.so

When libtool does these steps it sets an rpath inside the second shared library
which points to the first shared library in the build dir. Then when you
install the library into the prefix, libtool relinks it, adjusting the rpath.

The problem comes when ld sees the rpath on the uninstalled library while
linking exe. It prepends the sysroot onto it. This would be correct behaviour
for a library linked to something installed into the sysroot, but if rpath
refers to the build directory then it will break. Unfortunately there is no way
that ld can know what to do unless libtool tells it, which it does not.


As for a workaround: LDFLAGS="-Wl,--unresolved-symbols=ignore-in-shared-libs"
will prevent ld from trying to recursively resolve the shared object links. I
don't know if it has any side effects though, such as potentially making
configure tests pass when they should fail.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.