[aur-general] Gcc-6.3: ldd shows wrong symbols
Hello, I have put gcc63 to AUR, merely to have a working gcj implemetation, but 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. 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. Help is much appreciated. Best Regards Stefan
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
Eli Schwartz via aur-general <aur-general@archlinux.org> writes:
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?
It is newer than mine.
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? Yes, I am aware of that.
Also, gcc 7 was released to [core] a month ago. It does not come with gcj anymore, they dropped it.
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?
Running pdftk without having LD_LIBRRY_PATH set to $LD_LIBRARY_PATH:/lib/gcc/x86_64-pc-linux-gnu/6.3.1/ results in pdftk: error while loading shared libraries: libgcj.so.17: cannot open shared object file: No such file or directory
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?
see above
-- Eli Schwartz
On 28-06-17 02:56, Stefan Husmann wrote:
Hello,
I have put gcc63 to AUR, merely to have a working gcj implemetation, but 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.
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.
Help is much appreciated.
Best Regards
Stefan
Stefan, for clarity : you did use gcc 6.3.1-6 as starting template ? https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag... If https://aur.archlinux.org/packages/gcc63/ is your package, you are not building the gcc63-libs subpackage. Why is that part commented out ? Lone_Wolf
participants (3)
-
Eli Schwartz
-
LoneVVolf
-
Stefan Husmann