py26-numpy +gcc44 requires gcc45 variant of atlas

[Jeff Singleton]

On Tue, Sep 14, 2010 at 1:56 PM, Michael Dickens <michaelld at mailworks.org>wrote:

>
> Which in my experience means that you're compiling from .c to .o for one
> arch (e.g., 32 bit) but trying to link from .o to an executable with another
> arch (e.g., 64 bit) -- so, the compiler errors out & that's the error that
> Python prints.  If you look at the more in depth debug output, I bet you
> find some comment about not finding the correct architecture.
> --
>  Michael Dickens
>  michaelld at mailworks.org
>
>
How could "I" be compiling for one arch and then linking another ... I'm
using MacPorts.  I would assume that if a Port has support for universal,
then MP would adhere to this and build universal.  If the compiling from .c
to .o is done as 32-bit, but trying to link 64-bit, then I would say that
the maintainer of said port needs to look at this and fix it.

One should be able to compile either arch if the hardware supports it.  If
32 bit apps are the most stable, then one should logically expect that the
dependents would also need to be in 32-bit.  If I explicitly set i386 as the
default arch, and disable universal builds, then I should not have to worry
about whether MacPorts wants to do what it wants to do despite my
settings...it should just obey my configuration, period.

The mac in question (this time) is set for Universal building x86_64 and
i386, with default Arch x86_64 should no universal variant exist...yet
py26-numpy refuses to build using mp-gcc-4.4 with universal enabled...each
attempt ending with the "RuntimeError: Broken toolchain...".  The only way I
could get it to build was to edit the Portfile and force it to use
gcc-4.2/g++-4.2...and it still put everything under
/opt/local/Library/Frameworks as I would expect.

I find it troubling that 32-bit building is causing so much issue when its
been a stable arch for much longer than 64-bit building has been.

I believe Wine was mentioned as an example ... which can build 64 bit, but
is very unstable and causes more issues in the long run.  Crossover Office
(Wine on Steroids) also uses 32 bit wine, and requires X11 quartz-wm in 32
bit if you want seamless integration with the OS X environment...it will not
work with XQuartz built from ports nor the DMG version from MacOSForge.

I would think that some level of synchronization would be used overall in
MacPorts, but seems to be severely lacking in this area when compared to
some of the other package managers I've used under Linux....Gentoo's
portage, for example, masks different versions until their dependencies have
caught up, but still allows the user to unmask both the dependencies and the
actual application should they wish to try bleeding edge...and each
application and each dependency has a list of supported/required versions of
library's and such that must be met before it will compile and work...not
just the port itself, but the versions as well.  Under this method of
management, the maintainers simply mark newer versions as available and then
mask them with notes stating what is needed to make this version work. Then
these versions will get unmasked when their dependencies catch up, but
because they are marked as available, it gives the users more knowledge of
what and why a certain version is not readily available and allows them to
unmask/build the necessary requirements. This gives users a Stable branch
(fully tested), a couple of Intermediate branches (some testing and patches
available), and then the uber-Bleeding edge branch (latest version, not much
testing or patches).

With MacPorts, its one version at a time, and only when the maintainer deems
it stable. I'm sure someone will point out that their is a SVN MacPorts that
allows bleeding edge, but that doesn't offer versioning, nor proper
explanation of why a certain version of something has not made it into the
tree yet.

-- 
J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20100914/e1941de0/attachment.html>