Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] amd64 /lib64 to /lib conversion fixes and adventures.

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: sergey AT optimaltec.com
  • To: Seth Alan Woolley <seth AT positivism.org>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] amd64 /lib64 to /lib conversion fixes and adventures.
  • Date: Wed, 20 Apr 2005 12:20:10 -0500

Seth,

Sorry I didn't reply right away! Please see below.

Quoting Seth Alan Woolley <seth AT positivism.org>:

> On Mon, Apr 18, 2005 at 11:15:00AM -0500, sergey AT optimaltec.com wrote:
> > OK, third time: I strongly object to having support for multilib systems
> > in
> > SMGL. We're burdened as it is with custom patches and fixes, this will be
> one
> > more *major* kludge. If my capacity as a grimoire sections maintainer
> allows
> > this, I'd like to call a vote to ban this approach in SMGL.
>
> Sergey,
>
> I'm proposing I apply the bugfixes that fix everything except the
> dynamic loader path from /lib64 to /lib.

Well, to me nothing appears to be broken in devel grimoire right now. I don't
disagree as much now that we're over the multilib question, but I still don't
get why this is necessary, from technical perspective.

>
> They are small fixes that don't do anything non-standard and make the
> basesystem more FHS-compliant. Where there is possible difference
> between the FHS and the AMD64ABI documents, notably on the dynamic
> linker, I won't apply my patch directly. I will make it completely
> optional and default to /lib64 which matches the ABI and is _closer_ to
> the LSB (the LSB has its own proprietary linker name though, which we
> won't support -- FHS is a lot more sane).

That seems to be good. If I choose a non-default option, how are my other
spells
going to be affected? Are we talking about the gcc toolchain here and glibc,
or
there's something else? I remember you mentioned perl. Should multiple spells
be configured the same way or it's a per-spell option?

> I'm still not going to work on multi-lib. This is just so I can have my
> own /lib without a symlink and you don't have to worry about recompiling
> anything since with the symlink the resultant behaviors are identical,
> and without the symlink one can get further on a rebuild with benoit's
> ISO.

OK, that's fair.

> Is this good with you Sergey? Sandalle's already declared multi-lib
> "off-limits" for now, so your vote proposal is probably not needed
> (although there is a draft policy proposal document being written up
> where you may be able to propose to codify such things, but not yet).

Yes, I'm better now :-). I didn't see this "declaration" though, and I'm
reading
every list ;-). Anyway, as long as the impact of changes is as low as you
say, I
don't mind anymore. I still think that if there such cornerstone things as
glibc
and gcc are affected, single centralized option would probably be more
appropriate. Maybe something like USE variable in Gentoo in spirit, but
sorcery
way.

Sergey.




Archive powered by MHonArc 2.6.24.

Top of Page