On Fri, Apr 16, 2010 at 04:50:34PM +0200, Jean-François Mertens wrote: > > On 16 Apr 2010, at 15:14, Jack Howarth wrote: > >> JF, >> When you say you had to remove binutils to build gcc45, do you >> mean that FSF gcc tries to use binutils instead of cctools if present? >> If so, we definitely need either a BuildConflicts or to manually >> pass the --with-as, --with-ld, --with-nm, etc as we do in llvm.info. > > Copying from my earlier message : > >>> But in the meantime I get (on 10.5 32bit _ on the 64bit side it >>> continues happily..: >>> binutils didn't build there..) >>> >>>> checking linker --sysroot support... no >>>> checking __stack_chk_fail in target C library... checking for >>>> __stack_chk_fail... yes >>>> yes >>>> Using ggc-page for garbage collection. >>>> checking whether to enable maintainer-specific portions of >>>> Makefiles... no >>>> Links are now set up to build a native compiler for i386-apple- >>>> darwin9.8.0. >>>> checking for exported symbols... unable to read unknown load command >>>> 0x1b >>>> /sw/bin/objdump: conftest: Invalid operation >>>> checking for -rdynamic... unable to read unknown load command 0x1b >>>> /sw/bin/objdump: conftest: Invalid operation >>>> checking for library containing dlopen... none required >>>> checking for -fPIC -shared... yes >>>> configure: error: >>>> Building GCC with plugin support requires a host that supports >>>> -fPIC, -shared, -ldl and -rdynamic. >>>> make[2]: *** [configure-stage1-gcc] Error 1 >>>> make[1]: *** [stage1-bubble] Error 2 >>> >>> with : >>> >>> # dlocate -S /sw/bin/objdump >>> binutils: /sw/bin/objdump
JF, My understanding is that the darwin support in binutils is very raw. Look at the last message archived in this web page... http://www.pubbs.net/200909/gcc/74135-cvssvn-binutils-and-gcc-on-macos-x.html Replacing cctools with binutils in building most if not almost all of the other fink packages is a really dicey proposition. Unlike providing a FSF gdb package (which when prefixed is produces no problems), a binutils package can cause havoc for fink builds. I would strongly suggest that binutils package not install in %/bin or %/lib but bury itself in a subdirectory like %/lib/binutils. It should be accessed directly from their via %p/lib/binutils/bin and %p/lib/binutils/lib by only those packages that need it. It could have a binutils-dev split-off which put symlinks in %p/bin or %p/lib but I would be loath to see that installed during package builds that need binutils (which should directly access the buried copy instead). Rather the binutils-dev split-off would be considered very experimental and to be used with caution. Jack > > Jean-Francois ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Fink-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-users
