py26-numpy +gcc44 requires gcc45 variant of atlas

[Ryan Schmidt]

On Sep 14, 2010, at 13:41, Jeff Singleton wrote:

> 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.

I would agree. Many maintainers never test the universal variant so some ports are broken and indeed need to be fixed.


> One should be able to compile either arch if the hardware supports it.  If 32 bit apps are the most stable,

Who says that?

> 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.

Sure. But the ability to specify the build_arch in MacPorts is even newer than the capability to build universal; even more ports have not been updated to support build_arch. For any such ports that you find, please file tickets.


> 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.

MacPorts used to always build by default using whatever architecture the compiler felt like building with. This was always 32-bit in Leopard and earlier. Then with Snow Leopard Apple changed this to 64-bit, and suddenly we had to deal with all the software that wouldn't build 64-bit, and we introduced the build_arch setting, but many ports don't know about it yet, so yes, even after the amount of time Snow Leopard has already been out, you can still expect many ports to not respect the build_arch setting. Patches are welcome to fix ports that still have this problem.


> 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.

Yes, the three versions of wine in MacPorts all force themselves to 32-bit. I know this works; the wine ports support the build_arch setting, and all their dependencies support building universal. Other maintainers may not be so diligent with their ports. It is a volunteer project after all and we have to take what we can get.


> 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.

Actually, the svn version of MacPorts concerns the MacPorts base software only, not the ports collection, which is always bleeding edge, as you put it.

You're right, we don't have stable and unstable port trees. The suggestion has come up several times in the past, but we hardly have the manpower to keep our current single tree up to date; I fear splitting the tree in two would only double the problem. I'm also unclear how it is decided in such a system when a port is "stable".

You're also right, MacPorts doesn't have the capability for ports to declare dependencies on a specific version of another port, only on a port (whatever version exists). There's little need to add this capability IMHO since MacPorts also doesn't have the ability to install a specific version of a port, only the currently-available version. I imagine adding this capability would be quite involved. In any case, nobody has added it yet; if you are sufficiently interested in having this feature, and are interested in driving its design and development, you could write a proposal to the macports-dev list.