Gentoo Archives: gentoo-amd64

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-amd64@l.g.o
Subject: [gentoo-amd64] Re: Problems customizing gentoo
Date: Fri, 03 Oct 2008 09:08:31
Message-Id: pan.2008.10.03.09.08.02@cox.net
1 Drake Donahue <donahue95@×××××××.net> posted
2 19351.0605059148$1222999100@××××××××××.org, excerpted below, on Thu, 02
3 Oct 2008 21:56:58 -0400:
4
5 > TRY using 2008.0 minimal livecd following the handbook in detail as
6 > though you were a gentoo first timer. A lot of knowledge is also a
7 > dangerous thing.
8
9 Good advice! =:^)
10
11 First, note that stage-1 installs are no longer supported, due to nasty
12 circular dependency issues that are very difficult to work out. They're
13 still provided and in theory can still work, but the decision was that it
14 was simply too much trouble trying to support stage-1, given that the
15 same customized end result can be achieved by starting from a stage-3,
16 remerging system, then world. The caveat there is that one or more
17 packages may need to be done out of order, if the USE flags changed
18 significantly from the defaults for that stage-3.
19
20 As for the glibc errors, what this type of glibc errors usually mean is
21 that somewhere along the line your multilib config got screwed up, and
22 gcc can no longer compile one of 32-bit or 64-bit correctly. There's a
23 number of different ways the multilib could have gotten screwed, and it's
24 often not worth the trouble to figure out which it was, but just to fix
25 it, by starting from a stage-3 once again. Actually, it's often possible
26 to fix the problem by remerging just one package, gcc, from the stage-3
27 (quickpkg it to a binpkg, then emerge -K the binpkg). However, just
28 doing the full stage-3 should work as well and is more likely to fix
29 other misc errors.
30
31 FWIW, after losing 32-bit compiling several times, I got tired of it and
32 went to the no-multilib profile, which then kills the 32-bit bits of
33 gcc/glibc/binutils/sandbox. The biggest reason for multilib is legacy
34 support of 32-bit-only closed source packages. Since they're closed
35 source, porting them to 64-bit isn't an option (the major open source
36 stuff has all long been ported, OpenOffice was one of the last open
37 source apps not ported, and it is now), and 32-bit compatibility must be
38 maintained if you use them. Since I don't do closed source (in general,
39 I couldn't legally do so even if I wanted to, since I no longer agree to
40 sign my rights away nor will I accept their disclaimer for damages when
41 it's a black-box who /knows/ what's in), there's very little reason I'd
42 ever need 32-bit, and avoiding all the hassles that come with multilib
43 has been a MUCH better choice for me.
44
45 Of course, even with no-multilib, if I needed to do 32-bit compiles as I
46 now do since I just got an Acer Aspire One AOA-150L netbook and plan on
47 putting Gentoo on it, with the work done on my main 64-bit no-multilib
48 system, it's still very possible to install an x86 (32-bit) stage into a
49 chroot and build a full 32-bit system from there. That's actually what
50 I'll be doing, running a full 32-bit chroot with FEATURES=buildpkg, then
51 installing the binary packages on my AA1 netbook.
52
53 So if you can do without multilib, do consider switching to the no-
54 multilb profile. It has certainly simplified my life here, and as a
55 bonus, gcc and glibc only take half the time to merge, because they only
56 build for a single bitness instead of two. Given that both those
57 packages are fairly major and take a decent amount of time to build,
58 halving that time is nice!
59
60 --
61 Duncan - List replies preferred. No HTML msgs.
62 "Every nonfree program has a lord, a master --
63 and if you use the program, he is your master." Richard Stallman