Compiling FreeBSD with GCC 4.3+

[David Naylor]

On Tuesday 21 April 2009 17:58:15 Mel Flynn wrote:
> On Tuesday 21 April 2009 17:37:50 David Naylor wrote:
> > On Tuesday 21 April 2009 10:32:04 Mel Flynn wrote:
> > > Hi David,
> > >
> > > On Monday 20 April 2009 21:48:39 David Naylor wrote:
> > > > There has been an article recently published by phoronix
> > > > (http://www.phoronix.com/scan.php?page=article&item=pcbsd_vs_kubuntu&
> > > >nu m= 1) that compares PC-BSD to Kubuntu.  Kubuntu uses GCC 4.3.3
> > > > compared to FreeBSD's GCC 4.2.2.  There is a considerable performance
> > > > difference between the two OS's, the article contributes this
> > > > difference to the compiler.
> > >
> > > Nice shot in the dark, since except the calculations a lot of these are
> > > influenced by "journaled FS vs stock UFS".
> >
> > I know, benchmarking anything but the simplest things are influenced by
> > too many factors.  Pity it doesn't provide an unbiased comparison of
> > FreeBSD and Linux.
>
> That and comparing apples and pears as default configured fruit, don't
> usually work well. Of course it appeals to the end user "which fruit is
> healthier".

:-)

> > > > In order to check if this is so (and to get the speed improvements of
> > > > GCC 4.3+) one needs to compile the ports (and preferable world/kernel
> > > > as well) with GCC 4.3+.
> > >
> > > It's license is incompatible with world/kernel.
> >
> > What type of incompatibility.  I know FreeBSD has reservations about
> > GPLv3 (I personally don't understand why everyone cannot be friends and
> > use BSD Licenses).  So is this a policy incompatibility or a legal one
> > (i.e. would it be 'illegal' for me to use GCC 4.3+ to compile
> > world/kernel, as an end-user/consumer of FreeBSD).  I assume the same
> > discussion applies to binutils.
>
> Policy. Only legal issue in FreeBSD for the end user is WITH_IDEA.

Thanks for sorting that out.  Good news for me.

> > > That said, install
> > > lang/gcc43 and set CC/CXX for ports. World/kernel would be a lot
> > > harder. Maybe setting WITHOUT_GCC in /etc/src.conf and setting CC/CXX
> > > would work, but there's quite a few modifications to gcc that aren't in
> > > ports lang/gcc, so I have my doubts.
> >
> > I suppose it would be nice if there was an easy way to use an
> > out-of-source compiler in FreeBSD.  Like set PORTS_COMPILER=gcc43 and the
> > port will installed and used... One may have dreams.
>
> cat <<'EOF' >> /etc/make.conf
> .if !empty(.CURDIR:M/usr/ports/*)
> CC=/usr/local/bin/gcc43
> CXX=/usr/local/bin/g++43
> .endif
> EOF
>
> Pretty close, huh?

Kinda, it is what I was thinking about (or just symlinking cc, cxx to the 
proper programs).  Of course if this is implemented 'properly' in ports then 
auto-dependencies and all that will be added.  

I was actually thinking about replacing the standard compiler by
a) not installing gcc 4.2.2 (i think WITHOUT_GCC, as mentioned by yourself)
b) installing latest gcc: 
# make -C /usr/ports/lang/gcc43 install DESTDIR=/new/freebsd/system 
PREFIX=/usr -DWITHOUT_JAVA
 [ With symlinks from gcc43 -> gcc, etc]
c) Hoping this works

Well something like that (with extra hope)

> > > > Is there an easy way to set this up and does anyone know the
> > > > compatibility of world/kernel/ports with GCC 4.3+?
> > > >
> > > > Also has anyone tried this and benchmarked the result?
> > >
> > > Not me, but be sure to stick around for the new non-gcc compiler coming
> > > to a FreeBSD near you. And with the work done by Marcel Molenaar on
> > > gpart, hopefully we can have ZFS and gjournal as choices in the
> > > installer.
> >
> > You mean llvm, waiting patiently.  I suppose my suggestion above will
> > become even more important (at least for compiling ports) since it will
> > be a while till llvm has decent c++ support.
>
> Yeah, I don't know how that's gonna work if llvm is ready for base, but no
> c++. I guess we'll have to sit out g++ 4.2 for a while. If you're in the
> position to do so, I'd do their benchmarks with ZFS and see how much
> difference that already makes.

Well, llvm does support C++ (with the gcc frontend) so that shouldn't be too 
much of a problem.  clang is more of the issue but I suppose we could always 
have llvm-clang for C and llvm-gcc for C++ (until clang gets full C++ 
support).  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20090421/2a0991bc/attachment.pgp