Open tsmanner opened 3 years ago
One more thought on this, is it possible that this derivation is just missing the buildInput
for those gcc-X.Y.Z-lib
paths, so they're not accessible at build time? If so, then I would argue the statement we use a wrapper script that sets up the right environment variables so that the compiler and the linker just "work" seems at worst incorrect, and at best misleading.
Why are you using "-o" flag instead of "-c"?
The -c
flag works as long as there is only one source file per object file. My real-world use case is an environment where multiple .cpp
files are used to define functions in a single .h
. At some point, before the end of compilation, I would like to be able to describe intermediate object files that contain one class, so that large implementation files can be easily split apart.
More to the point, using just -c
and creating separate .o
files for each source file and then only linking one time at the very end would be a hack to get me going, and not a solution to the problem. The fact is that gcc9 from nixpkgs works, and invoking impure g++
on a Debian system in this way also works.
Doing some more digging and experimenting: it looks like including pkgs.glibc.static
helps ld
find libc
and libm
, but libgcc_s
is still missing. Doing a diff of the output of g++ -v
in each environment, to inspect the search paths, it looks like pkgs.glibc.static
included the following new path there, which contains libm.a
and libc.a
.
/nix/store/621bazyaka30fnswdni4a4qr4x0zxa1f-glibc-2.30-static/lib
Is there some equivalent derivation that yields a libgcc_s.a
? It seems, at the moment, like this may be solvable by just adding some buildInput
s for these static libraries. I am not certain whether I can complete the compile with these versions of the static libraries, as I will eventually need to run this on pre-ABI change gcc4.8, since it's in use in some development environments at $dayjob, and I fear I'll need non-standard, or locally compiled, versions of those static libraries in order to link.
Is there some equivalent derivation that yields a
libgcc_s.a
?
You might be able to get it from gcc.override { enableShared = false; }
I marked this as stale due to inactivity. → More info
Describe the bug When compiling using versions of gcc older than gcc9 with the
-r
flag, the compile fails withld
reporting missing libraries.To Reproduce Steps to reproduce the behavior:
foo.nix
that will compile a minimal c++ program, like the followingnix-build foo.nix
and it should succeedfoo.nix
to usepkgs.gcc8
nix-build
withpkgs.gcc8
and it will fail with linker errorsExpected behavior The
result
link should exist and point to an object file that represents the relocatable (a.k.a. partially linked) object, under all versions of gcc that support the-r
flag.Additional context This behavior is consistent in my WSL2 Debian (x86_64 Intel) environment and on my NixOS (x86_64 AMD) server. It doesn't seem to have anything to do with the platform as far as I can tell. I also see the same failure using
pkgs.gcc7
andpkgs.gcc48
.I do see, when
NIX_DEBUG
is enabled, that there are-L
and-rpath
flags being set in the wrapper that seem to point to the correct library directories:Notify maintainers
Metadata Please run
nix-shell -p nix-info --run "nix-info -m"
and paste the result. Results from WSL:Results from NixOS:
Maintainer information: NOTE: I suspect this is really an issue with the
cc-wrapper
or something similar.