-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
libgcc_s is from bootstrap tools?? #36947
Comments
Update: This is actually the reason gcc7 is broken with i686 everywhere! ("undefined refeences to Sure enough the libgcc_s we should be using has that symbol, but it is missing in the one from bootstrap tools (that we manage to use instead). |
Relevant to #36453 ; for nixos:release-18.03:nixos.closures.xfce.i686-linux (https://hydra.nixos.org/build/71018796) |
I have a solution for this based on #36948, but the hairy problem is that a number of packages that used to find |
👍 sounds updating them is the easiest workaround ATM. It would be really nice to have i686 in a better shape for 18.09. |
We actually do have a libgcc package, haha. It's sort of lying in waiting until I package enough of the other ones to redo the bootstrapping. |
There is no way the abomination that grovels deeply in the internals of the GCC build system can or should be used. Especially considering the fact that the current problems are caused by a version mismatch between
|
Huge 👍 (warranting a comment ;)). |
Also fixing up binary packages doesn't seem so bad-- can we fix this for 18.09? This is the foundation of everything else in nixpkgs (more or less), and it's worth ensuring it's solid. |
Yes that should be down for 18.09. And if I make the libs output a |
There was the plan to just update bootstrap tools to work around the worst for 18.09 – what phase is that in? (Have I missed some thread?) EDIT: the longterm plan is to fork 18.09 during the next weekend, you know... |
@vcunat I have the branch at https://github.com/dezgeg/nixpkgs/tree/update-bootstrap. IT seemed to work for me, as in fixing the i686 packages that used to be broken. Just need someone to upload them to an official location, for which the commit message has a script for whoever is responsible for that. (edit: https://github.com/dezgeg/nixpkgs/tree/update-bootstrap-rebased rebased to today's staging to fix a conflict, not tested) |
OK, I tested stdenv and some other builds on the rebased branch: x86_64, i686, and aarch64 (via the community machine). I confirm that i686 problem doesn't appear anymore. @edolstra: can you upload the tarballs? I don't know who else has credentials for this. Paths to Hydra builds are linked in that commit. I suppose it might be enough to update i686 to work around the worst part, but it's probably better to keep them all in sync. |
I've built my system based on this and I'm very happy to have recent qt and stuff now again on my old i686 laptop! |
When things get automatically mirrored to tarballs.nixos.org once hydra built them, what is to be done to have the changes made in dezgeg@2dff64e available in official places? I found some docs by @domenkozar, maybe he wants to help. |
First should be tarball upload, then pushing the equivalent of dezgeg@2dff64e (with different URLs) to staging branch(es) to rebuild the world, and finally merging to the main branch(es). |
Maybe I'm missing something, but why not push those two commits as-is to staging and change the URLs later? And, will this get into 18.09 at all? |
That would be possible, but not nice, and we might just forget to upload it for a very long time. 18.09 certainly won't contain this at release time (days away), but I think it might be possible to pick it later, as update of bootstrapping tools should be very non-intrusive (it's mainly a mass rebuild). |
Rebased the glibc fix, since it had conflicts. Why do bootstrap tool bundles need updating for this, again? If/when we merge this we may wish to include immediately also pick the commit from @dezgeg that removes the treewide kludgery that works around the issues this resolves. |
Found the commit, touched it up and added it. |
Ahh great. I can open a PR to change this. I believe it was in GNOME 3.34 we had to do this (woefully). |
To summarize,
but any final stage package should use libgcc_s from gccForLibs instead:
|
Aargh, I seem to have used the wrong keyword. Sorry for closing 😁 |
FYI, i have arrived here while trying to use it's a project that can also be built without linking to
my
|
I marked this as stale due to inactivity. → More info |
#132343 should help. |
I stumbled on this while debugging #136574. The problem is, that recent GCCs add more symbols to A previous fix has removed We (@BBBSnowball and I) have explored another option: Instead of removing |
Is there any sort of workaround available here? I've become blocked on needing Chromium on my RPi, which is marked broken due to #136629. If I've read everything correctly, this appears to be the underlying issue. |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/chromium-on-rpi-workaround/18557/1 |
Let's try this again. See NixOS#36947 and NixOS#36948 for history
Let's try this again. See NixOS#36947 and NixOS#36948 for history
Can this be closed? |
Yes, I believe so. |
Issue description
Time for a libgcc package? 😁
We probably want to have libgcc_s matching our compiler (and not frozen to whatever is in our bootstrap tools).
diffoscope between libgcc_s.so.1 in stdenv.cc.cc.lib and glibc: https://gist.github.com/dtzWill/596b43d5c16178f570b5357e941ea587
Note that this libgcc_s (the old one from gcc 5.3 apparently) is what everything links to (that needs it), easy example is lzip.
nixpkgs/pkgs/development/libraries/glibc/default.nix
Line 36 in 25edc47
(Comment suggests the glibc used in stdenv won't be copied like this, but that's not true)
A separate libgcc package (or compiler-rt? :D) would be best, but if nothing else we probably should use a libgcc that matches our compiler.
Steps to reproduce
The text was updated successfully, but these errors were encountered: