Thanks for the invitation!

[gsw]

Hi Burcin,

I was already following the thread on gentoo-alt:

http://archives.gentoo.org/gentoo-alt/msg_a41a3f91236feb534218db02472e8a1f.xml

with great interest.
I got Gentoo prefix working on MacIntel both OS X 10.4 and OS X 10.6
(and have a MacPPC OS X 10.4 available, but it's only got a 0,55 GHz
CPU ...), but couldn't push through Chr. Schwans sage-on-prefix
overlay to successfully install, even with the help of Fr. Bissey.
So I'm excited to hear about "the next phase of the sage-prefix
project"!!

Cheers,
Georg

[Burcin Erocal]

Hi Georg,

welcome to the list and congratulations on the first post!

On Fri, 25 Nov 2011 03:55:36 -0800 (PST)
gsw <georg...@googlemail.com> wrote:

> I was already following the thread on gentoo-alt:
>
> http://archives.gentoo.org/gentoo-alt/msg_a41a3f91236feb534218db02472e8a1f.xml
>
> with great interest.

Oh, yes. I need to check the results of the Sage test suite on ia64 and
answer back. :)

Thanks for your support on sage-devel BTW. It came at a critical time.

> I got Gentoo prefix working on MacIntel both OS X 10.4 and OS X 10.6
> (and have a MacPPC OS X 10.4 available, but it's only got a 0,55 GHz
> CPU ...), but couldn't push through Chr. Schwans sage-on-prefix
> overlay to successfully install, even with the help of Fr. Bissey.

I'll answer the OSX stuff on another thread.

> So I'm excited to hear about "the next phase of the sage-prefix
> project"!!

There is still a lot to be done to match the features of the spkg
system, relocation, setting up development environments for
mathematical packages, etc. I have half working implementations for
these, but I can't keep up with maintaining the ebuilds and implement
new features at the same time.

This is partly because the tree is rather large. All the dependencies
of Sage are there. Though it's important to have Sage available as a
test case. It exercises many libraries, uses fortran, blas, lisp etc.
Without that, checking if compilerwrapper works honestly would have
been impossible.

Cheers,
Burcin

[Burcin Erocal]

Hi,

On Fri, 25 Nov 2011 03:55:36 -0800 (PST)
gsw <georg...@googlemail.com> wrote:

> I got Gentoo prefix working on MacIntel both OS X 10.4 and OS X 10.6
> (and have a MacPPC OS X 10.4 available, but it's only got a 0,55 GHz
> CPU ...), but couldn't push through Chr. Schwans sage-on-prefix
> overlay to successfully install, even with the help of Fr. Bissey.

I only have access to a 10.5 PPC, so I couldn't really try all
these options myself. I recently got funding to get a Mac for testing
lmonade. I don't know when it will be available though.

On the 10.5 PPC box, I didn't get everything working because of the
missing gfortran, but it went pretty far. The main problem seemed to be
missing keywords. Especially with the latest state of the
sage-on-gentoo tree, if you use --autounmask, it tries to pull
experimental polybori, linbox-1.1.7, etc. These don't work with Sage.

ATM, most OSX profiles are missing from the lmnd-prefix tree. Adding a
new profile is simple. You just need to create the correct directories
under profiles/ and update the file scripts/bootstrap-sage.sh with the
relevant lines from scripts/bootstrap-prefix.sh modified accordingly.

I'll try to put this information up on the wiki soon.

I'd be interested to hear your experiences trying things out on OSX.

Cheers,
Burcin

[François]

Hi George,

well I am on board too now! I never add access to the sage-on-prefix overlay and Christopher basically thought it was irrelevant some time ago.

But yes we need a few things for OS X.

The burden will be somewhat lower when:

python-2.7.3 is released

R is updated in sage

polybori-0.8 is included in sage (all these warnings we get will just go away or so Alexander Dryer promised me)

I have been very busy lately but I'll try to be at least a bit active in conversation here.

Francois

[François]

autounmask is sometimes too eager. But I should check the dependencies to lock in the right ones if necessary.

The packages you mention are a recent addition and we may not have planned properly for them.

Francois  

[gsw]

Well,

I hoped to get farther this weekend. At least I can say that
"compilerwrapper" is the first ebuild that currently wants to get
unmasked on OS X.
To be continued ...

Cheers,
Georg

[Francois Bissey]

I am updating some dependencies in sage-on-gentoo so that the
unmasking does the right thing. I don't think I have write access
to the new lmonad-prefix so burcin will have to pick up the changes.

I'll probably land 4.8.alpha2 in sage-on-gentoo in a few hours.

Francois

This email may be confidential and subject to legal privilege, it may
not reflect the views of the University of Canterbury, and it is not
guaranteed to be virus free. If you are not an intended recipient,
please notify the sender immediately and erase all copies of the message
and any attachments.

Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more
information.

[Burcin Erocal]

Hi Georg,

On Sun, 27 Nov 2011 15:01:38 -0800 (PST)
gsw <georg...@googlemail.com> wrote:

> I hoped to get farther this weekend. At least I can say that
> "compilerwrapper" is the first ebuild that currently wants to get
> unmasked on OS X.
> To be continued ...

What did it choose for your profile? What is the link
local/etc/make.profile pointing to?

I just added the x86-macos keyword to compilerwrapper. Now it should
get through bootstrap and fail with missing keywords when checking the
dependencies for Sage.

Cheers,
Burcin

[gsw]

On 28 Nov., 23:46, Burcin Erocal <bur...@erocal.org> wrote:
> Hi Georg,
>
> On Sun, 27 Nov 2011 15:01:38 -0800 (PST)
>

> gsw <georgswe...@googlemail.com> wrote:
> > I hoped to get farther this weekend. At least I can say that
> > "compilerwrapper" is the first ebuild that currently wants to get
> > unmasked on OS X.
> > To be continued ...
>
> What did it choose for your profile? What is the link
> local/etc/make.profile pointing to?
>

For my first test setup, it points to ".../dist/portage/profiles/sage/
darwin/macos/10.6/x86/"
It should be "x64" at the end, however ... I may and I want to use
64bit OS X 10.6.

> I just added the x86-macos keyword to compilerwrapper. Now it should
> get through bootstrap and fail with missing keywords when checking the
> dependencies for Sage.
>
> Cheers,
> Burcin

I think I'll start all over again. I got rather far, but I didn't use
"configure" and thus no "make", but instead the ./dist/portage/scripts/
install.sh shellscript. (In the meantime, I got the impression that
this is just a leftover, is it?) Next I'll use the "configure" way.

For the record: I could emerge all but 20 packages, the three
remaining blockers are openssl, blas-reference, and polybori. The
first two might "go away" rather easy, given that they are both "x64-
macos" keyworded (and I think I already had them working in some
prefix). Polybori gives me a headache, though, dying with:

