Date: Wed, 21 Jan 2009 09:30:04 GMT From: Alexander Best <alexbestms@math.uni-muenster.de> To: freebsd-ports-bugs@FreeBSD.org Subject: Re: ports/130715: New Port:devel/binutils-2.19 Message-ID: <200901210930.n0L9U4fD070741@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR ports/130715; it has been noted by GNATS. From: Alexander Best <alexbestms@math.uni-muenster.de> To: Pegasus Mc Cleaft <ken@mthelicon.com> Cc: <bug-followup@freebsd.org> Subject: Re: ports/130715: New Port:devel/binutils-2.19 Date: Wed, 21 Jan 2009 10:24:30 +0100 (CET) the reason i was trying binutils 2.19 is that i wanted to compile mplayer with ssse3 support. now the base version of gcc knows about ssse3, but the gas version in base is unaware of it. that's why i'd like to test compiling mplayer with gas 2.19. of course i could install the new binutils and then install a gcc version from the ports tree, but for me the base gcc is sufficient. so in order to use the base gcc with a different gas version i have to set AS=/usr/local/bin/as and recompile gcc right? so what happens during the gcc compilation is this: the gcc configure scripts search for the binutils. if the binaries get found their location is being statically built into the gcc binary. wouldn't it make more sense to let gcc search for the binutils during runtime? that way it would be possible to change the binutils used by gcc withut recompiling it. also this behaviour of gcc makes some configure options bogus. mplayer e.g. let's me define the assembler that should be used by doing ./configure --as=ASSEMBLER. this settings however doesn't have any effect since gcc uses the gas version that was found at compilation time. cheers. alex Pegasus Mc Cleaft schrieb am 2009-01-21: > On Tuesday 20 January 2009 21:53:56 Alexander Best wrote: > > compiling and installing the port works fine for me. > Firstly, thanks for testing the port. I really appreciate it. > > the only problem i'm having is that i can't convince gcc to use the > > updated > > version of `as` (gas). gcc seems to be using /usr/bin as a > > hardcoded path > > to look for as `as`. only if gcc doesn't find the executable in > > that > > directory it looks for it in the places specified in $PATH. > <snip> > > i don't know if this is just the case with `as` or with all the > > binutils > > binaries. the only solution i've found so far is to rename > > /usr/bin/as to > > something else so gcc cannot find it and searches for `as` in > > $PATH. > If you are using the base compiler, this is probably normal. > During the > ./configure of the compiler, it either searches for or is told where > to find > ar, as, ld, etc.. You can override this by setting the appropriate > environment > variables either in your environment or in the /etc/make.conf: > AR=/usr/local/bin/ar, etc. To be honest, using the new binutils with > the base > compiler really wont do very much for you, its useful if you also > upgrade your > compiler (to take advantage of processor features that the base tools > are not > aware of yet, IE: SSE4) > What you might consider is building /usr/ports/lang/gcc43. > When this port > configures, it will find the new tools and use them by default. > The above is the path I took, and in addition, I added the > following to my > /etc/make.conf to use it by default: > <in /etc/make.conf> > #CFLAGS= -O2 -fno-strict-aliasing -pipe -s > #CXXFLAGS+= -fconserve-space > CFLAGS= -march=native -O2 -fno-strict-aliasing -pipe -s > CXXFLAGS+= -fconserve-space > CC=gcc43 > CXX=g++43 > NO_CPU_CFLAGS= # Don't add -march=<cpu> to CFLAGS > automatically > NO_CPU_COPTFLAGS= # Don't add -march=<cpu> to COPTFLAGS > automatically > Now I comment out the first block when I am compiling from > the ports tree, > and comment out the second block (and uncomment the first) when > compiling the > world and kernel. Just be aware that using the later gcc will break > many of > the ports due to gcc's Header dependency cleanup. So, if you find > something > that is broken, just switch back to the first block and try again. > ~Peg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901210930.n0L9U4fD070741>