[Numpy-discussion] Numpy 1.3.0 rc1 OS X Installer
Thu Apr 2 00:18:43 CDT 2009
Christopher Barker wrote:
> I'm not surprised it took that long -- that sounds short to me!
> Anyway, If there are new python builds that are 64-bit (quad?) you wont'
> have to change much -- "only" make sure that the libs you are linking to
> are 64 bit. I suppose you could try to get a quad-universal gfortran.a
> now, but I'd wait 'till you need it.
My main concern was about making sure I always built against the same
python interpreter. For now, I have hardcoded the python executable to
use for the mpkg, but that's not good enough.
> It did a lot, but I don't THINK is re-compiled everthing. I think the
> trick is that eveything it built was still in the build dir -- and it is
> the saem python, even though it's not living in the same place.
Well, yes, it could be a totally different, incompatible python that it
would still do as you said - distutils cannot be trusted at all to do
the right thing here, it has no real dependency system. The problem is
to make sure that bdist_mpkg and the installed numpy in virtual env are
built against the same python binary:
- it makes sure the build is actually compatible
- it also gives a sanity check about 'runnability' of the binary -
at least, numpy can be imported (for the doc), and by building from
scratch, I lose this.
Of course, the real solution would be to automatically test for the
built numpy - I unfortunately did not have the time to do this correctly,
> which should be set to:
> If it was built in a virtualenv, that would be the virtualenv path.
> It's a hack, but you could post-process the mpkg to change that value
> after building.
This has the same problem - it works as long as the virtual python and
the 'python targetted by the binary installer are the same'.
> showing what a pain all of this is! Of course, you could put it in:
> or something that only scipy would know about.
That's the only correct solution I can see, yes.
>> Linux, the static library is not even publicly available (it is in
>> /usr/lib/gcc/4.3.3). I wonder whether the mac os x gfortran binary did
>> not make a mistake there, actually.
> where are you getting that? I'm about to go on vacation, but maybe I
> could try a few things...
On linux, libgfortran.a is /usr/lib/gcc/i486-linux-gnu/4.3/libgfortran.a
-> this is private
On mac OS X, it is /usr/local/lib -> this is public
Exactly the kind of 'small' things which end up with quite some headache
when you care about reliability and repeatability.
As a related problem, I am not a big fan about the Apple way of building
fat binaries, I much prefer the approach one build/arch and merging the
binaries after build with lipo. This is more compatible with all
autoconf projects out there - and it means using/updating the compilers
is easy (building multi-arch binaries the 'apple' way is really a pain -
the scripts used by R, to build the universal gfortran, is quite
complicated). I think this above problem would not have happened with a
pristine gfortran built from sources,
More information about the Numpy-discussion