g++ -o polybori/src/DegRevLexAscOrder.o -c -march=nocona -fno-strict-
aliasing -DNDEBUG -DSIZEOF_VOID_P=8 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -
DHAVE_GD -DHAVE_HASH_MAP -DPACKED -DHAVE_M4RI -DSIZEOF_VOID_P=8 -
DSIZEOF_LONG=8 -DHAVE_IEEE_754 -ICudd/epd -ICudd/st -ICudd/mtr -ICudd/
cudd -ICudd/obj -ICudd/util -Ipolybori/include -Igroebner/include -I/
Users/Shared/lmnd/lmnd-test01/local/usr/include/python2.7 polybori/src/
DegRevLexAscOrder.cc
Undefined symbols:
"_gdImageSetPixel", referenced from:
polybori::groebner::drawmatrix(mzd_t*, char const*)in nf.os
"_gdImageColorAllocate", referenced from:
polybori::groebner::drawmatrix(mzd_t*, char const*)in nf.os
polybori::groebner::drawmatrix(mzd_t*, char const*)in nf.os
"_gdImageDestroy", referenced from:
polybori::groebner::drawmatrix(mzd_t*, char const*)in nf.os
"_gdImageFilledRectangle", referenced from:
polybori::groebner::drawmatrix(mzd_t*, char const*)in nf.os
"_gdImageCreate", referenced from:
polybori::groebner::drawmatrix(mzd_t*, char const*)in nf.os
"_gdImagePng", referenced from:
polybori::groebner::drawmatrix(mzd_t*, char const*)in nf.os
ld: symbol(s) not found
collect2: ld returned 1 exit status
scons: *** [libgroebner.dylib] Error 1
scons: building terminated because of errors.
* ERROR: sci-mathematics/polybori-0.7.1 failed (compile phase):
* (no error message)

Any ideas?

Cheers,
Georg

[Francois Bissey]

I believe that somehow your compile line is missing -lgd you should
check your use flags and whether media-gfx/gd has been installed.

Francois

[Alexander Dreyer]

Hi everybody!

> I believe that somehow your compile line is missing -lgd you should
> check your use flags and whether media-gfx/gd has been installed.

It would be useful to see the full ebuild log (HAVE_GD and -lgd should
be consistent).

Regards,
Alexander

--
Dr. rer. nat. Dipl.-Math. Alexander Dreyer

Abteilung "Systemanalyse, Prognose und Regelung"
Fraunhofer Institut f�r Techno- und Wirtschaftsmathematik (ITWM)
Fraunhofer-Platz 1
67663 Kaiserslautern

Telefon +49 (0) 631-31600-4318
Fax +49 (0) 631-31600-1099
E-Mail alexande...@itwm.fraunhofer.de
Internet http://www.itwm.fraunhofer.de/sys/dreyer.html

[Burcin Erocal]

On Thu, 1 Dec 2011 13:43:00 -0800 (PST)
gsw <georg...@googlemail.com> wrote:

> On 28 Nov., 23:46, Burcin Erocal <bur...@erocal.org> wrote:

> > What did it choose for your profile? What is the link
> > local/etc/make.profile pointing to?
> >
>
> For my first test setup, it points to ".../dist/portage/profiles/sage/
> darwin/macos/10.6/x86/"
> It should be "x64" at the end, however ... I may and I want to use
> 64bit OS X 10.6.

gentoo-prefix picks 32-bit builds by default.

http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-macos.xml

The paragraph after code listing 1.2 says:

If you want to end up with a 64-bits native Prefix installation,
then set your CHOST variable accordingly to x86_64-apple-darwin9
for Leopard, x86_64-apple-darwin10 for Snow Leopard, or
x86_64-apple-darwin11 for Lion. You only need to do this if you
want a 64-bits native Prefix!

We'll need to add a new configure option, which enables 64-bit by
setting the CHOST variable before calling the bootstrap-sage.sh
script. Note that bootstrap-sage.sh is a wrapper around
bootstrap-prefix.sh. Actual code for most functions is in the latter.

We could still use the code in bootstrap-prefix.sh [1] to guess an
initial value for CHOST. This can be obtained by calling the script
with chost.guess as an argument:

$ scripts/bootstrap-sage.sh chost.guess /bogus/absolute/path
x86_64-pc-linux-gnu

[1]
https://bitbucket.org/burcin/lmnd-prefix/src/e58a371641fb/scripts/bootstrap-prefix.sh#cl-894

> > I just added the x86-macos keyword to compilerwrapper. Now it should
> > get through bootstrap and fail with missing keywords when checking
> > the dependencies for Sage.
> >
> > Cheers,
> > Burcin
>
>
> I think I'll start all over again. I got rather far, but I didn't use
> "configure" and thus no "make", but instead
> the ./dist/portage/scripts/ install.sh shellscript. (In the meantime,
> I got the impression that this is just a leftover, is it?) Next I'll
> use the "configure" way.

Yes, it was there just in case the transition to waf didn't cover
everything. In the mean time, the waf script in wscript grew to do much
more.

> For the record: I could emerge all but 20 packages, the three
> remaining blockers are openssl, blas-reference, and polybori. The
> first two might "go away" rather easy, given that they are both "x64-
> macos" keyworded (and I think I already had them working in some
> prefix).

polybori and openssl should be easy to resolve.

AFAIR, blas-reference needs gfortran which is still an unsolved
problem. Since we don't want to build gcc, we will have to distribute a
binary gfortran like Sage. I still haven't managed to find a binary for
a fortran compiler which also works with compilerwrapper.

As a first try, I added a g95-bin ebuild to the tree based on an ebuild
Francois posted to the gentoo forums a long time ago. This didn't work
on my 10.5 ppc box. It had the path of the linker hardcoded
as /usr/bin/libtool and wanted to pass arguments that were not
supported by that version. Perhaps an older version would work on that
computer. I didn't try that yet.

I also tried extracting the contents of the dmg file found on this page:

http://r.research.att.com/tools/

and using those files as the compiler. This somehow builds the location
for libgfortran.2.dylib into the programs it compiles. config.log has
the following:

