public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64]  Re: Problems customizing gentoo
Date: Fri, 3 Oct 2008 09:08:02 +0000 (UTC)	[thread overview]
Message-ID: <pan.2008.10.03.09.08.02@cox.net> (raw)
In-Reply-To: 19351.0605059148$1222999100@news.gmane.org

Drake Donahue <donahue95@comcast.net> posted
19351.0605059148$1222999100@news.gmane.org, excerpted below, on  Thu, 02
Oct 2008 21:56:58 -0400:

> TRY using 2008.0 minimal livecd following the handbook in detail as
> though you were a gentoo first timer. A lot of knowledge is also a
> dangerous thing.

Good advice! =:^)

First, note that stage-1 installs are no longer supported, due to nasty 
circular dependency issues that are very difficult to work out.  They're 
still provided and in theory can still work, but the decision was that it 
was simply too much trouble trying to support stage-1, given that the 
same customized end result can be achieved by starting from a stage-3, 
remerging system, then world.  The caveat there is that one or more 
packages may need to be done out of order, if the USE flags changed 
significantly from the defaults for that stage-3.

As for the glibc errors, what this type of glibc errors usually mean is 
that somewhere along the line your multilib config got screwed up, and 
gcc can no longer compile one of 32-bit or 64-bit correctly.  There's a 
number of different ways the multilib could have gotten screwed, and it's 
often not worth the trouble to figure out which it was, but just to fix 
it, by starting from a stage-3 once again.  Actually, it's often possible 
to fix the problem by remerging just one package, gcc, from the stage-3 
(quickpkg it to a binpkg, then emerge -K the binpkg).  However, just 
doing the full stage-3 should work as well and is more likely to fix 
other misc errors.

FWIW, after losing 32-bit compiling several times, I got tired of it and 
went to the no-multilib profile, which then kills the 32-bit bits of 
gcc/glibc/binutils/sandbox.  The biggest reason for multilib is legacy 
support of 32-bit-only closed source packages.  Since they're closed 
source, porting them to 64-bit isn't an option (the major open source 
stuff has all long been ported, OpenOffice was one of the last open 
source apps not ported, and it is now), and 32-bit compatibility must be 
maintained if you use them.  Since I don't do closed source (in general, 
I couldn't legally do so even if I wanted to, since I no longer agree to 
sign my rights away nor will I accept their disclaimer for damages when 
it's a black-box who /knows/ what's in), there's very little reason I'd 
ever need 32-bit, and avoiding all the hassles that come with multilib 
has been a MUCH better choice for me.  

Of course, even with no-multilib, if I needed to do 32-bit compiles as I 
now do since I just got an Acer Aspire One AOA-150L netbook and plan on 
putting Gentoo on it, with the work done on my main 64-bit no-multilib 
system, it's still very possible to install an x86 (32-bit) stage into a 
chroot and build a full 32-bit system from there.  That's actually what 
I'll be doing, running a full 32-bit chroot with FEATURES=buildpkg, then 
installing the binary packages on my AA1 netbook.

So if you can do without multilib, do consider switching to the no-
multilb profile.  It has certainly simplified my life here, and as a 
bonus, gcc and glibc only take half the time to merge, because they only 
build for a single bitness instead of two.  Given that both those 
packages are fairly major and take a decent amount of time to build, 
halving that time is nice!

-- 
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




  parent reply	other threads:[~2008-10-03  9:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-02 21:35 [gentoo-amd64] Problems customizing gentoo Greg
2008-10-02 21:53 ` Tonko Mulder
2008-10-03  0:42 ` Rick Meredith
2008-10-03  1:56   ` Drake Donahue
     [not found]   ` <19351.0605059148$1222999100@news.gmane.org>
2008-10-03  9:08     ` Duncan [this message]
2008-10-03  7:50 ` Beso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pan.2008.10.03.09.08.02@cox.net \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-amd64@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox