[lfs-dev] Killing the /lib64 symlinks (Was: Re: [blfs-dev] [blfs-book] r17603 - in trunk/BOOK: . general/prog introduction/welcome x/installing x/lib)

Douglas R. Reno renodr2002 at gmail.com
Sat Aug 6 15:15:40 PDT 2016


On Sat, Aug 6, 2016 at 5:06 PM, Ken Moffat <zarniwhoop at ntlworld.com> wrote:

> On Sat, Aug 06, 2016 at 02:31:06PM -0700, Bryan Kadzban wrote:
> > On Sat, Aug 06, 2016 at 02:53:37PM -0500, Bruce Dubbs wrote:
> > > DJ Lucas wrote:
> > > >On 07/24/2016 06:03 PM, Chris Staub wrote:
> > > >>On 07/23/2016 05:25 PM, Bruce Dubbs wrote:
> > > >>>I wouldn't mind seeing the /lib64 symliks go, but I'm not sure
> packages
> > > >>>would install properly.  I think thy would just create the lib64
> > > >>>directories and lead to some files in /lib and others in /lib64 even
> > > >>>though all the libraries are for 64-bit systems.  This would need
> to be
> > > >>>tested.
> > > >>>
> > > >>>Note that we create similar symlinks in /opt/xorg.
> > > >>>
> > > >
> > > >Is there any reason we modify the linker configuration for all
> targets and
> > > >arch? Realistically, we only need to modify
> gcc/config/i386/linux{,64}.h
> > > >in LFS, and even then, only for GLIBC. The gcc/config/linux.h file is
> only
> > > >for uclibc and bionic (Android), and musl (?) gets redefined in the
> arch
> > > >specific target. Is there any reason to continue to modify all of
> those
> > > >files in LFS? The sed commands get a lot cleaner if we only modify the
> > > >needed files.
> > >
> > > I'm reluctant to make such changes right now.  We are only a week away
> > > from package freeze for 7.10.
>
> I was going to say that this seems as good a time as any ;-)
>
> Because: when we freeze, we have to (re)build everything anyway.  If
> people say that dropping lib64 works, this seems to be a good time
> to do it.
>
> In the absence of any other suckers, I will need to rebuild texlive
> (source / trying to get tlmgr working reliably / binary) several
> times - on top of everything else I care about.  BUT, at least for
> the binary, I'll need a symlink.
>
> I'm mostly using the "simple" approach for gold (put gold at the
> beginning of $PATH) because I'm too stupid to work out how to do it
> cleanly), but that seems to work on everything I care about
> (although all of kde5 is excluded from that because of my failure to
> get it to work - I know it works (without gold) for one user but
> not for another).  But I'm meandering, gold is merely another "it
> would be nice to use it in the book" thing.
> > >
> > > In any case, exactly which files do you want to change?  Just
> gcc-pass2 in
> > > Chapter 5?  Or are there other places?
> > >
> > > BTW, I built Xorg without the /opt/lib64 symlink and everything was
> fine.
> > >  I think we can omit the last part of the Xorg setup:
> > >
> > > install -v -m755 -d $XORG_PREFIX &&
> > > install -v -m755 -d $XORG_PREFIX/lib &&
> > > ln -sf lib $XORG_PREFIX/lib64
> > >
> > > but I want to test it once more before committing a change.
>
> /me tries not to comment on X not in /usr - unlike kde, which
> includes static qt libs, using /usr is good - and if another load
> of Xorg vulnerabilities emerge, runlevel 3 is the place to rebuild.
> So, now that I've pissed-off half the people who've read this far:
>
I continue to build Xorg in /usr regularly. I know the advantages of
running it in /opt, but... binary programs!

> >
> > Not sure on xorg (or maybe more relevant, any packages that depend on it
> > and also need to dump libs into its --libdir), but I really don't want to
> > change my system's lib path from /lib64 when I rebuild.
> >
> > The reason is the dynamic linker.  I run a lot of precompiled binaries
> > (mostly unity-engine stuff from GoG), and they're all built to look for
> > ld-linux in /lib64, per the original AMD64 ABI.
> >
>
> It continues to amaze me how people find time to run games ;-)  I
> guess I'm just jealous.
>
> It is my only form of stress relief, so I always have to find time.


> > So I think a symlink would still work.  But only having a /lib directory
> > only works if the user compiles every program they run, and that's not
> > possible for a bunch of programs.  :-/
>
> I'm regrettably in that position (the texlive binary: although I
> prefer to use source, the binary shows an example for the packaging
> files for tlmgr, and for the rest of it when it works - at the
> moment upstream builds on gcc < 6 and asymptote works differently
> when run on gcc6 compared to a source build).  And having /lib64 in
> my general builds continues to annoy me, but for binaries I'm sure we
> can put a symlink there in BLFS - but only for those who need it.
>
> ĸen
>
I would need it, so it would probably screw up any updates that I do
further if we make this change. I have two binary programs that I run
regularly. The most important one for me is an application/game called
Uplink, created by Introversion Software. As it is, for that one, I have to
change it from a .deb file into a .tar.gz using the deb2targz script. The
other is a version control manager on a system I maintain for a friend of
mine. That is called PVSS, and it is a pain to get running in general, but
I always have the client installed in case I have to do anything.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20160806/cbc7b526/attachment.html>


More information about the lfs-dev mailing list