configure:2830: checking whether the Fortran 77 compiler works
configure:2852: powerpc-apple-darwin9-gfortran -Wl,-dead_strip_dylibs
conftest.
f >&5
configure:2856: $? = 0
configure:2904: result: yes
configure:2907: checking for Fortran 77 compiler default output file
name
configure:2909: result: a.out
configure:2915: checking for suffix of executables
configure:2922: powerpc-apple-darwin9-gfortran -o conftest
-Wl,-dead_strip_dylibs conftest.f >&5
configure:2926: $? = 0
configure:2948: result:
configure:2964: checking whether we are cross compiling
configure:2972: powerpc-apple-darwin9-gfortran -o conftest
-Wl,-dead_strip_dylibs conftest.f >&5
configure:2976: $? = 0
configure:2983: ./conftest
dyld: Library not loaded: /usr/local/lib/libgfortran.2.dylib
Referenced
from: /Users/burcin/tprefix/prefix-20111115/dist/tmp/portage/sci-li
bs/blas-reference-20070226-r2/work/lapack-lite-3.1.1/./conftest
Reason: image not found
./configure: line 2985: 73328 Trace/BPT
trap ./conftest$ac_cv_exeext
configure:2987: $? = 133
configure:2994: error: in
`/Users/burcin/tprefix/prefix-20111115/dist/tmp/portag
e/sci-libs/blas-reference-20070226-r2/work/lapack-lite-3.1.1':
configure:2996: error: cannot run Fortran 77 compiled programs.

All this with DYLD_FALLBACK_LIBRARY_PATH containing

/Users/burcin/test/usr/local/lib

where libgfortran.2.dylib actually is.

Cheers,
Burcin

[gsw]

Hi,

thanks for all the helpful comments!

>>> gentoo-prefix picks 32-bit builds by default.

Therefore, I decided to attempt to build everything 32bit, but was not
consequent enough. The problem is, that the default mechanisms do pick
"32bit", but they do not really know that the wrapped compiler has to
be told so. So I got past bootstrapping (this time the "configure/Waf"
way --- the only difference to "install.sh" was that the "startprefix"
script now is generated and placed one level deeper under /local/,
i.e. in $EPREFIX, not in the root directory), but then gmp checked for
the size of long, which was 8 instead of 4, and choked (rightfully). I
tried to add "-m32" to my CFLAGS, but too late --- parts of the system
were already built. And when I tried to rebuild with "emerge world --
nodeps", one of the first things rebuilt was zlib, and now the
installation is broken, because Python can't find anymore a suitable
zlib library (with the right ABI), and everything depends on a working
Python --- hehehe. I'll start my next (third) attempt tomorrow, from
scratch.

As for the fortran problem, I'll try the "Sage way". Deep hidden in
the "fortran-20100629" spkg, there is some "gfortran-4.2.3.tar.bz2",
which just is to be unpacked in /local/ --- see spkg-install. (And
then I'll remove the script "gfortran" and rename "gfortran-64" back
to "gfortran", because I'm going for 32bit). It seems that this
originates from http://r.research.att.com/tools/ , too (the spkg
documentation is suboptimal in this respect).

Cheers,
Georg

P.S.:
@François, Alexander:

With my first install, I tried on the one hand:
USE="sage -doc -gd" emerge -D polybori

and on the other hand, after emerging "media-libs/gd":
USE="sage -doc gd" emerge -D polybori

but in all cases, many lines show up with the "-DHAVE_GD" option, and
at the same time the "-lgd" option seems finally to be missing.
Should I go for making the "-DHAVE_GD" vanish, or rather for "-lgd" to
appear?

The scons call is always a bit lengthy and seems to duplicate options:
>>> Source configured.

>>> Compiling source in /Users/Shared/lmnd/lmnd-test01/dist/tmp/portage/sci-mathematics/polybori-0.7.1/work/polybori-0.7 ...

scons -j6 CC=gcc CXX=g++ CFLAGS=-march=nocona -fno-strict-aliasing
CCFLAGS= CXXFLAGS=-march=nocona -fno-strict-aliasing LINKFLAGS=-Wl,-
dead_strip_dylibs HAVE_HEVEA=False HAVE_L2H=False HAVE_TEX4HT=False
HAVE_DOXYGEN=False HAVE_PYDOC=False MANDIR=/Users/Shared/lmnd/lmnd-
test01/dist/tmp/portage/sci-mathematics/polybori-0.7.1/image/Users/
Shared/lmnd/lmnd-test01/local//usr/share/man PREFIX=/Users/Shared/lmnd/
lmnd-test01/dist/tmp/portage/sci-mathematics/polybori-0.7.1/image/
Users/Shared/lmnd/lmnd-test01/local//usr PYINSTALLPREFIX=/Users/Shared/
lmnd/lmnd-test01/dist/tmp/portage/sci-mathematics/polybori-0.7.1/image/
Users/Shared/lmnd/lmnd-test01/local//usr/lib/python2.7/site-packages
INSTALLDIR=/Users/Shared/lmnd/lmnd-test01/dist/tmp/portage/sci-
mathematics/polybori-0.7.1/image/Users/Shared/lmnd/lmnd-test01/local//
usr/share/polybori CONFFILE=/Users/Shared/lmnd/lmnd-test01/dist/tmp/
portage/sci-mathematics/polybori-0.7.1/image/Users/Shared/lmnd/lmnd-
test01/local//usr/share/polybori/flags.conf INSTALL_NAME_DIR=/Users/
Shared/lmnd/lmnd-test01/local/usr/lib/ HAVE_PYTHON_EXTENSION=False
EXTERNAL_PYTHON_EXTENSION=True FORCE_HASH_MAP=True
SHLIBVERSIONING=False CC=gcc CXX=g++ CFLAGS=-march=nocona -fno-strict-
aliasing CCFLAGS= CXXFLAGS=-march=nocona -fno-strict-aliasing
LINKFLAGS=-Wl,-dead_strip_dylibs HAVE_HEVEA=False HAVE_L2H=False
HAVE_TEX4HT=False HAVE_DOXYGEN=False HAVE_PYDOC=False MANDIR=/Users/
Shared/lmnd/lmnd-test01/dist/tmp/portage/sci-mathematics/
polybori-0.7.1/image/Users/Shared/lmnd/lmnd-test01/local//usr/share/
man PREFIX=/Users/Shared/lmnd/lmnd-test01/dist/tmp/portage/sci-
mathematics/polybori-0.7.1/image/Users/Shared/lmnd/lmnd-test01/local//
usr PYINSTALLPREFIX=/Users/Shared/lmnd/lmnd-test01/dist/tmp/portage/
sci-mathematics/polybori-0.7.1/image/Users/Shared/lmnd/lmnd-test01/
local//usr/lib/python2.7/site-packages INSTALLDIR=/Users/Shared/lmnd/
lmnd-test01/dist/tmp/portage/sci-mathematics/polybori-0.7.1/image/
Users/Shared/lmnd/lmnd-test01/local//usr/share/polybori CONFFILE=/
Users/Shared/lmnd/lmnd-test01/dist/tmp/portage/sci-mathematics/
polybori-0.7.1/image/Users/Shared/lmnd/lmnd-test01/local//usr/share/
polybori/flags.conf INSTALL_NAME_DIR=/Users/Shared/lmnd/lmnd-test01/
local/usr/lib/ HAVE_PYTHON_EXTENSION=False
EXTERNAL_PYTHON_EXTENSION=True FORCE_HASH_MAP=True
SHLIBVERSIONING=False prepare-install prepare-devel

scons: Reading SConscript files ...

[Francois Bissey]

> P.S.:
> @François, Alexander:
>
> With my first install, I tried on the one hand:
>     USE="sage -doc -gd" emerge -D polybori
>
> and on the other hand, after emerging "media-libs/gd":
>     USE="sage -doc gd" emerge -D polybori
>
> but in all cases, many lines show up with the "-DHAVE_GD" option, and
> at the same time the "-lgd" option seems finally to be missing.
> Should I go for making the "-DHAVE_GD" vanish, or rather for "-lgd" to
> appear?
>

Just checked my log on Gentoo and I think we don't add -lgd for this
particular compilation. It should only be needed at linking time. I will
have to look at what happens in my gentoo-prefix on OS X.
I wonder why it wants -lgd here.

Francois

[Alexander Dreyer]

Hi Francois, hi Georg,

> Just checked my log on Gentoo and I think we don't add -lgd for this
> particular compilation. It should only be needed at linking time. I will
> have to look at what happens in my gentoo-prefix on OS X.
> I wonder why it wants -lgd here.

I think the problem is, that recent OSXs wants -lgd when generating
dylibs. (This used to be different in 10.5, and is different on my main
development platform Linux.)

I'm about to prepare a patch for this.

@Georg: As long as PolyBoRi finds libgd it will enforce HAVE_GD.
Passing GD_LIBS="" to scons if USE="-gd" switches that off.

Best regards,

[Francois Bissey]

> Hi Francois, hi Georg,
>
> > Just checked my log on Gentoo and I think we don't add -lgd for this
> > particular compilation. It should only be needed at linking time. I will
> > have to look at what happens in my gentoo-prefix on OS X.
> > I wonder why it wants -lgd here.
>
> I think the problem is, that recent OSXs wants -lgd when generating
> dylibs. (This used to be different in 10.5, and is different on my main
> development platform Linux.)
>

That's why I am wondering what's happening. He is creating a .o for the
static library, he is not creating a dylib in which I would understand.
Could it be the fact that we are creating a static object? In which case
may be what is missing is a static libgd?

Francois

[Alexander Dreyer]

Hi Francois,

> That's why I am wondering what's happening. He is creating a .o for the
> static library, he is not creating a dylib in which I would understand.
> Could it be the fact that we are creating a static object? In which case
> may be what is missing is a static libgd?

I think compiling the .o has nothing to do with the problem (scons
doesn't complain about that target, but about the dylib). Possibly, the
line compiling the .o file is most recent one because of a parallel build.

Regards,

[Francois Bissey]

> Hi Francois,
>
> > That's why I am wondering what's happening. He is creating a .o for the
> > static library, he is not creating a dylib in which I would understand.
> > Could it be the fact that we are creating a static object? In which case
> > may be what is missing is a static libgd?
>
> I think compiling the .o has nothing to do with the problem (scons
> doesn't complain about that target, but about the dylib). Possibly, the
> line compiling the .o file is most recent one because of a parallel build.
>

That would make sense. In that case we are just missing a lot of log that
would be useful.

Cheers,
Francois

[Francois Bissey]

> Hi Francois,
>
> > That's why I am wondering what's happening. He is creating a .o for the
> > static library, he is not creating a dylib in which I would understand.
> > Could it be the fact that we are creating a static object? In which case
> > may be what is missing is a static libgd?
>
> I think compiling the .o has nothing to do with the problem (scons
> doesn't complain about that target, but about the dylib). Possibly, the
> line compiling the .o file is most recent one because of a parallel build.
>

Actually, I based my initial diagnostic of missing "-lgd" on that compilation
line alone rather than the complete log. So for all we know, if you are right
about the parallel compilation, -lgd is there (possibly up to 4 times) and
there is a more subtle problem with the linking.

So we really need to have more info before fixing polybori when may be the gcc
wrapper should be fixed.

Cheers,
Francois

[Alexander Dreyer]

Hi Francois,

> Actually, I based my initial diagnostic of missing "-lgd" on that
> compilation
> line alone rather than the complete log. So for all we know, if you are
> right
> about the parallel compilation, -lgd is there (possibly up to 4 times) and
> there is a more subtle problem with the linking.

But it was not there, where compiling libgroebner.dylib. This was fixed
some time ago in 0.8 (but we are still waiting for 0.8 to be included
into Sage, due to a dependency on a patch, which was unfortunately
de-merged after the PolyBoRi upgrade ticket was positively reviewed
already).

I backported that part to 0.7.1 (see the lmonade-repo). Also, libgd
sometimes depends on other libraries, like libpng. So we check now,
whether linking succeeds. Otherwise the optional gd-based features are
skipped.

> So we really need to have more info before fixing polybori when may be
> the gcc
> wrapper should be fixed.

Of course, this could cause more trouble. But Georg should test the most
recent repo version, since that patch had already fixed the problem for 0.8.

[gsw]

(For Alexander and François: see #16 below.)

Recipe to bootstrap current (Dec 4th, 2011) lmnd-prefix on (some)
MacIntels,
as "32 bit" (x86-macos) system.
Use on your own risk. Your mileage may vary.

0. OS X 10.6.8, on a Core2Duo (alternatively QuadCore) Intel system,
with XCode 3.2.6,
"gcc --version" gives among other information:
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666)
(dot 3)
"python --version" gives:
Python 2.6.1
"bash --version" gives (among other information):
version 3.2.48(1)-release

Check that your CFLAGS and LDFLAGS environment variables are empty.
Bootstrapping will be done in two phases, the first one using the
host build environment, the second the new guest build environment.
The latter, starting with emerging the compiler wrapper, will need
CFLAGS and LDFLAGS to be set to certain values.
But if one does this right at the beginning, both the builds for
Bash v4.1
and "Python-2.7.2-patched" (built in the first phase) wouldn't
succeed!

1. go to some Sage installation directory, and enter a Sage shell "./
sage -sh"
(needed only for hg, if you don't have a system-wide hg, like me)

2. create (or update) a lmnd repository in /Users/Shared/lmnd/mlnd-
repository/
(say), by cd'ing into that directory and doing
"hg clone https://bitbucket.org/burcin/lmnd-prefix"
(or, after cd'ing under an existing "lmnd-prefix/" , do there:
"hg pull https://bitbucket.org/burcin/lmnd-prefix", followed by
"hg update")

3. create some testdir, say /Users/Shared/lmnd/lmnd-test05/
cd to it,
and do
"../lmnd-repository/lmnd-prefix/create_test_dir.sh"
(for this again some "hg" command must be available, see inside
that script)

4. exit the Sage shell, cd (again) into /Users/Shared/lmnd/lmnd-
test05/
(no more "hg" will be necessary in the following)

5. (optional, but saves both space and time) populate the directory
/Users/Shared/lmnd/lmnd-test05/dist/distfiles/
with the more than half a GB of files fetched in earlier attempts

6. ./configure --flavor=plain
("plain" will just bootstrap a plain "bare" prefix)

7. make
I do not really understand why (the ebuild seems to have the
correct
resp. necessary keywords), but the build will halt with:
.
.
.
[16/24] EmergePackage:
Calculating dependencies... done!
[ebuild N *] sys-devel/compilerwrapper-1.3-r4

The following keyword changes are necessary to proceed:
#required by compilerwrapper (argument)
=sys-devel/compilerwrapper-1.3-r4 **

NOTE: The --autounmask-keep-masks option will prevent emerge
from creating package.unmask or ** keyword changes.

Use --autounmask-write to write changes to config files (honoring
CONFIG_PROTECT).
Waf: Leaving directory `/Users/Shared/lmnd/lmnd-test04/dist/waf_build'
Build failed
-> task failed (exit status 1): EmergePackage compilerwrapper
''
make: *** [build] Error 1
.
.
.

