Richard Fish schreef:
> Holly Bostick wrote:
>
>
>>OK, I'm following both of you so far. Yes, I do have 'multislot' for
>>binutils. I admit it was just guesswork on my part; I read the USE flag
>>description, thought about automake and autoconf, thought that binutils
>>sounded like the kind of system utility that might need similar
>>functionality (though for reasons I wouldn't know about, as a
>>non-programmer), so enabled it. But of course, now I still don't know if
>>I actually need it or it's just causing me grief. Was it a bad call?
>>
>>
>
>
> First, let me say that I couldn't find any documentation via google
> ("site:gentoo.org multislot") or in use.desc for multislot. So if I
> contradict anything that the documentation says, I am probably wrong. ;->
$ useflag multislot
/usr/portage/profiles/use.local.desc:sys-devel/binutils:multislot -
Allow for multiple versions of binutils to be emerged at once for same
CTARGET
/usr/portage/profiles/use.local.desc:sys-devel/gcc:multislot - Allow for
SLOTs to include minor version (3.3.4 instead of just 3.3)
"useflag" is an alias that searches the system useflag docs for the
description of the requested useflag. I got it from a posting on this
ML, and saved it, it's so useful-- which is why I'll post it again. Put
this in your .bashrc:
alias useflag='grep /usr/portage/profiles/use.*desc -e'
and . ~/.bashrc, and you can just type
useflag <flag_you_don't_know> to get the descriptions.
>
> The only reason I can think of for having multiple versions of binutils
> around is for cross-compiling or distcc use. For both cases, I think
> you would want the same compiler version and platform target available
> on all systems. There also might be a dependancy between binutils and
> gcc versions, (version x of gcc requires version y of binutils). But
> the current version of gcc should always work with the current version
> of binutils, so unless you are doing cross-compiling or distcc, I don't
> really see the point in keeping multiple versions of binutils around.
OK, thank you. I am doing neither. Guess that explains why it's an
optional dependency. I should have learned by now that adding features
that you *might possibly* need (but you don't really know if you need),
as opposed to features that you can clearly see that you need (based on
your specific system), is just a losing proposition. Every time I try
"compiling for the future", it just doesn't work out. I've gotta give it up.
>
> Now gcc is a different matter, because there are some libraries
> (libstdc++, libgcj, ...) that are built and installed with gcc, so you
> could argue that you want to keep multiple versions of that around to
> avoid breaking dependancies. Since libstdc++ is used by a great many
> programs, removing it before rebuilding all dependancies with
> revdep-rebuild could be dangerous.
>
> So my advice is, to be safe, update make.conf and/or package.use to
> remove the multislot flag from binutils but keep it for gcc.
That sounds fair.
>
> Now, with that said, I don't even think removing multislot from gcc
> would be dangerous, because every program that links against libstdc++
> should be linked against either "libstdc++.so" or possiblity
> "libstdc++.so.6", not a minor version. So as long as /etc/ld.so.conf
> and /etc/ld.cache are kept up-to-date (as portage does), and gcc doesn't
> move to libstdc++.so.7, there is no reason that a gcc update should
> break anything.
Well, since I'm in the process of updating my toolchain and world to
make sure that everything is compiled against the same version of GCC
(3.4.4), I suppose I don't really need to have multislot for that
either. Sigh. I feel like such a yutz...
>
> For the record, I don't have either multislot or multitarget, but then
> again, I also run ~x86,
Well, I don't (yet)... this install is new enough that I really want to
keep track of what's stable and what's testing (which having to use
/etc/portage/package.* enables me to do). But the system is starting to
get a bit *too* mixed, and it's about reached the point where it's a
diminishing return not to just set ACCEPT_KEYWORDS="~86" in
/etc/make.conf.... which I will probably do after I've finished making
sure that the system is all on the same page, as it were.
>
>
>>1) trim out a bunch of binutils slots that I may or may not need (and
>>therefore whose loss may break unknown applications), so that glsa-check
>>
>>
>
>
> The only shared libraries that binutils includes are libbfd and
> libopcodes, and the only thing I could find on my system that linked
> against them outside of binutils was oprofile. Since oprofile isn't
> exactly a critical program, revdep-rebuild would easily fix this. I
> think the worst case is that you would not be able to compile anything,
> and would need to run binutils-config to select the correct version.
Well, I don't even have oprofile installed, nor do I have most of the
other programs:
Programs That Depend On binutils
app-crypt/johntheripper
app-misc/git
dev-embedded/tigcc
dev-lang/swi-prolog-lite
dev-libs/elfutils
dev-lisp/plt
dev-util/alleyoop
dev-util/debootstrap
dev-util/memprof
dev-util/oprofile
net-misc/quagga
sci-chemistry/gromacs
sci-electronics/balsa
sci-electronics/lard
sys-apps/lshw
sys-apps/mindi
sys-apps/mondo-rescue
sys-apps/paxctl
sys-apps/tcng
sys-devel/gcc
sys-devel/prelink
sys-kernel/ksymoops
All I've got is gcc, I haven't even gotten around to installing prelink
yet. And I can't imagine that any of these programs (gcc, prelink, and
elfutils, which prelink requires), would need some old version of
binutils hanging around, especially since I would be keeping these
reverse dependencies up-to-date.
So you're probably right; I can most likely remove multislot from both
binutils and gcc (since I only mean to have one version of GCC anyway),
recompile everything *yet again* (just to be safe; this system is
starting to have a rather filthy backend, and I will not have it), and I
think it should be OK.
Something for the weekend.... a month from now (as you may have noticed,
I've got a lot of other cleanup work to do-- not to mention regular
computer projects-- before I can feel comfortable rebuilding everything).
Thanks a lot for the info.
Holly
> -Richard
>
--
[email protected] mailing list
