[Pan-users] Re: [0.110] pan compiles on gcc-4.1,1

[Duncan]

Frederic Bezies <address@hidden>
posted address@hidden, excerpted below, on  Fri, 01 Sep 2006
06:26:26 +0200:

> Le 01.09.2006 05:29,  walt a écrit :
> 
>> Exciting news, fellow geeks:  gentoo upgraded gcc-4.1.1 to 'stable'
>> today!
> 
> Ang gentoo 2006.1 is available too.

Yes, but release version doesn't really affect a Gentoo user, after
installation.  It's big news only for those doing new Gentoo installs.

>> 
>> The very first thing I did (of course) was to compile pan using
>> gcc-4.1.1 -- and it works beautifully!
> 
> I build it every single week with gcc 4.0.3 :)

I've been building it with gcc 4.1.1 for awhile, on Gentoo, but I prefer
~arch (unstable) to the "stale" stuff in stable.  Back on Mandrake, I ran
cooker for the same reason, and I'd be running the latest
unstable/testing/beta/whatever release, no matter what distribution or
platform I was running.  That's just the way I am.

So anyway, yes, pan builds on Gentoo with gcc 4.1.1, but some of us have
been doing that for awhile, so it's not news.  Only the fact that gcc 4.1.1
finally went stable is news, but that's Gentoo news more than pan news.

>> The great thing is that the binary is only 7% bigger than with
>> gcc-3.4.x and there are lots of other benefits as well -- but
>> I need to read hundreds of pages of documents to find out just
>> what those benefits might be.
>> 
>> I'll spend the next day or two reading those docs while I rebuild
>> my entire gentoo machine with gcc-4.1.1.  
> 
> Upgrade to gentoo 2006.1 it will be simpler.

No it wouldn't, as Gentoo users don't "upgrade" to a release.  By the time
of the release, the regular Gentoo user will already have most of the stuff
that comes with that release already merged, and in fact may have /newer/
stuff merged, due to the snapshot-freeze that the release is built and
tested against. (In particular, ~arch users are likely to have newer
versions, assuming newer versions have been released upstream, of course.)
 
See, part of the whole point of Gentoo is that you upgrade individual
applications as they become available, thus never have to do the full
system upgrade that other distributions do.

Of course, another part of the point of Gentoo is that you get to choose
the dependancies (where optional) that a package builds with, normally
using USE flags.  For example, where a particular package from a binary
distribution may be built with both kde and gnome support, thus depending
on libraries from both, or built with only support for the "default"
desktop environment (DE) choice of that distribution, thus lacking both the
dependencies and the optional support of the other DE, so by choosing
distribution you choose either full support and dependencies or limit the
support for the other choice, with Gentoo, the same package will typically
have both kde and gnome (or gtk) use flags, and the person doing the
install chooses which support and dependencies the package will have.  If
they only run KDE (as here, but with GTK as well, in part to support pan),
they can set "USE=-gnome kde" and not build those gnome dependencies or
have that support.  If they run only GNOME, likewise, "USE=gnome -kde"
gets the gnome support but won't pull in the KDE dependencies or support.

Now Gentoo does have binary packages available for many packages, but they
are only updated at Gentoo release time, not as upstream releases new
packages.  Yes, this includes security updates -- if you choose the binary
packages from the old release, that's what you get, even if that package
has had security releases since then.  The GRP (what Gentoo calls it's
binary package program) only updates at Gentoo release, because those
packages are only designed to aid in a quick install.  After initial
install, further upgrades are done via the normal Gentoo compile from
source procedure.

Similarly, by definition, the GRP binaries shipped with each release use a
default set of USE flags and CFLAGS -- they are not nor could they be
optimized for an individual installation.  Using the example above where
both KDE and GNOME support are possible and toggled with the appropriate
USE flags, the GRP binary package will have been built with "USE=gnome
kde", thus, support and dependencies for both.  If you merge that binary
package, you'll pull in GNOME dependencies even if you only run KDE and
don't want them (or the reverse, you'll pull in KDE dependencies even if
you don't want them), because the package was compiled for general use with
support for both and won't run without the libraries it linked in for
both.  Of course, the general packages will also be compiled with
general CFLAGS, say supporting a pentium and not making use of newer
SSE and the like.  For this reason, beyond the initial install, few Gentoo
users ever use the GRP packages of any release, because they aren't
customized to what they have and want on their own system.  Thus again, a
Gentoo release matters little to them beyond initial install.  Once they
have the system up and running, they update as things come along,
customizing the build to their individual installation in the process, and
what particular Gentoo release is current matters very little.

