On 06/27/2017 08:56 PM, Stefan Husmann wrote:
Hello,
I have put gcc63 to AUR, merely to have a working gcj implemetation,
Wait, isn't there already a gcc6 package in the AUR?
something is wrong with it. If I compile anything with it, ldd shows that the resulting binaries have wrong symbols. For instance,
ldd ~/paketierung/meine_Pakete/fotoxx/pkg/fotoxx/usr/bin/fotoxx |grep -v usr linux-vdso.so.1 (0x00007ffcbe5cf000) libstdc++.so.6 => /lib/gcc/x86_64-pc-linux-gnu/6.3.1/libstdc++.so.6 (0x00007fd4fb0e7000) libgcc_s.so.1 => /lib/gcc/x86_64-pc-linux-gnu/6.3.1/libgcc_s.so.1 (0x00007fd4fabbe000) /lib64/ld-linux-x86-64.so.2 (0x00007fd4fe8d6000)
IMHO it should be libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/libstdc++.so.6
What am I doing wrong? I do not know how to fix this.
How does the resulting binary have "wrong symbols" as a result of where the linux dynamic linker resolves a soname without a path to? Also are you aware that on Linux, "/lib" is a symbolic link to "usr/lib" and therefore your preferred result resolves to the same filename? Also, gcc 7 was released to [core] a month ago. A better question would be, why is the linker looking in /usr/lib/gcc/$CHOST/$gccver/ instead of /usr/lib? And, do you have some sort of actual issue whereby any of this would be relevant? And, I think you are lying about the command you ran, not that it really matters as the command wouldn't show anything interesting anyway. Namely, I think you prefixed it with LD_LIBRARY_PATH="$blah"
fotoxx is written in c++, but this happens also for programs compiled with gcc or gcj. The pdftk PKGBUILD especially suffers from this, as you can see in the AUR comments.
The pdftk PKGBUILD and others suffer from being run with a custom LD_LIBRARY_PATH and therefore having the dynamic loader match sonames to non-default shared library filenames? Or something else? -- Eli Schwartz