what exactly means "Installation Dependencies"?

dagmar at speakeasy.net dagmar at speakeasy.net
Tue Oct 8 08:29:44 PDT 2002


On Tue, 8 Oct 2002, Hannes Birnbacher wrote:

> Antwort auf die E-Mail vom Mo 07 Okt 2002 11:20:48p :
>
> >> I'm a little confused by the way you phrased things,
> >> because if you're operating from _within_ the static build
> >> environment, then _one_ of those binaries should be the
> >> ones built by SuSe.  Possibly you need to be clearer.
> >
> > Drek.  s/_one_/_none_/;
> >
>
> Txs for the clarification (and I learnt a new word from the
> English language, which seems to be of German origin;-).
>
> You are correct, of course. If I want to know if I've compiled a
> program file like, for example, "find", I will cd into the
> $LFS/static/bin directory and type "./find --version". Either I
> see an id string like "find version 4.1 etc." or maybe the
> program file is not there or I made a mistake and did not link it
> statically, so I would not get the expected result.
>
> If I, contrary to that, would like to know if I have the same
> program file on my host distribution, I would type on the console
> "find --version", and bash will find the program file in the
> path, for example /bin, and not the one situated in
> /mnt/lfs/static/bin.
>
> The difference to search for the program files with "find" is,
> that by this I can be sure they are working properly.

This is something of a moot point, since _unless you're chrooted_ at the
time you test the files in your /mnt/lfs/static/bin directory, they could
be built improperly _and_ still work.  The entire point of the initial
static build environment is to make a clean getaway from the shared
libraries installed by the host distro.  Inside the chrooted environment,
your new binaries can't get at those shared libraries at all, which is
reasonably clean enough for this purpose.  The problem this is getting
around is that sometimes (read: annoyingly often, or for certain when
you're ni a hurry) shared library symbols and code will manage to make
their way from the old libraries and be replicated exactly in the _new_
libraries, which may or may not be compatible with new packages.  Meaning
if you attempt to do LFS without that static build environment, around 7
times out of 10 things are going to start mysteriously exploding soon
after building a new glibc version.

> Concerning the missing program files, I found out that gasp,
> mentioned in the lfs book as a binutil file, is not mentioned in
> the doc-files of binutils, and the "gasp" from my host
> distribution is Version 1.2, which makes it doubtful if it is
> part of modern binutils, now in the 2.13 range. I think the entry
> in the LFS book may be obsolete, but of course, there might be
> something I do not yet understand properly.
> Some of the files from Findutils which I thought were missing in
> the 20020215 version of the LFS book I found in libexec, so
> that's one of the cases where I did not search long enough.
> Probably I should have a look at the makefiles to see what they
> do.

It's very possible that SuSe has installed a version of gasp separate from
binutils for reasons of their own.  I was mistaken before when I referred
to it as `as`.  Still, I would not worry about it for more than a moment.
I've been using essentially the same build script for binutils (one of
those things I've always had to replace for one reason or another) for
about two years now, and after poking at several other machines I see that
they don't have gasp either.  Weird that binutils is building but not
installing it.  My guess is that it's use was deprecated some time ago.
(Which seems logical, since there's an awfully large number of "tiny
moving parts" to the compiler toolchain)

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-support' in the subject header of the message



More information about the lfs-support mailing list