Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

On Wed, Apr 20, 2005 at 12:20:10PM -0500, sergey AT optimaltec.com wrote:
> 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.

From a technical perspective, it's not necessary unless you want to 
avoid the symlink.  I suppose not using the symlink is also faster on 
loading libraries as well (very negligible), though it would slow down 
the ld loader lookup since that would be through a symlink, but this 
latter effect is made optional as described below.

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

The way it would work is simple: only two spells needs to have an 
option, and they are gcc and glibc.  

===

Here's why: For the other changes, the ld.so.cache would be identical 
because since there's a symlink already all it does is tell the 
installer to put it where the symlink target is already.  No binaries 
are affected in all but the gcc change, just installation process.  The 
gcc changees actually tell gcc to both install to /lib and to compile 
programs to expect the linker installed by glibc in /lib.  The latter 
part, where it changes actual binaries, would be optional.  The first 
would be done on either system since it's just the same as what I'm 
doing to procps.  Perl's chance is actually telling it to look in /lib64 
explicitly for libraries as well as /lib so that you can compile perl at 
any stage of the conversion process and have it work on benoit's iso 
out-of-the box.  It's sort of unrelated to my proposal, it just makes it 
able to compile on a split library system (assuming I made my changes to 
glibc, perl would have no problem compiling unmodified).

===

Now for the exact two optional changes:

  * gcc would have an option specific to amd64 for now:

    "Shall gcc compile binaries to expect the dynamic linker in /lib 
    (not /lib64) (lib64 purge part 1 of 2)? [n]"

    (gcc split companion spells would then check gcc's configured status)
    (in addition to the change noted in the bug report, gcc itself would make 
    sure there's a symlink from /lib linker to /lib64 linker if /lib 
    linker doesn't exist)
    
    (this is the second sedit in the 8626 bug report)

  * glibc would have an option specific to amd64 for now:

    "Shall the dynamic linker install to /lib (not /lib64) (lib64 purge 
    part 2 of 2)? [n]"

    (in addition to the change noted in the bug report, glibc shall 
    check to see if /lib64 exists, and if it does exist it will make 
    sure the /lib64 linker exists or is a symlink to /lib linker already 
    -- if /lib64 doesn't exist it will assume the change purge has 
    already completed)

    (this is the first two sedits in the 8626 bug report)

With a symlink from /lib64 to /lib and from /usr/lib64 to /usr/lib 
saying yes or no to either in any combination would work perfectly.

Saying yes to both and then rebuilding your entire system would enable 
you to remove all *lib64 symlinks.  To further gain compatibility with 
proprietary binaries, one need only then add: mkdir /lib64; ln -s 
/lib/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2 as ldconfig would 
take care of all other linker changes.  (The only library hardcoded in 
the linking process is the dynamic linker itself, which is set at 
compile-time.

If you've got a benoit split-lib iso with no symlinks, you do:

 * cast -r gcc, say yes to lib64 purge part 1 of 2
 * cast -r glibc, say yes to lib64 purge part 2 of 2
 * rebuild the entire system (glibc and gcc can actually be done at the same 
   time as this rebuild instead of separately)
 * order of the first two compiles is irrelevent
 * after everything compiles, there should be nothing in /lib64 and 
   /usr/lib64 if all the spells currently installed are doing the right 
   thing.
 * at the very end of this process, the user may remove the
   /lib64 directory and its linker symlink or remove the great big 
   /lib64 to /lib symlink, depending upon their initial configuration.  
   This part will not be automated, as it renders proprietary systems 
   following other systems incompatible. No automated change above 
   should affect how proprietary systems link on the system. :)
 * optionally, the user may add a /lib64 to /lib big symlink and they'd
   have a system perfectly consistent with your (Sergey's) proposal and 
   have completely "fixed" the multilib "out" of the benoit iso (after 
   deleting the /usr/include aliens from the multilib libc headers of 
   course).

In ether case, saying yes to either option and no to the other is 
entirely workable in _any_ case, except going back to no after you've 
removed /lib64 from your system, which is not automated and will only 
partially be supported.  Putting the symlink back and reconfiguring with 
"no" on the options would bring it back to the way it was, so it's 
entirely reversible.

===

Now for the changes that won't affect any system with symlinks in place 
except make it more compatible to later remove the symlink:

  * gcc and companion spells would be made to install to /usr/lib 
    instead of /usr/lib64 (first sedit in the 8626 bug report)

  * glibc would be made to install to /usr/lib instead of /usr/lib64
    (last two sedits in glibc).  It would also have PRE_INSTALL properly 
    check for a linker in /lib or /lib64 also listed in the bug report.


  * procps would be made to install to /usr/lib instead of /usr/lib64

procps isn't even in the basesystem, but since I use it and many spells 
will later depend on it, I want to fix it.  I'll probably be fixing some 
more spells to install to /lib by default in the future as well.

===

Now for the changes that make using benoit's iso easier to bootstrap from:

  * Perl's default compile configuration process would be made to check in 
  /lib64 and /usr/lib64 as well as the standard lib locations.

This just makes it so you can compile perl before gcc and glibc get hit 
in the queue and have it work.

===

That's that, I hope it explains everything!  I'll of course thoroughly 
test these changes, and all of the "effect" will be limited to amd64 
arch.

Seth


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

Not actually needed given the parenthesized checks above :)

> 
> Sergey.
> 

-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id 00BA3AF3 = 8BE0 A72E A47E A92A 0737  F2FF 7A3F 6D3C 00BA 3AF3
Security Team Member Source Mage GNU/Linux http://www.sourcemage.org
Elected Coordinating Committee Member, Pacific Green Party of Oregon

Attachment: pgp71eVPYrZBp.pgp
Description: PGP signature