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

Everything should be rebuilt after GCC upgrade #24703

Closed
jdemeyer opened this issue Feb 10, 2018 · 55 comments
Closed

Everything should be rebuilt after GCC upgrade #24703

jdemeyer opened this issue Feb 10, 2018 · 55 comments

Comments

@jdemeyer
Copy link

Due to C++ ABI incompatibilities, problems occur if code built with earlier versions of GCC is linked against code built with newer versions of GCC. This leads for example to patchbot failures mentioned below.

The simplest solution is to make every package depend on the GCC executable. This way, a GCC upgrade will force everything to be rebuilt. This may be overkill, but it's not a big problem in practice since GCC is upgraded rarely (unlikely other Sage packages, it is never automatically rebuilt except if absolutely needed, see for example #24599).


See attachment: crash_zrVXNw.log for a crash log from the arando i686 patchbot with Sage 8.2.beta5 using GCC 7.2.0. It involves brial and C++ strings.

The following doctests fail:

sage -t --warn-long 67.1 src/sage/rings/polynomial/multi_polynomial_sequence.py  # Killed due to abort
sage -t --warn-long 67.1 src/sage/rings/polynomial/pbori.pyx  # Killed due to abort
sage -t --warn-long 67.1 src/sage/rings/polynomial/multi_polynomial_libsingular.pyx  # Killed due to abort
sage -t --warn-long 67.1 src/sage/rings/polynomial/polynomial_ring_constructor.py  # Killed due to abort

CC: @kiwifb @embray

Component: packages: standard

Author: Jeroen Demeyer

Branch: 70ff832

Reviewer: François Bissey

Issue created by migration from https://trac.sagemath.org/ticket/24703

@jdemeyer
Copy link
Author

Attachment: crash_zrVXNw.log

@jdemeyer

This comment has been minimized.

@jdemeyer

This comment has been minimized.

@jdemeyer

This comment has been minimized.

@jdemeyer

This comment has been minimized.

@jdemeyer jdemeyer changed the title SIGABRT on i686 involving polybori and strings SIGABRT on i686 involving polybori and C++ strings Feb 10, 2018
@jdemeyer
Copy link
Author

Author: Jeroen Demeyer

@jdemeyer

This comment has been minimized.

@jdemeyer jdemeyer changed the title SIGABRT on i686 involving polybori and C++ strings Everything should be rebuilt after GCC upgrade Feb 12, 2018
@jdemeyer

This comment has been minimized.

@kiwifb
Copy link
Member

kiwifb commented Feb 12, 2018

comment:7

Yup, pretty much anything that use C++ has to be rebuilt when you move to gcc-5. gcc dev have made some commitments to ABI stability for the time being. But then you also have the change of ABI for gfortran at gcc-7. The only thing that's rock solid for almost ever is C.

@jdemeyer
Copy link
Author

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Feb 14, 2018

Commit: c59430d

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Feb 14, 2018

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

c59430dEverything should be rebuilt after GCC upgrade

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Feb 14, 2018

Changed commit from c59430d to 057b434

@sagetrac-git
Copy link
Mannequin

sagetrac-git mannequin commented Feb 14, 2018

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

057b434Everything should be rebuilt after GCC upgrade

@jdemeyer

This comment has been minimized.

@kiwifb
Copy link
Member

kiwifb commented Feb 18, 2018

Reviewer: François Bissey

@kiwifb
Copy link
Member

kiwifb commented Feb 18, 2018

comment:13

Not sure why the patchbot is failing but the stuff looks good me, and we should include it ASAP.

@embray
Copy link
Contributor

embray commented Feb 19, 2018

comment:14

Replying to @kiwifb:

Not sure why the patchbot is failing but the stuff looks good me, and we should include it ASAP.

I need to upgrade that patchbot. It's running an old version of the patchbot package that has a bug when testing "unsafe" tickets.

@embray
Copy link
Contributor

embray commented Feb 19, 2018

comment:15

Okay, I don't really care since I'm not in the habit of building gcc anyways, but I would appreciate if someone sign off on #21524 so I don't have to keep upgrading it to incorporate changes like this.

@vbraun
Copy link
Member

vbraun commented Feb 20, 2018

@jdemeyer
Copy link
Author

jdemeyer commented Mar 2, 2018

comment:27

Replying to @vbraun:

This also happens after backing out the ticket

I think it's a bug in the previous version of this ticket then.

This is the second build of gcc

There shouldn't be a second build of gcc.

It would be very useful to see the auto-generated build/make/Makefile from the failed build to understand what is happening.

@vbraun
Copy link
Member

vbraun commented Mar 2, 2018

Attachment: Makefile.gz

@vbraun
Copy link
Member

vbraun commented Mar 2, 2018

comment:29

I attached the makefile...

@vbraun
Copy link
Member

vbraun commented Mar 2, 2018

comment:30

I checked out just this ticket and ran make distclean && make and gcc builds twice

