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