-Original Message-
From: sage-devel@googlegroups.com on behalf of Georg S. Weber
Sent: Fri 12/17/2010 11:30 AM
To: sage-devel
Subject: [sage-devel] Re: Should Sage include its own gcc ? It would add <= 1.6
MB to the Sage tarball.
P.S.:
Francois, I thought you were "on leave&qu
On 16 Dez., 14:56, leif wrote:
> On 16 Dez., 13:11, Volker Braun wrote:
>
> > Gentoo-prefix uses rpath instead of the LD_LIBRARY_PATH kludge, very good!
> > But this also means that there won't be any binary distributions (even in
> > their current broken state) until we work out the rpath-rewr
>
> I think you really know what you're talking about. I agree with your
> remarks above, especially points 1 and 2 above, and your remarks about
> the difficulty of building GCC itself and having different coexisting
> GCC's at once are exactly right.
>
> Shall we start taking some genuine steps
For the record, PatchELF can grow an ELF executable to accommodate a larger
RPATH than what it was originally linked with.
But at least initially we should probably go with Leif's variable-rpath
option. By the time this works all distributions probably come with a
dloader that supports it ;-)
You can bootstrap gcc with Sun studio, say, but you cannot compile gcc with
another compiler. If gcc 4.0.1 did not bootstrap with Sun's compiler then it
was a regression and fixed in later versions.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this
-Original Message-
From: sage-devel@googlegroups.com on behalf of Volker Braun
Sent: Fri 12/17/2010 1:11 AM
To: sage-devel@googlegroups.com
Subject: [sage-devel] Re: Should Sage include its own gcc ? It would add <= 1.6
MB to the Sage tarball.
Gentoo-prefix uses rpath instead of
On 16 Dez., 18:09, David Kirkby wrote:
> On 14 December 2010 05:30, leif wrote:
>
> > (Btw., I failed in trying to compile some older versions of GCC with
> > newer ones, e.g. 4.0.x with 4.3.3, 4.4.3 and 4.5.1.)
> > -Leif
>
> At one point one could build gcc with a C compiler. Then it became
> ne
On 14 December 2010 05:30, leif wrote:
> (Btw., I failed in trying to compile some older versions of GCC with
> newer ones, e.g. 4.0.x with 4.3.3, 4.4.3 and 4.5.1.)
> -Leif
At one point one could build gcc with a C compiler. Then it became
necessary to use gcc to build gcc. Now as you say, you
On 16 Dez., 13:11, Volker Braun wrote:
> Gentoo-prefix uses rpath instead of the LD_LIBRARY_PATH kludge, very good!
> But this also means that there won't be any binary distributions (even in
> their current broken state) until we work out the rpath-rewriting.
At least newer GNU / Linux loaders s
I'm all in favor of splitting off the non-mathematical parts into sage-os. I
think Gentoo prefix is the most widely-used "hosted distribution" and
probably the way to go. Some observations:
Gentoo-prefix uses rpath instead of the LD_LIBRARY_PATH kludge, very good!
But this also means that there
On Wed, Dec 15, 2010 at 2:33 AM, Georg S. Weber
wrote:
> On 14 Dez., 16:36, Dima Pasechnik wrote:
>> actually, this idea won't fly on OSX, IMHO.
>> Using a non-Xcode compiler on OSX looks next to impossible.
>>
>
>
> On OS X,
>
> the approach to "include our own GCC 4.5.1" is doomed to fail.
> We
On 14 Dez., 16:36, Dima Pasechnik wrote:
> actually, this idea won't fly on OSX, IMHO.
> Using a non-Xcode compiler on OSX looks next to impossible.
>
On OS X,
the approach to "include our own GCC 4.5.1" is doomed to fail.
We could ship our own gcc-apple 4.2.1 for all supported Mac platforms
(1
actually, this idea won't fly on OSX, IMHO.
Using a non-Xcode compiler on OSX looks next to impossible.
On Dec 14, 10:56 pm, kcrisman wrote:
> Will a newer gcc work on older processors? I assume so, even with
> building gcc with an older gcc. I would be happy to test a sample
> proof-of-concept
Will a newer gcc work on older processors? I assume so, even with
building gcc with an older gcc. I would be happy to test a sample
proof-of-concept tarball on OS X PPC. If you get it to me before the
end of next week, at least.
- kcrisman
--
To post to this group, send an email to sage-devel
/Slightly/ related thread: (Shipping C, C++, Fortran libraries with
bdists):
http://groups.google.com/group/sage-devel/t/47ab4370e253306e
("Add 'gcc' libraries to Sage binaries (< 0.5% bloat)", from February)
-Leif
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsu
On 14 Dez., 09:21, leif wrote:
> Hmmm, couldn't resist, but ...
>
> ...
> libtool: link: ranlib .libs/libsupc++convenience.a
> rm: cannot remove `libsupc++convenience.la': No such file or directory
> libtool: link: ( cd ".libs" && rm "libsupc++convenience.la" && ln -s
> "../libsupc++convenience.la
On 14 Dez., 09:42, Jeroen Demeyer wrote:
> On 2010-12-14 05:59, David Kirkby wrote:
>
> > Cons:
> > * It would make Sage 1.6 MB larger
> > * It would slow builds on any system where the Sage gcc was used in
> > preference to a system one.
>
> Building gcc takes a huge amount of time. I guess
On 14 Dez., 06:30, leif wrote:
> An absolutely great idea.
>
> One problem remains: If we ship a more recent GCC, we still need to
> build GMP/MPIR, perhaps also MPFR and MPC, with the system's C
> compiler, preferably some GCC version, at least for bootstrapping our
> compiler.
>
> (Btw., I faile
On 14 Dez., 05:59, David Kirkby wrote:
> If anyone said including our own compiler with Sage is taking the
> "batteries included" approach too far, I would NOT disagree with them,
>
> But there do appear to be issues which may be difficult / impossible
> to resolve with Sage upgrades using gcc tha
19 matches
Mail list logo
