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.

Sign up for GitHub

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

Jump to bottom

build-support/cc-wrapper: add libstdc++fs into default library path for clang #213021

Merged
merged 1 commit into from
Jan 28, 2023
Merged

build-support/cc-wrapper: add libstdc++fs into default library path for clang #213021

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions pkgs/build-support/cc-wrapper/default.nix
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -321,6 +321,11 @@ stdenv.mkDerivation {
&& !(stdenv.targetPlatform.useLLVM or false)
&& gccForLibs != null) ''
echo "--gcc-toolchain=${gccForLibs}" >> $out/nix-support/cc-cflags

# Pull in 'cc.out' target to get 'libstdc++fs.a'. It should be in
# 'cc.lib'. But it's a gcc package bug.
Copy link

@ghost ghost Jan 28, 2023 •
edited by ghost
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, libraries belong in lib.

Unfortunately a ton of packages that have a $lib output are putting their .a files in $out. I think autotools even does this by default when you build both static and dynamic libraries (i.e. it doesn't use --libdir for the .a files). On my system, when scanning /nix/store/*-lib/ for .a files, the only hits are things that don't use autotools. Or it might be the way nixpkgs invokes ./configure. Anyways, the problem affects a lot more than just gcc.

This should probably be fixed nixpkgs-wide in setup.sh someday.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately a ton of packages that have a $lib output are putting their .a files in $out.

From what I understand how library lookup works splitting .a and .so into different directories will effectively cause only one of them to be used as ld will use first found. I would expect most of the packages to put both together in a single directory.

I think autotools even does this by default when you build both static and dynamic libraries (i.e. it doesn't use --libdir for the .a files). On my system, when scanning /nix/store/*-lib/ for .a files, the only hits are things that don't use autotools. Or it might be the way nixpkgs invokes ./configure.

My understanding is that nixpkgs tries hard not to build both if possible (--enable-shared --disable-static / --disable-shared --enable-static). autotools should put both into --libdir. Even FHS distributions rely a lot on --libdir correct handling to put 32-vs-64 bit code into a correct location to make -m32/-m64 just work.

Anyways, the problem affects a lot more than just gcc.

Sure. Though most programs don't implement the split between host/target libraries. For simpler programs it should be only a matter of fixing build system to put results into a correct directory (--libdir or equivalent). gcc case is slightly more complicated than that. Otherwise we would not need this huge driver-wrapper that incorrectly reimplements gcc's assumed library search.

# TODO(trofi): remove once gcc is fixed to move libraries to .lib output.
echo "-L${gccForLibs}/${optionalString (targetPlatform != hostPlatform) "/${targetPlatform.config}"}/lib" >> $out/nix-support/cc-ldflags
''

##
Expand Down