On Tue, Sep 14, 2010 at 1:56 PM, Michael Dickens <[email protected]>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 > [email protected] > > 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
_______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
