Should updates only be permitted with same gcc version?
Dr. David Kirkby
are performed with the same version of gcc as that which was used to build gcc
in the first placed. Basically, two people have found
1) Install Sage with older gcc.
2) Install the latest gcc 4.4.3
3) Try to update Sage, and it fails
4) Build Sage from the start, using gcc 4.4.3 and it works.
This makes me think it would be desirable to store the version of gcc used to
build Sage some way, and then only let updates take place with that same
version. Getting the version is very easy
$ gcc -dumpversion
so it could be stored in a file when Sage is first built. Then any updates check
that the version of gcc has not changed.
My understanding was that you could mix objects from the same minor release i.e.
gcc x.y.z for any 'z' would be ok. But it would appear in practice this is not so.
In initial build:
gcc -dumpvesion > gcc-build-version
In updates
gcc -dumpversion > gcc-update-version
if [ `cksum gcc-build-version` != `cksum gcc-update-version` ] ; then
echo 2>&1 "Sorry, you must use the same version of gcc to update Sage as you
used when you built Sage."
echo 2>&1 "Sage was built with gcc version `cat gcc.-build-version` "
exit 1
fi
Using the cksum of the file is probably the easiest way of determining if the
version is the same. Saves messing around parsing a file.
BTW, not that it is important here, since you would only update Sage on the same
platform, but 'cksum' gives the same answer on any platform, as the algorithm is
specified by POSIX
http://www.opengroup.org/onlinepubs/9699919799/utilities/cksum.html
In contrast, 'sum', which exists on many systems, gives different answers on
different platforms (I got my fingers burnt over this is the past)
Dave
Dr. David Kirkby
> The issue reported on sage-support makes me think we should insist that
> updates are performed with the same version of gcc as that which was
> used to build gcc in the first placed.
I mean update Sage with the same version of gcc - not update gcc with the same
version!
Dave
Alex Ghitza
> The issue reported on sage-support makes me think we should insist that updates
> are performed with the same version of gcc as that which was used to build gcc
> in the first placed. Basically, two people have found
>
> 1) Install Sage with older gcc.
> 2) Install the latest gcc 4.4.3
> 3) Try to update Sage, and it fails
> 4) Build Sage from the start, using gcc 4.4.3 and it works.
>
Again, that's not what happened (but I guess I didn't explain it
properly). Here's the actual run of events:
1) Build sage-4.3.1 with gcc-4.4.2 on Arch Linux; Sage runs fine, passes
doctests, etc. Someone else gets the binary and can use it to run Sage
2) Upgrade gcc to gcc-4.4.3
3) Try to run sage, get errors that the original poster listed
4) Rebuild sage-4.3.1 (so the same version) from scratch with gcc-4.4.3,
and everything is fine again (for me, but not for the other person who
couldn't use my binary because of a cpu flag issue)
I guess the moral of the story is that one needs to exercise care when
upgrading gcc on one's machine, although I find it strange that this
occurred.
I'm not claiming that the scenario that you laid out could not occur;
I just wanted to clarify what happened in the case in question.
Best,
Alex
--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/
Dr. David Kirkby
> On Sun, 31 Jan 2010 09:47:00 +0000, "Dr. David Kirkby" <david....@onetel.net> wrote:
>> The issue reported on sage-support makes me think we should insist that updates
>> are performed with the same version of gcc as that which was used to build gcc
>> in the first placed. Basically, two people have found
>>
>> 1) Install Sage with older gcc.
>> 2) Install the latest gcc 4.4.3
>> 3) Try to update Sage, and it fails
>> 4) Build Sage from the start, using gcc 4.4.3 and it works.
>>
>
> Again, that's not what happened (but I guess I didn't explain it
> properly). Here's the actual run of events:
Sorry. I should have read the thread more carefully - it is not your fault.
> 1) Build sage-4.3.1 with gcc-4.4.2 on Arch Linux; Sage runs fine, passes
> doctests, etc. Someone else gets the binary and can use it to run Sage
> 2) Upgrade gcc to gcc-4.4.3
> 3) Try to run sage, get errors that the original poster listed
So you are saying that simply updating gcc, causes Sage to no longer work? That
seems very naughty of the shipped gcc/libc if that is happening. I could
understand if one removed a new version of gcc, and replaced it with an old
version this might happen.
But I think when shipping binaries, we should include ALL the libraries used by
gcc with Sage. That means:
* libgcc_s
* libgfortran
* libstdc++.
I've said this before, but nobody has really agreed with me. I think there could
be issues if Sage is built with a new gcc, and someone has only an old one.
I'm just in the process of building a SPARC binary package. I decided to use
LZMA compression, which is going to use 2 hours of CPU time on my oldest SPARC
machine. But I have included those libraries.
On Solaris at least, only a very old gcc is shipped, so I suspect the libraries
will be too out of date. If I build Sage with gcc 4.4.1, and someone has only
gcc 3.4.3 (shipped with Solaris), then I think their library is likely to be too
old. So it's better if we ship one with the same version of gcc as used to build
Sage.
> 4) Rebuild sage-4.3.1 (so the same version) from scratch with gcc-4.4.3,
> and everything is fine again (for me, but not for the other person who
> couldn't use my binary because of a cpu flag issue)
Fair enough. I mis understood this. But I still think we should not let someone
upgrade Sage with a version different to what they used to build it.
Dave
Jaap Spies
[snipped]
>
> Fair enough. I mis understood this. But I still think we should not let
> someone upgrade Sage with a version different to what they used to build
> it.
>
-1
I've a system wide install of sage upgraded 86 times:
[root@paix installed]# ls sage-*
sage-1.5.1.2 sage-2.1.0.1 sage-2.4.1.2 sage-2.8.12 sage-2.8.6 sage-3.0.6 sage-4.0
sage-1.5.3 sage-2.10.1 sage-2.4.2 sage-2.8.13 sage-2.8.7 sage-3.1 sage-4.0.1
sage-1.6 sage-2.10.2 sage-2.5 sage-2.8.14 sage-2.8.8 sage-3.1.1 sage-4.0.2
sage-1.6.1 sage-2.10.3 sage-2.5.0.2 sage-2.8.15 sage-2.8.8.1 sage-3.1.2 sage-4.1
sage-1.7 sage-2.10.4 sage-2.5.1 sage-2.8.2 sage-2.8.9 sage-3.1.4 sage-4.1.1
sage-1.7.1 sage-2.11 sage-2.5.2 sage-2.8.3 sage-2.9 sage-3.2 sage-4.1.2
sage-1.8 sage-2.1.3 sage-2.5.3 sage-2.8.3.3 sage-2.9.1.1 sage-3.2.1 sage-4.2
sage-1.8.1 sage-2.1.3.1 sage-2.6 sage-2.8.3.6 sage-2.9.2 sage-3.2.2 sage-4.2.1
sage-1.8.2.1 sage-2.1.4 sage-2.7 sage-2.8.4 sage-3.0 sage-3.2.3 sage-4.3
sage-1.9 sage-2.2 sage-2.7.3 sage-2.8.4.1 sage-3.0.2 sage-3.3
sage-2.0 sage-2.3 sage-2.8 sage-2.8.4.2 sage-3.0.3 sage-3.4
sage-2.1 sage-2.4 sage-2.8.10 sage-2.8.5 sage-3.0.4 sage-3.4.1
sage-2.10 sage-2.4.1 sage-2.8.11 sage-2.8.5.1 sage-3.0.5 sage-3.4.2
[root@paix installed]# ls sage-* | wc
87 87 945
Only last time things went wrong in upgrading to sage-4.3.1.
I have to look into that.
Jaap
> Dave
>
Peter Jeremy
>Alex Ghitza wrote:
>> 1) Build sage-4.3.1 with gcc-4.4.2 on Arch Linux; Sage runs fine, passes
>> doctests, etc. Someone else gets the binary and can use it to run Sage
>> 2) Upgrade gcc to gcc-4.4.3
>> 3) Try to run sage, get errors that the original poster listed
>
>So you are saying that simply updating gcc, causes Sage to no longer
>work? That seems very naughty of the shipped gcc/libc if that is
>happening. I could understand if one removed a new version of gcc,
>and replaced it with an old version this might happen.
This is definitely undesirable - especially with only a 0.0.1 change
in the compiler.
>But I think when shipping binaries, we should include ALL the
>libraries used by gcc with Sage. That means:
>
>* libgcc_s
>* libgfortran
>* libstdc++.
This opens up two cans of worms:
1) Since those libraries won't be located where the compiler originally
expected to find them, Sage will need to have appropriate
LD_LIBRARY_PATH (or equivalent) hooks.
2) There may be licensing issues distributing libraries associated with
non-gcc compilers.
>I've said this before, but nobody has really agreed with me. I think
>there could be issues if Sage is built with a new gcc, and someone
>has only an old one.
Definitely, if someone only has gcc3 libraries installed then trying
to use an application compiled with gcc4 could be problematic.
Finding the exact restrictions probably means asking the GCC
maintainers. There are also likely to be different restrictions on
compiling an application with gcc-X and trying to run it when only
gcc-Y is installed and compiling bits of an application with gcc-X
and other bits with gcc-Y and expecting it to work.
--
Peter Jeremy
David Kirkby
> On 2010-Jan-31 11:15:08 +0000, "Dr. David Kirkby" <david....@onetel.net> wrote:
>>Alex Ghitza wrote:
>>> 1) Build sage-4.3.1 with gcc-4.4.2 on Arch Linux; Sage runs fine, passes
>>> doctests, etc. Someone else gets the binary and can use it to run Sage
>>> 2) Upgrade gcc to gcc-4.4.3
>>> 3) Try to run sage, get errors that the original poster listed
>>
>>So you are saying that simply updating gcc, causes Sage to no longer
>>work? That seems very naughty of the shipped gcc/libc if that is
>>happening. I could understand if one removed a new version of gcc,
>>and replaced it with an old version this might happen.
>
> This is definitely undesirable - especially with only a 0.0.1 change
> in the compiler.
I would be tempted to dismiss this as a user error, but two people
have reported it, so it is not.
>>But I think when shipping binaries, we should include ALL the
>>libraries used by gcc with Sage. That means:
>>
>>* libgcc_s
>>* libgfortran
>>* libstdc++.
>
> This opens up two cans of worms:
> 1) Since those libraries won't be located where the compiler originally
> expected to find them, Sage will need to have appropriate
> LD_LIBRARY_PATH (or equivalent) hooks.
Yes, agreed. But the sage-env scripts addends (prepends?)
LD_LIBRARY_PATH to include $SAGE_ROOT/local/lib. So they will be
found.
As a test, I copied the libraries there, then changed the permissons
of the directories where the gcc libraries were, to 000, so they could
not be found. I then run
$ ./sage -sh
to get the Sage environment.
Then I used 'ldd' and see all libraries were found. (I must admit, I
did not actualy run Sage at that point, which would have been very
sensible!)
> 2) There may be licensing issues distributing libraries associated with
> non-gcc compilers.
That may be true, but I doubt it.
Certainly for Solaris, the Sun compilers are now free, so getting
someone to install them should not be an issue.
I can't believe IBM (AIX), HP (HP-UX) or similar would sell a
commerical compiler, then insist that before an end-user could run
your software, they would need to purchase a license for the compiler.
I suspect they will allow you to ship the run-time libraries if you
have a licensed commerical compiler.
>>I've said this before, but nobody has really agreed with me. I think
>>there could be issues if Sage is built with a new gcc, and someone
>>has only an old one.
>
> Definitely, if someone only has gcc3 libraries installed then trying
> to use an application compiled with gcc4 could be problematic.
From what I once read, you was ok if if the minor version (z), in
x.y.z changed, but not if the x or y changed.
I need to go out, so do not have time to find the link.
> Finding the exact restrictions probably means asking the GCC
> maintainers. There are also likely to be different restrictions on
> compiling an application with gcc-X and trying to run it when only
> gcc-Y is installed and compiling bits of an application with gcc-X
> and other bits with gcc-Y and expecting it to work.
>
> --
> Peter Jeremy
As you say, finding the exact restrictions would probably mean asking
the gcc maintainers. One Solaris, it is pretty likely to break, given
only gcc 3.4.x is shipped, which is why I added the libraries to the
binary. I will test that binary later today on 't2'.
Dave
Dr. David Kirkby
I just did on gcc-help. The basic answer was, for a version X.Y.Z
1) If X increments, then yes, you could get well problems.
2) If Y increments, you would very unlikely to get problems, but it is possible.
3) If Z increments, then you will not get problems.
Robert Bradshaw
I think "will" should be replaced with "should" in that last
statement. Some good practical info is on http://www.gentoo.org/doc/en/gcc-upgrading.xml
- Robert