[lfs-dev] Putting a copy util-linux in /tools

Bruce Dubbs bruce.dubbs at gmail.com
Sun Jan 19 09:38:43 PST 2014


Bryan Kadzban wrote:
> Armin K. wrote:
>> On 01/19/2014 12:45 AM, Bruce Dubbs wrote:
>>> Armin K. wrote:
>>>
>>>>> I'm glad you reminded me of that.  I suppose I could avoid a lot of
>>>>> changes if we made the symlinks, including one for
>>>>> /usr/include/{blkid,uuid}/. I'll keep investigating.
>>>>>
>>>> You don't really want to do this. If /usr/include/blkid is a symlink to
>>>> /tools/include/blkid, make install in chapter6 might install the
>>>> headers in /tools and that's not what we want. Furthermore, make
>>>> install might fail because it wants to create a directory but there's a
>>>> symlink in place. Special case is just to symlink the header files if
>>>> there aren't many to a directory in /usr/include.
>>>
>>> Yes, I thought about that.  An easy solution would be to just remove the
>>> symlinks just before the install phase of util-linux.
>>
>> Given that /usr/include/uuid contains uuid.h and /usr/include/blkid
>> contains blkid.h, it might not be hard to symlink the headers in a
>> previously created directories from /usr/include/{blk,uu}id/{blk,uu}id.h to
>> /tools/include/{blk,uu}id/{blk,uu}id.h
>>
>> It's your call. I don't have anything against your suggestion though.
>
> It seems to me that files required at runtime (that is, the libfoo.so soname
> symlink and the target of that link) could be handled differently than files
> required at build time (libfoo.so itself and the include files).
>
> The latter can be done with only gcc flags -- specifically -I and -L -- and
> since they're only needed at build time, they don't require changing the
> filesystem.  The former will need either LD_LIBRARY_PATH at runtime, or
> figuring out how to add -Wl,-rpath,/tools/lib (...lib64...) to the gcc
> LDFLAGS, or a symlink.
>
> -rpath is probably *not* good, because it'd mean we would have to rebuild
> whatever got built with the -rpath after the libs got installed in their final
> location.  Sorta defeats the purpose of using the /tools version in the first
> place.  I don't think a symlink is too bad.
>
> Actually... that brings up a good point.  Nothing else in the book needs this,
> because everything else relies on the PT_INTERP field pointing at the /tools
> dynamic linker when the binary in question requires libraries in /tools, and
> pointing at the /lib dynamic linker otherwise.  (Because we install deps in
> strict order.)  Are we sure that nothing will ever autodetect some feature
> differently with the /tools lib{blk,uu}id versus the final /lib ones?  Might
> require a little more attention to "can the book rebuild itself" type tests.

I've been doing a lot of testing with this.  We can use -L and -I where 
needed and LD_LIBRARY_PATH fixes the runtime issues during build, but I 
don't really like jumping through all those hoops.  The package that 
gives the most problem is e2psprogs.  It wants libblkid and uuid but 
can't find them in /tools without help.  udev also wants those libraries 
and needs LD_LIBRARY_PATH to load those libraries.  My lastes thinking 
is that a couple of symlinks early can fix things up across multiple 
packages.  That seems to be the least intrusive method to me right now, 
but I won't commit until I'm satisfied with the changes.

Right now I'm a little busy with non-LFS tasks, so it may be a few days.

   -- Bruce




More information about the lfs-dev mailing list