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