Of course here, we're dealing with a compiler upgrade going stable for
the new release as well, and it's not the release upgrade that's the issue,
but rather the compiler upgrade. Users can recompile their entire system
to get the better optimizations in the new compiler, if desired. However,
some only choose to recompile the toolchain (or just gcc itself), and let
the rest of the system get recompiled in the course of normal individual
application upgrades.  The only problem with doing upgrades only as they
come is that sometimes packages compiled with one version of gcc don't
work quite right (or at all) when used with packages compiled with a
different version.  This problem is most often seen when an application
uses a library compiled with a different gcc, or when two libraries used
by the same app are compiled with different gccs. Similarly, the problem
doesn't come up as frequently with pure C apps/libraries as it does with
C++, due to the libstdc++ library that every C++ app depends on, that's
part of gcc's C++ implementation and therefore changes each gcc version.

> I would have installed Gentoo 2006.1 instead of my Ubuntu 6.06.1 LTS,
> but I won't because :
> 
> - Gnome is older than the one available (2.14.2 in Gentoo, 2.14.3 in
> Ubuntu)

That's valid.  I would have suggested that gnome 2.14.3 might be available
for ~arch (that is, unstable), which is what I run, or still masked for
testing, but that doesn't seem to be the case.  gnome 2.14.2 seemps to be
the latest actually in portage.

However, because Gentoo is built from source by default, it's
generally easier to install from a tarball if desired, or often, to simply
move the ebuild of the existing version to your overlay, change the name to
reflect the new version, redigest the ebuild so portage doesn't complain
about a package that doesn't match its internal checks, and go from there.
Where most binary focused distributions require tracing down and
installing additional packages (<packagename>-devel or the like) to
actually build something from source, because that's the way Gentoo
normally does it, those packages are normally not spit into separate
packages in the first place, and will already be installed.

That's what I do with the weekly pan upgrades. Altho they do make it to
portage (now, the early 0.9x ones didn't), it takes a couple days, so all I
do is rename the ebuild (it's already in the overlay from the last upgrade
I did the same way) and redigest, and an upgrade then builds the new pan,
no additional intervention on my part required.

Also note that for an individual package, a minor point upgrade often
denotes only a security update or bugfix release.  With something as big as
GNOME, which comes in multiple individual packages, the individual parts
are likely to have already been upgraded to the new versions found in the
newer GNOME, even tho the gnome metapackage itself remains at the older
version number.

There are also likely to be publicly available portage overlays, such as
the GNOME-focused breakmygentoo.org (referencing the fact that the
packages are newer, even more unstable than ~arch, and may break
someone's system), that have newer versions of packages if the official
gentoo tree is behind.  A quick look at their repository...

https://svn.breakmygentoo.net/bmg-main/gnome-base/gnome/

It lists an even newer GNOME version, gnome-2.15.4, as available in their
overlay tree.


> - localization sucks (no french version out of the box for gnome
> and other tools)

I can't comment on that beyond the following as I know nothing about it. 
Knowing only English seriously decomplicates life in computer terms. =8^)

I'd speculate, however, that the appropriate l10n modules are available
either as separate packages within the normal Gentoo tree, or in overlays
such as bmg above. Even where that's not the case, as above, the
from-source nature means it's much easier to pull in such packages on your
own, as in contrast with most binary focused distributions, the
dependencies to build from source are normally already there,

> - having to build all the modules in order to make firewall work :(

Well, you don't have to build /all/ of them, only the ones you will use
and their dependencies. =8^)  While you do build what you need, you don't
have to have the ones you don't use on your system, as is often the case
with binary distributions due to the support=dependency problem, as in the
gnome/kde example above.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman