ports/130715: New Port:devel/binutils-2.19

[Alexander Best]

The following reply was made to PR ports/130715; it has been noted by GNATS.

From: Alexander Best <alexbestms at math.uni-muenster.de>
To: Pegasus Mc Cleaft <ken at mthelicon.com>
Cc: <bug-followup at 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