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:
>
> 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.
> 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 shall take my mountains', said Lu-Tze. `The climate will be good
for them.' -- Small Gods
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
