When moving gcc libs, prefer the same directory as libc #639
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If libc ended up in a directory other than /lib, place GCC's libs in that directory as well. Signed-off-by: Alexey Neyman <stilor@att.net>
|
I noticed that the glibc-based toolchains where the glibc's default installation directory is not lib (e.g., aarch64-*-linux-gnu where it is lib64) fail in buildroot because, e.g., libraries end up in /lib64 and dynamic linker is installed into /lib. Before this change, even libraries were split between both locations. I'll propose a patch to handle ld-so being in a different directory to buildroot (this seems to be the case with multilib-musl as well). |
|
Causes a regression in powerpc64le-unknown-linux-gnu, where ld's and gcc's search paths differ: gcc wants to use /lib64 and ld searches /lib64le. As a result, libgcc_s.so (needed by libexpat.so but not specified explicitly via the -lgcc_s) is not found by linker. |
binutils 2.23 and earlier are not affected, they had the correct code. Signed-off-by: Alexey Neyman <stilor@att.net>
... and in addition to final toolchain aliasing, use it when configuring multilibs for glibc/musl. Note that uClibc does not need it, it is explicitly selecting the tools using CROSS_PREFIX. Signed-off-by: Alexey Neyman <stilor@att.net>
Convert absolute targets to relative so that they are valid on the host, too. The procedure is very similar to uclibc, so it is moved into a common function. Signed-off-by: Alexey Neyman <stilor@att.net>
Also a fix for CT_IterateMultilibs: it didn't pass multi_os_dir_gcc, so it only worked if the caller did *not* declare it as a local variable. Signed-off-by: Alexey Neyman <stilor@att.net>
... as we are going through various multilibs in ld.so.conf Signed-off-by: Alexey Neyman <stilor@att.net>
Signed-off-by: Alexey Neyman <stilor@att.net>
... and default to 'n'. Signed-off-by: Alexey Neyman <stilor@att.net>
GCC does not distinguish the resulting binary by the CFLAGS (e.g. based on which -march= was given). This means, while it will use the right libraries for linking, at runtime they are all going to request the same ld.so path and load the libraries from the same default path. Signed-off-by: Alexey Neyman <stilor@att.net>
It turns out buildroot does not currently accept a toolchain where a dynamic linker does not reside in the multi-os-directory. Unfortunately this is how glibc installs itself on AArch64 without any extra tricks. So, provide an option to force everything into /lib or /usr/lib; patch to buildroot will be worked on separately. Signed-off-by: Alexey Neyman <stilor@att.net>
stilor
force-pushed
the
tweak-gcc-movelibs
branch
from
067a950
to
63b2a19
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If libc ended up in a directory other than /lib, place GCC's libs
in that directory as well.
Signed-off-by: Alexey Neyman stilor@att.net