-
-
Notifications
You must be signed in to change notification settings - Fork 15.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gcc: link $lib/lib -> $lib/$targetConfig correctly and consistently #282236
Conversation
When native-compiling, gcc will install libraries into: /nix/store/...-$targetConfig-gcc-$version-lib/lib When cross-compiling, gcc will install libraries into: /nix/store/...-$targetConfig-gcc-$version-lib/$targetConfig When cross-compiling, we intended to create a link from $lib/lib to $lib/$targetConfig, so that downstream users can always safely assume that "${lib.getLib stdenv.cc.cc}/lib" is where the gcc libraries are, regardless of whether `stdenv.cc.cc` is a cross compiler or a native compiler. Unfortunately, there were two problems with how we were trying to create these links: 1. The link would be created only when `enableLibGccOutput==true` 2. The link was being created from the incorrect source `$lib/lib/lib` instead of `$lib/lib`. Both of these mistakes are my fault. This commit corrects them by creating the link using `ln -Ts` (which is more predictable) and by creating the link from `gcc/common/builder.nix` rather than from `gcc/common/libgcc.nix`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I built the cross-compiler via
$ nom build .#pkgsCross.aarch64-multiplatform.stdenv.cc.cc.lib
I see that there's a nested lib
directory so the libraries are in lib/lib
-- is this intentional?
$ ls -la result-lib/lib/lib
total 8808
dr-xr-xr-x 2 root root 4096 Jan 1 1970 .
dr-xr-xr-x 3 root root 4096 Jan 1 1970 ..
-r-xr-xr-x 2 root root 1208 Jan 1 1970 libasan.la
lrwxrwxrwx 199 root root 16 Jan 1 1970 libasan.so -> libasan.so.8.0.0
lrwxrwxrwx 199 root root 16 Jan 1 1970 libasan.so.8 -> libasan.so.8.0.0
-r-xr-xr-x 2 root root 1678448 Jan 1 1970 libasan.so.8.0.0
-r-xr-xr-x 2 root root 1068 Jan 1 1970 libatomic.la
lrwxrwxrwx 289 root root 18 Jan 1 1970 libatomic.so -> libatomic.so.1.2.0
lrwxrwxrwx 289 root root 18 Jan 1 1970 libatomic.so.1 -> libatomic.so.1.2.0
-r-xr-xr-x 2 root root 90944 Jan 1 1970 libatomic.so.1.2.0
-r--r--r-- 175 root root 132 Jan 1 1970 libgcc_s.so
-r--r--r-- 2 root root 150664 Jan 1 1970 libgcc_s.so.1
-r-xr-xr-x 2 root root 1050 Jan 1 1970 libgomp.la
lrwxrwxrwx 289 root root 16 Jan 1 1970 libgomp.so -> libgomp.so.1.0.0
lrwxrwxrwx 289 root root 16 Jan 1 1970 libgomp.so.1 -> libgomp.so.1.0.0
-r-xr-xr-x 2 root root 384936 Jan 1 1970 libgomp.so.1.0.0
-r-xr-xr-x 2 root root 1222 Jan 1 1970 libhwasan.la
lrwxrwxrwx 59 root root 18 Jan 1 1970 libhwasan.so -> libhwasan.so.0.0.0
lrwxrwxrwx 59 root root 18 Jan 1 1970 libhwasan.so.0 -> libhwasan.so.0.0.0
-r-xr-xr-x 2 root root 604896 Jan 1 1970 libhwasan.so.0.0.0
-r-xr-xr-x 2 root root 1038 Jan 1 1970 libitm.la
lrwxrwxrwx 289 root root 15 Jan 1 1970 libitm.so -> libitm.so.1.0.0
lrwxrwxrwx 289 root root 15 Jan 1 1970 libitm.so.1 -> libitm.so.1.0.0
-r-xr-xr-x 2 root root 183008 Jan 1 1970 libitm.so.1.0.0
-r-xr-xr-x 2 root root 1208 Jan 1 1970 liblsan.la
lrwxrwxrwx 257 root root 16 Jan 1 1970 liblsan.so -> liblsan.so.0.0.0
lrwxrwxrwx 257 root root 16 Jan 1 1970 liblsan.so.0 -> liblsan.so.0.0.0
-r-xr-xr-x 2 root root 604224 Jan 1 1970 liblsan.so.0.0.0
-r-xr-xr-x 2 root root 1038 Jan 1 1970 libssp.la
-r-xr-xr-x 2 root root 1020 Jan 1 1970 libssp_nonshared.la
lrwxrwxrwx 289 root root 15 Jan 1 1970 libssp.so -> libssp.so.0.0.0
lrwxrwxrwx 289 root root 15 Jan 1 1970 libssp.so.0 -> libssp.so.0.0.0
-r-xr-xr-x 2 root root 71440 Jan 1 1970 libssp.so.0.0.0
-r-xr-xr-x 2 root root 1008 Jan 1 1970 libstdc++exp.la
-r-xr-xr-x 2 root root 1005 Jan 1 1970 libstdc++fs.la
-r-xr-xr-x 2 root root 1065 Jan 1 1970 libstdc++.la
lrwxrwxrwx 11 root root 19 Jan 1 1970 libstdc++.so -> libstdc++.so.6.0.32
lrwxrwxrwx 11 root root 19 Jan 1 1970 libstdc++.so.6 -> libstdc++.so.6.0.32
-r-xr-xr-x 2 root root 3131784 Jan 1 1970 libstdc++.so.6.0.32
-r--r--r-- 2 root root 2572 Jan 1 1970 libstdc++.so.6.0.32-gdb.py
-r-xr-xr-x 2 root root 999 Jan 1 1970 libsupc++.la
-r-xr-xr-x 2 root root 1208 Jan 1 1970 libtsan.la
lrwxrwxrwx 167 root root 16 Jan 1 1970 libtsan.so -> libtsan.so.2.0.0
lrwxrwxrwx 167 root root 16 Jan 1 1970 libtsan.so.2 -> libtsan.so.2.0.0
-r-xr-xr-x 2 root root 1495968 Jan 1 1970 libtsan.so.2.0.0
-r-xr-xr-x 2 root root 1215 Jan 1 1970 libubsan.la
lrwxrwxrwx 283 root root 17 Jan 1 1970 libubsan.so -> libubsan.so.1.0.0
lrwxrwxrwx 283 root root 17 Jan 1 1970 libubsan.so.1 -> libubsan.so.1.0.0
-r-xr-xr-x 2 root root 530304 Jan 1 1970 libubsan.so.1.0.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cross lib
dir seems wrong indeed, can confirm.
Description of changes
When native-compiling, gcc will install libraries into:
When cross-compiling, gcc will install libraries into:
When cross-compiling, we intended to create a link from
$lib/lib
to$lib/$targetConfig
, so that downstream users can always safely assume that${lib.getLib stdenv.cc.cc}/lib
is where the gcc libraries are, regardless of whetherstdenv.cc.cc
is a cross compiler or a native compiler.Unfortunately, there are two mistakes in how these links are created. Both of the mistakes are my fault:
The link would be created only when
enableLibGccOutput==true
The link was being created from the incorrect source
$lib/lib/lib
instead of$lib/lib
.This commit corrects these mistakes by creating the link using
ln -Ts
(which is more predictable) and by putting the code which creates the link ingcc/common/builder.nix
rather than ingcc/common/libgcc.nix
.CC: @trofi
Things done
x86_64-linux
)x86_64-linux
)tests.cross.sanity