xcode and gcc
William Stein
Earlier today I was arguing that we need to support Xcode 4.x, etc.,
in the context of the PARI bugs.
I'm sitting here with a grad student with a solid Mac running OS X
10.6.8, and trying to get XCode 3.x on it is HELL.
None of our Apple ID's work for the Developer network, etc. We can't
find a download. Anyway, it is frustrating.
The App store only supports 4.x.
I'm just curious if anybody has looked into the possibility of us
distributing our own build of GCC, which is good enough to build Sage
and use Cython.
Incidentally, the only reason he needs XCode is because our "sage -b"
build system is really stupid. If you do
"sage -b"
and don't have a compiler, it will die, even if you aren't doing
anything with Cython. He just wants to write some .py files.
http://trac.sagemath.org/sage_trac/ticket/12365
-- William
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
Jeroen Demeyer
Christopher Swenson
--
To post to this group, send an email to sage-...@googlegroups.com
To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
William Stein
<ch...@caswenson.com> wrote:
> -1 for distributing our own version of gcc.
>
> As someone who has been peripherally involved with this sort of thing at
> Google, here are some downsides:
>
> 1) several hours of extra compiling and testing (a full boostrap build of
> GCC can be very painful, and running every test can take a very long time)
We're not including it with Sage. We would make it available since
XCode is such a pain in the ass (and is not free). That Cython
and even "sage -b" don't work without having to pay Apple additional
money, gets in the way of our goals for Sage.
> 2) you are going to have to start throwing more and more things into spkgs
> as other things break (binutils comes to mind)
That's why we are here.
> 3) you *still* have to have a C compiler already on the system to compile
> the stupid thing anyway :)
That's only on the system that we build the package on. No users will
need that C compiler.
Given that the main issue we are trying to address is installing the
right compiler, I don't
see this as a problem.
Also, it will be nice since we can include gfortran in our gcc spkg,
and completely remove the
binary fortran spkg from Sage.
> 4) people will constantly ask why you didn't choose clang + llvm
No choice has been made. So far I have a choice of zero working
options. When I have >= 2, I can
make a choice.
> 5) why don't you choose clang + llvm?
:-)
Christopher Swenson
Jeroen Demeyer
> 5) why don't you choose clang + llvm?
Jeroen Demeyer
> I might look into this. I will try a proof-of-concept test on bsd.
PARI with it, PARI passes all tests.
I'd like to try an OS X 10.7 machine if anybody can give me access to
such a machine.
kcrisman
> XCode is such a pain in the ass (and is not free). That Cython
> and even "sage -b" don't work without having to pay Apple additional
> money, gets in the way of our goals for Sage.
files.
> Also, it will be nice since we can include gfortran in our gcc spkg,
> and completely remove the
> binary fortran spkg from Sage.
So the idea would be that one would develop on Mac by doing
./sage -i gcc
./sage -b
?
- kcrisman
William Stein
Yes! No screwing with joining the Apple developer network, paying
$5, installing > 1GB, etc., just to get GCC.
Also, we could have a dmg available that would install GCC (including
gfortran) somewhere, and could be used to build Sage on OS X.
william
>
> ?
>
>
> - kcrisman
William Stein
I'm sitting next to bsd.math, typing on my OS X 10.7 laptop. I can
try this out for you ?
Where did you do your gcc-4.4.6 build on bsd.math? I can't find one in
your home directory, /scratch, or /tmp.
William
David Roe
>
> ./sage -i gcc
> ./sage -b
+1
David
Jeroen Demeyer
gcc.spkg and have it compile gcc, gfortran on systems where this is
needed. The size of the gcc spkg would roughly be the same as the
current fortran spkg.
On bsd, I compiled gfortran-4.4.6 from source, compiled the Sage LAPACK
with it and it seemed to work.
Georg S. Weber
unlike OS X 10.7 Lion (for which no official install DVDs exist), OS X
10.6 Snow Leopard came with/on a install DVD (either with the Mac when
one bought it, or when one bought Snow Leopard later). And on those
DVD(s), there is also the XCode 3.x package --- to the best of my
knowledge, this hold for all versions of OS X 10.6 Snow Leopard.
As a second possibility, one can sign up for a free account to the
Apple Development network (ADC) --- note that this has nothing to do
with the Apple App Store or your Apple ID. There, XCode up to XCode
3.2.6 should be downloadable (I didn't check recently, but why would
Apple change that). I got myself e.g.
"xcode25_8m2558_developerdvd.dmg" and "xcode322_2148_developerdvd.dmg"
from there (the latest should be some "xcode326....dmg").
If you don't need the standard Unix development tools coming with
XCode (such as "make", "autoconf", etc.), but "only" need some gcc,
and you are on OS X 10.7, you can download and install the Apple gcc
v4.2.1 version (build 5666.3) from http://r.research.att.com/tools/
e.g. as a nice package "gcc-42-5666.3-darwin11.pkg" (link near the
middle of that page under the title "Apple Xcode gcc-42 add-ons"). I
didn't check whether it installs without XCode though, but I don't see
any reason why it shouldn't (I did install it under a OS X 10.7.2
install with XCode 4.2.1, so can confirm that it works in such a
scenario). Note that this installs "only" some /usr/bin/gcc-4.2 etc.,
so you'll need at least additionally something like:
sudo ln -sf /usr/bin/gcc-4.2 /usr/bin/gcc
and
sudo ln -sf /usr/bin/g++-4.2 /ust/bin/g++
Unfortunately, this might not work for OS X 10.6 (I didn't test it
there). If not, one could give a try to "gcc-42-5553-darwin8-
all.tar.gz" (targetting OS X 10.4, but might work on OS X 10.6, too)
from the the same page/site --- unfortunately, the R project does not
provide all nice-to-have combinations of the tools there, e.g.
especially gfortran for/with Apple gcc build 5666.3 specifically built
for OS X 10.6 Snow Leopard. BTW, the sources of this are all free and
available, but you'd have to bootstrap somehow ... or we'll just ask
the R folks to update their tool page to include a "gcc-42-5666.3-
darwin10.pkg" (as it would be have to be named --- darwin11 == 10.7,
darwin10 == 10.6, ..., darwin8 == 10.4).
Of course there are also MacPorts, Gentoo Prefix, Homebrew and the
like. Maybe we should create and provide some "easy-to-install"
minimal binary installation of "just what Sage needs on OS X"
available for exactly the purpose you started your post for (i.e. an
official Sage project alternative to saying "go install XCode" on OS
X). Restricting ourselves to 64bit OS 10.6 or higher (i.e. currently
OS X 10.6 and 10.7), and targetting primarily Sage "binary
installs" (i.e. not claiming to be fully able to build a Sage source
distribution), creating such a "dev tools dmg" binary installation is
pretty straightforward. I don't know enough of Homebrew, but I boldly
claim to be able to do so myself for the first two, i.e. MacPorts and
Gentoo Prefix (famous last words (tm) :-) ).
Is there a need for something like that? Any votes?? More thoughts???
(Incidentally, this also touches the topic of that other recent post
http://groups.google.com/group/sage-devel/browse_thread/thread/11a8eedde829cf0d#
about "Please someone upgrade sagenb so it has R graphics support"---
see the R tool page about "cairo", under "Optional tools and
libraries".)
Cheers,
Georg
William Stein
<georg...@googlemail.com> wrote:
> Hi William,
>
> unlike OS X 10.7 Lion (for which no official install DVDs exist), OS X
> 10.6 Snow Leopard came with/on a install DVD (either with the Mac when
> one bought it, or when one bought Snow Leopard later). And on those
> DVD(s), there is also the XCode 3.x package --- to the best of my
> knowledge, this hold for all versions of OS X 10.6 Snow Leopard.
Joe random student (actually named Jim) obviously doesn't have his
install DVD anymore. He bought his laptop 2 years ago and is sitting
in my office. Plus that XCode will be out of date, right -- full of
bugs.
> As a second possibility, one can sign up for a free account to the
> Apple Development network (ADC) --- note that this has nothing to do
> with the Apple App Store or your Apple ID. There, XCode up to XCode
> 3.2.6 should be downloadable (I didn't check recently, but why would
> Apple change that). I got myself e.g.
> "xcode25_8m2558_developerdvd.dmg" and "xcode322_2148_developerdvd.dmg"
> from there (the latest should be some "xcode326....dmg").
Should be != is.
This particular student (Jim again) couldn't get his apple id to work.
Apple said it was "compromised" and he was fighting with their system
to re-enable it. I guess he could get a new apple id though.
> If you don't need the standard Unix development tools coming with
> XCode (such as "make", "autoconf", etc.), but "only" need some gcc,
But that's exactly what we need, right? I assume by "don't" you mean "do"?
That's what I propose. And this would replace our current fortran
spkg (i.e., that would
no longer be needed).
> Restricting ourselves to 64bit OS 10.6 or higher (i.e. currently
> OS X 10.6 and 10.7), and targetting primarily Sage "binary
> installs" (i.e. not claiming to be fully able to build a Sage source
> distribution),
It must definitely be able to build Sage from source.
> creating such a "dev tools dmg" binary installation is
> pretty straightforward. I don't know enough of Homebrew, but I boldly
> claim to be able to do so myself for the first two, i.e. MacPorts and
> Gentoo Prefix (famous last words (tm) :-) ).
>
> Is there a need for something like that? Any votes?? More thoughts???
>
> (Incidentally, this also touches the topic of that other recent post
> http://groups.google.com/group/sage-devel/browse_thread/thread/11a8eedde829cf0d#
> about "Please someone upgrade sagenb so it has R graphics support"---
> see the R tool page about "cairo", under "Optional tools and
> libraries".)
I just did that for sagenb.org.
>
>
> Cheers,
> Georg
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
--
Dima Pasechnik
On Friday, 27 January 2012 04:15:32 UTC+8, William wrote:
Hi,Earlier today I was arguing that we need to support Xcode 4.x, etc.,
in the context of the PARI bugs.I'm sitting here with a grad student with a solid Mac running OS X
10.6.8, and trying to get XCode 3.x on it is HELL.
None of our Apple ID's work for the Developer network, etc. We can't
find a download. Anyway, it is frustrating.
William Stein
>
>
> On Friday, 27 January 2012 04:15:32 UTC+8, William wrote:
>>
>> Hi,
>>
>> Earlier today I was arguing that we need to support Xcode 4.x, etc.,
>> in the context of the PARI bugs.
>>
>> I'm sitting here with a grad student with a solid Mac running OS X
>> 10.6.8, and trying to get XCode 3.x on it is HELL.
>> None of our Apple ID's work for the Developer network, etc. We can't
>> find a download. Anyway, it is frustrating.
>
> it's still there: (you only need a free registration)
>
> https://developer.apple.com/devcenter/mac/index.action
It's still annoying that even this has to be done to just work on
Sage. I hope we can make it so "sage -b" works for Python code
without needing a compiler.
-- William
kcrisman
Fernando Perez
> Also, we could have a dmg available that would install GCC (including
> gfortran) somewhere, and could be used to build Sage on OS X.
+big_number
Even outside the context of Sage, when teaching purely 'scipy stack'
to students (many of whom have macs in US academia) it's really
frustrating to hit that stupid Xcode hurdle just so I can show them
how Cython works (or weave a little while back).
Just last wekend I was answering questions precisely on this for our
python bootcamp at Berkeley (http://register.pythonbootcamp.info), we
ended up disabling all weave/cython stuff because we were going to
drown in installation hassles (we had ~150 people).
If you guys can put out a gcc/gfortran installer for the Mac that's a
simple download, click, install, you'll benefit lots of people even
beyond Sage.
Back to the peanut gallery...
f
Georg S. Weber
so far, three distinct topics evolved in this thread:
1.
Make Sage not needing a C compiler, when one changed only .py files
and then types "sage -b". That's the topic of trac #12365 (see the
original post), and up to now, I read only supportive comments (to
which I say +1 also).
2.
Discussion of using the "LLVM-backend gcc" (or even the Clang compiler
itself, which amounts to almost to the same) versus using the "FSF-
backend gcc" for Sage, at least on OS X.
3.
Make Sage on OS X independent of having XCode installed.
I'll concentrate on this second and third points.
FWIW, on my OS X 10.7.2 partition I was able to build Sage-4.8 using
the "FSF-backend" gcc (using the R project's gcc42 package alluded to
above), and a ptestlong run only showed doctest failures in three
files (for which I failed to make up trac tickets up to now). William
had reported these failures (all seem to be numerical noise) elsewhere
in another thread for some "LLVM-backend gcc" OS X 10.7 test build of
his. But there he reported also failures in "interrupt.pyx", which I
didn't see with the "FSF-backend gcc" build of mine. IMHO, Sage should
be able to rely on either GCC (FSF-flavour) or else Clang --- we
really shouldn't target the "LLVM-flavour gcc", since support of this
might go away soon. The LLVM project says e.g. that as of their
current 3.0 release, "llvm-gcc is no longer supported" (see
http://llvm.org/releases/3.0/docs/ReleaseNotes.html), and Apple also
seems determined to replace it with Clang as soon as possible. This
leaves three alternatives:
a)
Stay with the old "FSF-flavor" Apple version of gcc v4.2.1 "build
5666.3", as has been included in XCode 3.2.6, 4.0. and 4.1 (but no
longer from 4.2 onwards), and that gcc42 package.
b)
Use newer FSF gcc's on OS X, e.g. gcc-4.4 (with the benefit of the
possibility to use an up-to-date gfortran also).
c)
Support building Sage with Clang (BTW, that's a general theme, which
is not restricted to OS X at all!) --- but both gfortran and g95 seem
to rely on the FSF gcc backends. Does any one know the status of
building some fortran compiler with/relying on nothing but Clang
(should be possible, since usually Fortran code is translated to C
code first, and only then compiled)?
Note that this still says next to nothing about point 3) above
(getting independent of XCode). If one wants to build Sage from source
on OS X, one needs not only "make" and such (which a vanilla OS X 10.7
install does not provide), but also certain library headers (which
e.g. on Debian would be in those "dev"-packages), and the like. I'm
not sure whether there is any solution for that available yet. (Both
MacPorts and Gentoo Prefix seem to require XCode at least for
bootstrapping themselves.)
Especially when interfacing with Cocoa/graphics is concerned (Python
itself does this, matplotlib, R, i.e. several non-trivial components
of Sage), the respective headers are needed, and it may very well be
that only XCode provides these in a "neatly downloadable" way (those
"SDKs").
One could patch all these parts out of Sage (they are "OS X only"
parts, after all, so Sage runs certainly without). I did that once to
get Sage building in 64bit on OS X 10.4 (for which those Cocoa parts
are supported only in 32bit), so it is definitely possible --- but
it's not some "minor" effort to get this ready for "prime-time"
mainline Sage releases, as you certainy want "plot" to show something
(maybe we would need Qt, or another alternative to Cocoa/Aqua
graphics)!
I'd modestly suggest staying with the requirement of XCode for
building Sage from source on OS X (merely using Sage, and doing Sage
library development, is something different, though).
Cheers,
Georg
Jason Grout
> If you guys can put out a gcc/gfortran installer for the Mac that's a
> simple download, click, install, you'll benefit lots of people even
> beyond Sage.
https://github.com/kennethreitz/osx-gcc-installer is one possible place
to look for gcc, at least.
Jason
Fernando Perez
<jason...@creativetrax.com> wrote:
> https://github.com/kennethreitz/osx-gcc-installer is one possible place to
> look for gcc, at least.
Nice, thanks! I didn't know about that, it's excellent and does help a lot.
Cheers,
f
R. Andrew Ohana
<georg...@googlemail.com> wrote:
> Hi,
>
> so far, three distinct topics evolved in this thread:
>
> 1.
> Make Sage not needing a C compiler, when one changed only .py files
> and then types "sage -b". That's the topic of trac #12365 (see the
> original post), and up to now, I read only supportive comments (to
> which I say +1 also).
However, if we do release a binary based upon this, it would need to
have a simple tool to switch toolchains, for developers who need to
use XCode for other projects (such as iPhone apps) -- I personally am
a fan of gentoo (prefix), which has the convenient gcc-config tool
that makes this super simple (although, it may have to be modified to
work with XCode).
> c)
> Support building Sage with Clang (BTW, that's a general theme, which
> is not restricted to OS X at all!) --- but both gfortran and g95 seem
> to rely on the FSF gcc backends. Does any one know the status of
> building some fortran compiler with/relying on nothing but Clang
> (should be possible, since usually Fortran code is translated to C
> code first, and only then compiled)?
+1 if feasible
However, according to Wikipedia (which is know to be always correct
:p) "For other languages, including Java, Fortran, and Ada, LLVM
remains dependent on GCC." [1]
>
>
> Note that this still says next to nothing about point 3) above
> (getting independent of XCode). If one wants to build Sage from source
> on OS X, one needs not only "make" and such (which a vanilla OS X 10.7
> install does not provide), but also certain library headers (which
> e.g. on Debian would be in those "dev"-packages), and the like. I'm
> not sure whether there is any solution for that available yet. (Both
> MacPorts and Gentoo Prefix seem to require XCode at least for
> bootstrapping themselves.)
However, we would only distribute a binary (most likely based upon
MacPorts or Gentoo Prefix) installer, so the bootstrapping process
should not be required from a users perspective (the only thing that
I'm not so sure about is libc).
> Especially when interfacing with Cocoa/graphics is concerned (Python
> itself does this, matplotlib, R, i.e. several non-trivial components
> of Sage), the respective headers are needed, and it may very well be
> that only XCode provides these in a "neatly downloadable" way (those
> "SDKs").
> One could patch all these parts out of Sage (they are "OS X only"
> parts, after all, so Sage runs certainly without). I did that once to
> get Sage building in 64bit on OS X 10.4 (for which those Cocoa parts
> are supported only in 32bit), so it is definitely possible --- but
> it's not some "minor" effort to get this ready for "prime-time"
> mainline Sage releases, as you certainy want "plot" to show something
> (maybe we would need Qt, or another alternative to Cocoa/Aqua
> graphics)!
>
> I'd modestly suggest staying with the requirement of XCode for
> building Sage from source on OS X (merely using Sage, and doing Sage
> library development, is something different, though).
-1 if feasible
Building sage from source is part of sage development, adding XCode as
a requirement will add a cost barrier (although minimal) to sage
development on OSX.
>
>
> Cheers,
> Georg
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
IMO I think that we should try to make Sage compatible with clang if
possible (including XCode's version), but I don't think that we should
make XCode a requirement (again if possible) for OSX. Ideally, I would
like to distribute (separately from sage) compatible toolchains on
systems where it is difficult for a user to install one freely (i.e.
OSX and Solaris).
[1] http://en.wikipedia.org/wiki/Clang
--
Andrew