Skip to content
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

Closed
wants to merge 1 commit into from
Closed

gcc: link $lib/lib -> $lib/$targetConfig correctly and consistently #282236

wants to merge 1 commit into from

Conversation

ghost
Copy link

@ghost ghost commented Jan 20, 2024

Description of changes

When native-compiling, gcc will install libraries into:

$lib/lib

When cross-compiling, gcc will install libraries into:

$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 are two mistakes in how these links are created. Both of the mistakes are my fault:

  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.

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 in gcc/common/builder.nix rather than in gcc/common/libgcc.nix.

CC: @trofi

Things done

  • Building
    • x86_64-linux
    • powerpc64le-linux
    • aarch64-linux (cross from x86_64-linux)
    • mips64el-linux (cross from x86_64-linux)
    • tests.cross.sanity
  • Fits CONTRIBUTING.md.

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`.
@delroth delroth added the 12.approvals: 1 This PR was reviewed and approved by one reputable person label Jan 21, 2024
ConnorBaker
ConnorBaker previously approved these changes Jan 22, 2024
@delroth delroth added 12.approvals: 2 This PR was reviewed and approved by two reputable people and removed 12.approvals: 1 This PR was reviewed and approved by one reputable person labels Jan 22, 2024
Copy link
Contributor

@ConnorBaker ConnorBaker left a 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

@ConnorBaker ConnorBaker dismissed their stale review January 22, 2024 17:38

Question about nested lib directory

@delroth delroth added 12.approvals: 1 This PR was reviewed and approved by one reputable person and removed 12.approvals: 2 This PR was reviewed and approved by two reputable people labels Jan 22, 2024
Copy link
Member

@sternenseemann sternenseemann left a 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.

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants