On Jun 15, 2010, at 3:41 PM, Jeff Singleton wrote:
> Seriously...what is the point of even having gcc44, gcc45, gcc46 in Macports,
> if we can't even use the newest compilers inside of Macports?
>
> I mean, I spend the hours building it, because there are features and
> enhancements in gcc 4.4 that I would like to use in other apps.
Just about everything built with gcc4+ should be ABI compatible -- since you
can link against the MacPorts libraries using any compiler you'd like, I'm not
sure I understand why you want to build MacPorts software with a specific
compiler?
Obviously there are some notable exceptions, but in those cases the port
maintainers do try to standardize on the latest stable/reliable version of GCC
when building those ports.
> But, after waiting all this time for gcc44 to build, then searching for some
> way to force Macports to use the newly built compiler...I end up with the
> dreaded: "configure: error: C compiler cannot create executables" error.
>
> ryandesign says forcing Macports to use a non-Xcode compiler is unsupported.
>
> So ... !!
>
> What is the point of having gcc44 in the Macports tree, if I can't even use
> it to build other Macports with?
For use with your own projects.
> Why doesn't Macports make the gcc44+ ports use the same patching that Apple
> does, and then build it the same way Apple does natively -- so we can
> freaking use the newer compiler?
Apple's compiler has a -lot- of patching, and Apple is not tracking later GCC
releases. It would be herculean task to merge that all in, much less maintain
it.
I suppose that MacPorts could fairly easily use Apple's "driver-driver" and use
an Apple-style build to support multiple architectures via the -arch flag, etc
-- if someone was inclined to do the work:
http://www.opensource.apple.com/source/gcc/gcc-5659/driverdriver.c
-landonf
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