buildbot@sagebd07_64s02:~/slave/sage_git/build$ grep 'Found local metadata for gcc' logs/install.log 
[gcc-7.2.0] Found local metadata for gcc-7.2.0
[gcc-7.2.0] Found local metadata for gcc-7.2.0

and the second time is in parallel with lots of other stuff...

@jdemeyer
Copy link
Author

jdemeyer commented Mar 2, 2018

comment:31

OK, I think I know what happened: there is indeed a serious bug that GCC is installed twice.

But that bug is not because of this ticket, it is most likely happening since #24599. I think you are just unlucky to hit this bug now and not before.

@jdemeyer
Copy link
Author

jdemeyer commented Mar 2, 2018

comment:32

I would rather prefer to merge this ticket anyway and then deal with further fixes to the GCC build process in a future ticket.

@vbraun
Copy link
Member

vbraun commented Mar 2, 2018

comment:33

Sure, did you open a followup ticket?

@vbraun
Copy link
Member

vbraun commented Mar 2, 2018

@vbraun
Copy link
Member

vbraun commented Mar 2, 2018

Commit: 057b434

@vbraun
Copy link
Member

vbraun commented Mar 2, 2018

New commits:

057b434Everything should be rebuilt after GCC upgrade

@vbraun
Copy link
Member

vbraun commented Mar 2, 2018

New commits:

70ff832Everything should be rebuilt after GCC upgrade

@vbraun
Copy link
Member

vbraun commented Mar 2, 2018

@vbraun
Copy link
Member

vbraun commented Mar 2, 2018

Changed commit from 057b434 to 70ff832

@vbraun
Copy link
Member

vbraun commented Mar 2, 2018

Changed branch from u/jdemeyer/057b434babb6ec6eaa7bae4afad4255a7481b1af to 70ff832

@jhpalmieri
Copy link
Member

comment:37

A question related to #24961: should we be checking that x$SAGE_INSTALL_GCC = xexists or that x$SAGE_INSTALL_GCC = xyes? On an OS X machine, I have Sage's gcc installed (from a few betas ago), but now Sage uses clang instead of gcc, so Sage's gcc will not be rebuilt as I upgraded Sage.

@jhpalmieri
Copy link
Member

Changed commit from 70ff832 to none

@kiwifb
Copy link
Member

kiwifb commented Mar 13, 2018

comment:38

Replying to @jhpalmieri:

A question related to #24961: should we be checking that x$SAGE_INSTALL_GCC = xexists or that x$SAGE_INSTALL_GCC = xyes? On an OS X machine, I have Sage's gcc installed (from a few betas ago), but now Sage uses clang instead of gcc, so Sage's gcc will not be rebuilt as I upgraded Sage.

Really, you need to check both, with the caveat that if you installed with clang and want to switch to gcc you will break your install. So, unfortunately, a not so stupid user could break things.

@jhpalmieri
Copy link
Member

comment:39

In my case, I switched from gcc (the default) to clang (the new default), and upgrading to the most recent beta broke things, because this test ended up adding bad stuff to build/make/Makefile, as reported in sage-release and #21524, and now being fixed in #24961.

@jdemeyer
Copy link
Author

comment:40

Replying to @jhpalmieri:

In my case, I switched from gcc (the default) to clang (the new default)

Are you sure? If the GCC spkg is installed, it should be used by Sage. If this is not the case, I consider that a bug.

@jdemeyer
Copy link
Author

comment:41

Replying to @kiwifb:

Replying to @jhpalmieri:

A question related to #24961: should we be checking that x$SAGE_INSTALL_GCC = xexists or that x$SAGE_INSTALL_GCC = xyes? On an OS X machine, I have Sage's gcc installed (from a few betas ago), but now Sage uses clang instead of gcc, so Sage's gcc will not be rebuilt as I upgraded Sage.

Really, you need to check both

I don't see why, but maybe I'm missing something?

@jhpalmieri
Copy link
Member

comment:42

Replying to @jdemeyer:

Replying to @jhpalmieri:

In my case, I switched from gcc (the default) to clang (the new default)

Are you sure? If the GCC spkg is installed, it should be used by Sage. If this is not the case, I consider that a bug.

I guess you're right, gcc is used, but configure tells me that gcc will not be installed.

@jdemeyer
Copy link
Author

comment:43

Replying to @jhpalmieri:

configure tells me that gcc will not be installed.

It won't be installed if it's already installed. Consider that a feature.

@jhpalmieri
Copy link
Member

comment:44

I also consider it a feature if it's not installed because clang is going to be used instead. configure does not give a reason for it not being installed, leaving me to guess as to what's going on.

@jdemeyer
Copy link
Author

comment:45

Replying to @jhpalmieri:

I also consider it a feature if it's not installed because clang is going to be used instead.

Of course. But that should work now, right?

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

No branches or pull requests

5 participants