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.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