8. Create the directory (if it doesn't exist already)
/Users/Shared/lmnd/lmnd-test05/local/etc/portage/
and under it the file
/Users/Shared/lmnd/lmnd-test05/local/etc/portage/
package.accept_keywords
with the contents:

#required by compilerwrapper (argument)
>=sys-devel/compilerwrapper-1.3-r4 **

9. make
The build stops almost immediately again, this time with:
.
.
.
checking build system type... i686-apple-darwin10
checking for i686-apple-darwin10-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/Users/Shared/lmnd/lmnd-test04/dist/tmp/portage/
sys-devel/compilerwrapper-1.3-r4/work/compilerwrapper-be20111116':
configure: error: C compiler cannot create executables
See `config.log' for more details

!!! Please attach the following file when seeking support:
!!! /Users/Shared/lmnd/lmnd-test04/dist/tmp/portage/sys-devel/
compilerwrapper-1.3-r4/work/compilerwrapper-be20111116/config.log
.
.
.

10. The mechanisms inherited from Gentoo Prefix default to 32bit
installations
on Mac OS. Since the compilerwrapper does not (yet) handle this
gracefully
on my OS X 10.6, we now hammer those nails in (but not earlier!):

export CFLAGS="-m32"
export CXXFLAGS="${CFLAGS}"
export LDFLAGS="-arch i386"

export USE="-aqua"

The first three are necessary in order to have a sane C/C++ guest
build
environment, the latter prevents later Python builds to try to
drag in
"framework" stuff, which (at least on my system) would break with:
.
.
.
* Bootstrapping Sage installation using
* host: i386-apple-darwin10
* base: /Users/Shared/lmnd/lmnd-test03/dist/tmp
* ready to bootstrap python
* Bootstrapping python-2.7.2
* Fetching python-2.7.2-patched.tar.bz2
--12:07:41-- http://www.lmona.de/files/distfiles/python-2.7.2-patched.tar.bz2
=> `python-2.7.2-patched.tar.bz2'
.
.
.
gcc -o python.exe \
Modules/python.o \
libpython2.7.a -ldl -framework CoreFoundation
ld: warning: in Modules/python.o, file was built for i386 which is not
the architecture being linked (x86_64)
ld: warning: in libpython2.7.a, file was built for unsupported file
format which is not the architecture being linked (x86_64)
Undefined symbols:
"_main", referenced from:
__start in crt1.o

ld: symbol(s) not found
collect2: ld returned 1 exit status

make[1]: *** [python.exe] Error 1
Waf: Leaving directory `/Users/Shared/lmnd/lmnd-test03/dist/waf_build'
.
.
.

11. While we are at it, do manually create the directory
/Users/Shared/lmnd/lmnd-test05/local/share/
and there the following link:

ln -s /usr/share/aclocal-1.10 /Users/Shared/lmnd/lmnd-test05/
local/share/aclocal-1.10

(later on, e.g. such a link with "automake-1.10" instead of
"aclocal-1.10"
will be created by the build procedure, but not the
"aclocal-1.10" one!?)
If you do not have that link, the build later stops with (at
least for me):
.
.
.
>>> Emerging (11 of 13) dev-lang/python-2.7.2-r3
.
.
.
* Applying python-2.7.2-
ubuntu_multiarch_paths.patch ...
[ ok ]
* Running eautoreconf in '/Users/Shared/lmnd/lmnd-test05/dist/tmp/
portage/dev-lang/python-2.7.2-r3/work/Python-2.7.2' ...
* Running aclocal -I /Users/Shared/lmnd/lmnd-test05/local/usr/share/
aclocal ...
[ !! ]

* Failed Running aclocal !
.
.
.

12. Let's take the time to check the following two links:

/Users/Shared/lmnd/lmnd-test05/local/bin/perl
/Users/Shared/lmnd/lmnd-test05/local/bin/less

They should link to (respectively):

/usr/bin/perl
/usr/bin/less

I don't know how, but during testing, I more than once ended up
with
both these links pointing each to itself, with errors like
"too man levels of indirection" when called.
If one (or both) of these links are broken, correct it.

13. make
(will now finally succeed)

14. copy the script "startprefix" under /Users/Shared/lmnd/lmnd-test05/
local to
/Users/Shared/lmnd/lmnd-test05/
and rename it to
"startprefix.tool"
(so it can be started up with the mouse by just double-clicking on
it)
One word of CAUTION:
From "inside" the prefix, never call "make" in the lmnd root
directory!
I suspect this breaks the "less" and "perl" links, and it won't
work anyway.

Done!

15. The next thing to do would be to adjust the file
/Users/Shared/lmnd/lmnd-test05/local/etc/make.conf

The content of mine is (note the -aqua):

ACCEPT_KEYWORDS="~x86 x86 ~amd64 amd64 ~x86-linux x86-linux ~amd64-
linux amd64-linux"
USE="-aqua data -gdbm gmp jpeg libpolymake ntl -openmp pari24
png readline sage sqlite ssl zlib"
MAKEOPTS="-j2 VERBOSE=1"
FEATURES="nostrip lmirror"
CFLAGS="-m32"
CXXFLAGS="${CFLAGS}"
FFLAGS="${CFLAGS}"
FCFLAGS="${FFLAGS}"
LDFLAGS="-arch i386"

16. Finally, with this 32-bit sane guest build environment,
e.g. openssl and polybori both build fine!
(Polybori not setting "-D_HAVE_GD" as in some obviously broken
build environment. I didn't test it with USE="gd" yet, though.)

17. singular and libsingular have a problem.
The build rules for the production libraries do respect CXXFLAGS,
but the buildrules for debug and profiling library versions
don't.
Since they do at least respect CPPFLAGS, a workaround is to set
(for those two packages only):
export CPPFLAGS="-m32"

Once the compilerwrapper "talks OS X 10.6", this shouldn't be
necessary
anymore.

18. gnutls-2.10.5 has a problem on OS X 10.6, see:
http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/4825

The workaround is to unmask and use gnutls-2.12.5, with USE="-
nettle"
(or else create some gnutls-2.10.5-r1 with the patch of the link
above,
but I didn't test this --- the "un-nettled" 2.12.5 works fine
for me).

19. On the further road to Sage, now only the packages relying on
fortran
remain as blockers for me.
Using the "Sage way" to install a gfortran (v4.2.3) compiler,
I could build the blas-reference package.
However, then neither superlu nor lapack-reference would build,
both due to linking problems, as far as I can tell.
But MacPorts surely has all these working, so the obstacles
should be
surmountable.
I think the next thing to do, is to decide which fortran to use,
how to install it, how to make the compilerwrapper "know" it.

Cheers,
Georg

[Burcin Erocal]

Hi Georg,

thanks for the detailed notes.

On Sun, 4 Dec 2011 13:32:14 -0800 (PST)
gsw <georg...@googlemail.com> wrote:

> Recipe to bootstrap current (Dec 4th, 2011) lmnd-prefix on (some)
> MacIntels,
> as "32 bit" (x86-macos) system.
> Use on your own risk. Your mileage may vary.

Wow! This is far more complicated than I expected. I hope I can get
access to an OSX 10.6 system in the next few days so I can try things
myself and fix at least some of these problems.

It's good to have mercurial around for development. I usually
easy_install mercurial in my home directory. You can also just download
a tarball from bitbucket though.

> 3. create some testdir, say /Users/Shared/lmnd/lmnd-test05/
> cd to it,
> and do
> "../lmnd-repository/lmnd-prefix/create_test_dir.sh"
> (for this again some "hg" command must be available, see inside
> that script)

It is possible to create a test tree from a tarball for the repository,
which you can get from the web interface to bitbucket. After extracting
the files, the following command will give you the same result as the
output of create_test_dir.sh.

<base_of_prefix>/scripts/bootstrap-sage.sh <absolute_path_to_dest_dir>
tree <path_of_overlay_tarball>

> 4. exit the Sage shell, cd (again) into /Users/Shared/lmnd/lmnd-
> test05/
> (no more "hg" will be necessary in the following)
>
>
> 5. (optional, but saves both space and time) populate the directory
> /Users/Shared/lmnd/lmnd-test05/dist/distfiles/
> with the more than half a GB of files fetched in earlier attempts

This is really a good idea. After creating the test tree, I usually go
into dist/ and link distfiles/ and portage/ to other locations.

> 6. ./configure --flavor=plain
> ("plain" will just bootstrap a plain "bare" prefix)
>
>
> 7. make
> I do not really understand why (the ebuild seems to have the
> correct
> resp. necessary keywords), but the build will halt with:

I thought that if you enable ~arch as a keyword, then portage also
accepted the non tilde version. Apparently this is not correct.

The profile enables ~x86-macos and the ebuild has x86-macos.

I will add a make.defaults file to the profiles to add the non-tilde
keyword explicitly.

So it couldn't even build compilerwrapper?

This is unusual. Perhaps the links to compilers in local/bin were
corrupted somehow because of a previous compilerwrapper install which
didn't go right.

Can you send me the config.log mentioned above?

> 10. The mechanisms inherited from Gentoo Prefix default to 32bit
> installations
> on Mac OS. Since the compilerwrapper does not (yet) handle this
> gracefully
> on my OS X 10.6, we now hammer those nails in (but not earlier!):
>
> export CFLAGS="-m32"
> export CXXFLAGS="${CFLAGS}"
> export LDFLAGS="-arch i386"
>
> export USE="-aqua"

This is not enough unfortunately. These do not explicitly include the
library paths in the prefix for example. compilerwrapper used to do
that behind the scenes for us.

I created a ticket for this:

http://issues.lmona.de/issue7

The issue tracker (roundup) seems to be flaky. Please report me if it
causes problems for you.

> 13. make
> (will now finally succeed)
>
>
> 14. copy the script "startprefix"
> under /Users/Shared/lmnd/lmnd-test05/ local to
> /Users/Shared/lmnd/lmnd-test05/
> and rename it to
> "startprefix.tool"
> (so it can be started up with the mouse by just double-clicking on
> it)
> One word of CAUTION:
> From "inside" the prefix, never call "make" in the lmnd root
> directory!
> I suspect this breaks the "less" and "perl" links, and it won't
> work anyway.

Hmm.. that's a fair warning. I wonder if we should remove the Makefile
wrapper once the build completes successfully.

<snip>

>
> 19. On the further road to Sage, now only the packages relying on
> fortran
> remain as blockers for me.
> Using the "Sage way" to install a gfortran (v4.2.3) compiler,
> I could build the blas-reference package.

That's great!

> However, then neither superlu nor lapack-reference would build,
> both due to linking problems, as far as I can tell.

This is probably because the library path was not set to include the
prefix paths.

> But MacPorts surely has all these working, so the obstacles
> should be
> surmountable.
> I think the next thing to do, is to decide which fortran to use,

I'd be happy to use the same one as Sage. I couldn't get the dmg
provided on the R project page to work.

> how to install it,

We should create a gfortran-bin ebuild to handle the install and put
stuff in opt/.

> how to make the compilerwrapper "know" it.

AFAICT, compilerwrapper needs to be patched to run gfortran from a
location different from that of gcc.

Thanks again for the feedback.

Cheers,
Burcin

[gsw]

Hi,

some updates, before I forget all the details.

20. After quite some thought, on OS X, I propose to use the gfortran
packages from the R folks, see http://r.research.att.com/tools/. More
precisely:

On OS X 10.4, use (XCode 2.5 with) : gcc-4.2-5566-darwin8-all.tar.gz
On OS X 10.5, use (XCode 3.1.4 with): gfortran-42-5577.pkg
On OS X 10.6, use (XCode 3.2.6 with): gfortran-42-5664.pkg
On OS X 10.7, use (XCode 4.1 with) : gfortran-lion-5666-3.pkg
On OS X 10.7, use (XCode 4.2 with) : gcc-42-5666.3-darwin11.pkg

Some notes are appropriate.
First, regarding the compiler saga on OS X, read e.g. the blog entry
http://left404.com/2011/10/15/macos-x-10-7-compilers/ .
Secondly, this proposal is for gfortran v4.2.4, relying on gcc v4.2
(several builds, from 5566 to 5666.3); the default names (under /usr/
bin/) are:
gcc-4.2 (C compiler)
gpp-4.2 (C preprocessor)
g++-4.2 (C++ compiler)
gfortran-4.2 (Fortran compiler)

On some OS X versions, one has to manually create links in /usr/bin/
from gcc, gpp, g++, gfortran to these (with "sudo", i.e. as root/admin
user).
On OS X 10.4: do that manually, OS X 10.4 does not normally know
about gcc 4.2.
On OS X 10.5: do that manually, or use "sudo /usr/sbin/gcc_select
4.2"
On OS X 10.6: nothing to do, gcc 4.2 is the default gcc --- but with
XCode 3.2.6 comes build 5666.3, there is no "gfortran-
darwin10-5666-3.pkg" or such on the above web site, and so the
original 5666.3 "cc1" will be overwritten with the 5664 one. However,
the following post indicates that this is OK:
https://stat.ethz.ch/pipermail/r-sig-mac/2011-April/008163.html
On OS X 10.7 with XCode 4.2, it seems that "gcc" points not to gcc-4.2
(which is no longer contained?!), but to llvm-gcc instead (and
"gcc_select" is no longer available) --- so again, you have to have
adjust the links manually.
(Currently, upstream Sage does not yet build with this llvm-gcc.)

To cut a long story short:
On OS X, install the latest XCode for the OS version, install the
respective gfortran package from the R project, and let some future
compilerwrapper lmnd go for /usr/bin/gcc-4.2 etc., i.e. with "-4.2" at
the end(s). (And with the current compilerwrapper, do manually some
link renaming/creating).

(The long story would need some mail on its own --- you need not only
to take the fortran compiler into account, but also the accompagnying
fortran library and its whereabouts ... that's why the Sage upstream
*source* distribution carries around three different fortran *binary*
installations. One might wish to change that, but that's another
story.)

21. And yes, on my OS X 10.6 system, with XCode 3.2.6 (gcc 4.2 build
5666.3), lmnd 32bit-version as in my previous mail, I did test out the
proposed "gfortran-42-5664.pkg", ultimately with success!

22. But it was still a longer way, I hope I still remember all the
details. Re-starting from step 19. (previous mail), now with gfortran
available in /usr/bin/, blas builds (again) fine.
However, under .../local/lib/ there are only links libblas.dylib, and
libblas.0.dylib --- do create another link named libblas.0.0.0.dylib
(with all the same target under .../local/lib/blas/reference/)
To build R later, this will be needed.

23. superlu and lapack both want to build certain files "without any
optimization", and to do so, their build systems ignore our "CFLAGS".
For superlu, the trick with
export CPPFLAGS="-m32"
does the job. For lapack, essentially the same trick works, but with
NOOPT_FFLAGS instead.

24. R needs additionally export OBJCFLAGS and OBJCXXFLAGS to be set to
-m32

25. I advise sage-doc to be built with USE="html" and both sage-
baselayout and sage itself to be built with USE="testsuite" --- or
otherwise, sage -t blah will exit with some uninformative error
message "sage-test not found".
This probably is a bug in sage-on-gentoo upstream, and should be fixed
there (i.e. in case of "testsuite" not being among the use flags, give
a useful hint to enable this on entering "sage -t ...").

26. Done. Really? No way!
sage -maxima and sage -R are both broken, giving all similar error
messages like:

dyld: Library not loaded: @executable_path/../lib/libblas.0.0.0.dylib
Referenced from: /Users/Shared/lmnd/lmnd-test05/local/usr/lib/R/lib/
libR.dylib
Reason: image not found
/Users/Shared/lmnd/lmnd-test05/local/usr/bin/sage-sage: line 372:
301 Trace/BPT trap "$SAGE_LOCAL/bin/R" "$@"

until you copy some dylibs or at least some symlinks around. The
reason: compilerwrapper assumes that the maxima and R (resp. R.dylib)
binaries are in .../local/bin/ (resp. ...local/lib/) and hardcodes
paths relative to these locations. But the maxima binary e.g. is in
.../local/lib/maxima/5.24.0/binary-ecl/
and thus looks for its libraries (libecl.dylib, libffi.5.0.10,dylib,
libgmp.10.dylib) then in:
.../local/lib/maxima/5.24.0/lib/

I did dirtily just copy the libs around, but I think symlinks would
have been fine, too. As this problem does not seem to affect Linux
systems, the "ld" there seems to be a bit smarter than "dyld" on OS X.
But hey, "Sage works!", and after fixing maxima and R, only very few
doctests remain broken. These deserve another mail however (some gfan
"doctest ordering" oddities, some path that has changed in lmnd,
surprisingly few doctests fail because of using python 2.7, but there
ought to be some).

Finally, why did/does complerwrapper fail to build "natively" on my
machine?
I don't have the output at hand (I could reproduce it, if needed), but
from what helps:

a) either export CFLAGS="-m32"
b) or else export CFLAGS="-march=nocona"

and in the output being the option "-march=prescott", the default
bitness (the compiler produces) being 64 bit, prescott CPUs not being
64bit CPUs and the failure saying something about bitness
incompatibility, I think compilerwrapper just needs some magic to
detect which bitness/options to use on OS X.
But that bitness "magic" is yet another topic for another thread.

My next step is to try to build lmnd on OS X 10.4 Tiger --- in "64 bit
mode"!
I always dreamt of Sage running there in 64 bit (it's got a Core2Duo
CPU, so is 64bit capable), but since upstream Sage uses e.g. the
system (32bit) blas, upstream Gentoo Portage insisting being 32bit,
that becomes possible only with lmnd.

Cheers,
Georg

[Burcin Erocal]

Hi Georg,

On Mon, 12 Dec 2011 13:37:23 -0800 (PST)
gsw <georg...@googlemail.com> wrote:

> some updates, before I forget all the details.

Thanks for the comprehensive info.

lmnd builds on my main OSX development machine broke a while ago and I
haven't had time to fix it since:

http://issues.lmona.de/bb/builders/tibatong/builds/5/steps/shell_4/logs/stdio

While bootstrapping portage, I see a message similar to the whoami
error message here:

http://trac.sagemath.org/sage_trac/ticket/12158

lmnd bootstraps coreutils on that machine before this. I guess
something is broken in the newly built id command.

> 20. After quite some thought, on OS X, I propose to use the gfortran
> packages from the R folks, see http://r.research.att.com/tools/. More
> precisely:
>
> On OS X 10.4, use (XCode 2.5 with) : gcc-4.2-5566-darwin8-all.tar.gz
> On OS X 10.5, use (XCode 3.1.4 with): gfortran-42-5577.pkg
> On OS X 10.6, use (XCode 3.2.6 with): gfortran-42-5664.pkg
> On OS X 10.7, use (XCode 4.1 with) : gfortran-lion-5666-3.pkg
> On OS X 10.7, use (XCode 4.2 with) : gcc-42-5666.3-darwin11.pkg
>
> Some notes are appropriate.
> First, regarding the compiler saga on OS X, read e.g. the blog entry
> http://left404.com/2011/10/15/macos-x-10-7-compilers/ .

This was really helpful. Thanks again.

Is /usr/bin/gcc-4.2 installed by the dmg file from the R project, if
the system doesn't provide it?

> (The long story would need some mail on its own --- you need not only
> to take the fortran compiler into account, but also the accompagnying
> fortran library and its whereabouts ... that's why the Sage upstream
> *source* distribution carries around three different fortran *binary*
> installations. One might wish to change that, but that's another
> story.)

I am curious to find out how you worked around the requirement that the
fortran libraries are installed in system paths in /usr/*. Or are you
suggesting that we ask the user to install fortran on the system, using
the dmg files provided by the R project?

I am not opposed to adding a requirement for gfortran on OS X as well.
Since OS X users are more likely to have root access on their machines
than linux users.

> 21. And yes, on my OS X 10.6 system, with XCode 3.2.6 (gcc 4.2 build
> 5666.3), lmnd 32bit-version as in my previous mail, I did test out the
> proposed "gfortran-42-5664.pkg", ultimately with success!
>
>
> 22. But it was still a longer way, I hope I still remember all the
> details. Re-starting from step 19. (previous mail), now with gfortran
> available in /usr/bin/, blas builds (again) fine.
> However, under .../local/lib/ there are only links libblas.dylib, and
> libblas.0.dylib --- do create another link named libblas.0.0.0.dylib
> (with all the same target under .../local/lib/blas/reference/)
> To build R later, this will be needed.
>
>
> 23. superlu and lapack both want to build certain files "without any
> optimization", and to do so, their build systems ignore our "CFLAGS".
> For superlu, the trick with
> export CPPFLAGS="-m32"
> does the job. For lapack, essentially the same trick works, but with
> NOOPT_FFLAGS instead.
>
>
> 24. R needs additionally export OBJCFLAGS and OBJCXXFLAGS to be set to
> -m32

I would expect all these flags to be set by the portage profile. I am
surprised you need to do this manually.

>
> 25. I advise sage-doc to be built with USE="html" and both sage-
> baselayout and sage itself to be built with USE="testsuite" --- or
> otherwise, sage -t blah will exit with some uninformative error
> message "sage-test not found".
> This probably is a bug in sage-on-gentoo upstream, and should be fixed
> there (i.e. in case of "testsuite" not being among the use flags, give
> a useful hint to enable this on entering "sage -t ...").

Right. I enabled these USE flags in the lmnd profile:

https://bitbucket.org/burcin/lmnd-prefix/src/fdc571be4dc7/profiles/lmnd/package.use

> 26. Done. Really? No way!
> sage -maxima and sage -R are both broken, giving all similar error
> messages like:
>
> dyld: Library not loaded: @executable_path/../lib/libblas.0.0.0.dylib
> Referenced from: /Users/Shared/lmnd/lmnd-test05/local/usr/lib/R/lib/
> libR.dylib
> Reason: image not found
> /Users/Shared/lmnd/lmnd-test05/local/usr/bin/sage-sage: line 372:
> 301 Trace/BPT trap "$SAGE_LOCAL/bin/R" "$@"
>
>
> until you copy some dylibs or at least some symlinks around. The
> reason: compilerwrapper assumes that the maxima and R (resp. R.dylib)
> binaries are in .../local/bin/ (resp. ...local/lib/) and hardcodes
> paths relative to these locations. But the maxima binary e.g. is in
> .../local/lib/maxima/5.24.0/binary-ecl/
> and thus looks for its libraries (libecl.dylib, libffi.5.0.10,dylib,
> libgmp.10.dylib) then in:
> .../local/lib/maxima/5.24.0/lib/
>
> I did dirtily just copy the libs around, but I think symlinks would
> have been fine, too. As this problem does not seem to affect Linux
> systems, the "ld" there seems to be a bit smarter than "dyld" on OS X.

On linux, compilerwrapper also adds an absolute rpath which gives the
correct location of local/lib. AFAIU, the linker on OS X doesn't let us
specify two different relative paths at the same time.

I am planning to remove these absolute paths and adjust the relative
link paths with a short script which will be run after the src_install
step of an ebuild. These steps are described here:

http://devmanual.gentoo.org/ebuild-writing/functions/index.html

Then the symlinks are only required during the build. This will also
eliminate the need to go through every library file and rewrite paths
during relocation.

> But hey, "Sage works!", and after fixing maxima and R, only very few
> doctests remain broken. These deserve another mail however (some gfan
> "doctest ordering" oddities, some path that has changed in lmnd,
> surprisingly few doctests fail because of using python 2.7, but there
> ought to be some).

Excellent! These sound like the standard problems I see with a linux
build. We should patch these so all doctests pass with our updated
versions as well.

> Finally, why did/does complerwrapper fail to build "natively" on my
> machine?
> I don't have the output at hand (I could reproduce it, if needed), but
> from what helps:
>
> a) either export CFLAGS="-m32"
> b) or else export CFLAGS="-march=nocona"
>
> and in the output being the option "-march=prescott", the default
> bitness (the compiler produces) being 64 bit, prescott CPUs not being
> 64bit CPUs and the failure saying something about bitness
> incompatibility, I think compilerwrapper just needs some magic to
> detect which bitness/options to use on OS X.
> But that bitness "magic" is yet another topic for another thread.

AFICT, "-march=prescott" is only set for 32-bit profiles:

~/.../prefix/darwin $ grep -R prescott *
macos/10.6/x86/make.defaults:# normally we set arch to prescott for all
MacTel users, as this enables
macos/10.6/x86/make.defaults:CFLAGS="-march=prescott"
macos/10.7/x86/make.defaults:# normally we set arch to prescott for all
MacTel users, as this enables
macos/10.7/x86/make.defaults:CFLAGS="-march=prescott"
macos/10.4/x86/make.defaults:# set arch to prescott for all MacTel
users, as this enables SSE and MMX
macos/10.4/x86/make.defaults:CFLAGS="-march=prescott"
macos/10.5/x86/make.defaults:# set arch to prescott for all MacTel
users, as this enables SSE and MMX
macos/10.5/x86/make.defaults:CFLAGS="-march=prescott"

Could it be that somewhere in the beginning 32-bit and 64-bit profiles
got mixed?

> My next step is to try to build lmnd on OS X 10.4 Tiger --- in "64 bit
> mode"!
> I always dreamt of Sage running there in 64 bit (it's got a Core2Duo
> CPU, so is 64bit capable), but since upstream Sage uses e.g. the
> system (32bit) blas, upstream Gentoo Portage insisting being 32bit,
> that becomes possible only with lmnd.

I hope it goes smoother this time. :) I tried fixing some of the issues
you mentioned. Please report back with results so we can verify if I
got things right.

Cheers,
Burcin

[Burcin Erocal]

Hi,

On Wed, 7 Dec 2011 16:49:46 +0100
Burcin Erocal <bur...@erocal.org> wrote:

> On Sun, 4 Dec 2011 13:32:14 -0800 (PST)
> gsw <georg...@googlemail.com> wrote:

<snip>

> > 12. Let's take the time to check the following two links:
> >
> > /Users/Shared/lmnd/lmnd-test05/local/bin/perl
> > /Users/Shared/lmnd/lmnd-test05/local/bin/less
> >
> > They should link to (respectively):
> >
> > /usr/bin/perl
> > /usr/bin/less
> >
> > I don't know how, but during testing, I more than once ended up
> > with
> > both these links pointing each to itself, with errors like
> > "too man levels of indirection" when called.
> > If one (or both) of these links are broken, correct it.
>
> I created a ticket for this:
>
> http://issues.lmona.de/issue7
>
> The issue tracker (roundup) seems to be flaky. Please report me if it
> causes problems for you.

We now check if the waf script is called from the prefix environment
and if the symlink points to a location within the prefix:

https://bitbucket.org/burcin/lmnd-prefix/changeset/c2acbe754f87


So this should not cause problems in the future.


Cheers,
Burcin