On 9/4/06, Jim Gifford <[EMAIL PROTECTED]> wrote:
In the past, we have had anything that has a library needs to be built for each ABI on the system. A lot of people on IRC and on the lists have expressed some concerns with this idealism, so it may be a time of change coming to our ideals. The change would be only build if something else depends on it. So lets visit the facts and come to agreement on 2 such programs that are in the standard CLFS build.This first one is udev. This one has a extra's program that creates a shared library that gets installed libvolume_id.so. Under our current idealism, we need to build these extra programs for each ABI on a system. As it was pointed out to me, this library is only used for udev, why do we need to worry about it. It was also pointed out, that during the build this library is hardcoded to /lib. Under the new idea of just building once with the 64bit abi, would work, but a minor change would need to occur, to keep the schema of things correct. We would need to change all the /lib to /lib64. The second one is iproute2 This one installs a /usr/lib/tc which contains a library specific only to iproute2. This is the same situation as udev, normally we would build for each ABI, but under the new idea, we would build it as 64 bit and make sure the directory goes to /usr/lib64/tc. But in this case since iproute2 is required for bootup, and if /usr is on a different partition, the change would actually need to be /lib64/tc. So I'm putting it out there, what is the community's opinion, I say lets just build it once, if someone finds that some other program needs the library, then we can reevaluate Jim Gifford
As 1.0 release manager, I agree whole-heartedly. If those libraries are private to a certain binary, and not used externally, then I feel there is no sense in building both 32-bit and 64-bit versions, as the 32-bit version would never be used. However, we should ensure that they do end up in the proper place - i.e. the iproute2 lib should be put into lib64 instead of being dumped in lib. I use a script to check and make sure no libs have ended up in the wrong location, and this lib causes a spurious error. Jeremy CLFS 1.0 Release Manager CBLFS Lead _______________________________________________ Clfs-dev mailing list [email protected] http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
