Jim Gifford wrote: > since on multilib we are required to build anything with a library to > make sure the library is available in /lib /lib32 or /lib64.
OK, so a better fix would have been to build udev (or at least extras/volume_id) twice. (Not that big of a deal for me, because I don't care if I don't have a 32-bit libvolume_id, but in general that's probably the right way to handle everything. At least for the basic book.) > Here's what we come up with to fix the /lib64 stuff > > for file in `find * -name Makefile`; do > sed -i $file \ > -e '[EMAIL PROTECTED](^libudevdir =\)[EMAIL PROTECTED]/lib64/[EMAIL > PROTECTED]' \ > -e '[EMAIL PROTECTED](^libdir =\)[EMAIL PROTECTED]/[EMAIL > PROTECTED]' \ > -e '[EMAIL PROTECTED](^usrlibdir =\)[EMAIL PROTECTED]/usr/[EMAIL > PROTECTED]' || ERROR > done > sed -i 's@/lib/udev/@/lib64/udev@' udev_utils_run.c Looks like it should work, but would it make more sense to override all three of those from the make command? Of course then that command starts to get even bigger, so maybe not. (The sed to udev_utils_run.c would still be needed, of course.) One issue might be if we split udev into 32-bit and 64-bit, the 32-bit install will still create /lib/udev, but the final binary won't use that directory. Might be a little confusing for the user; maybe we should change libudevdir in both 32- and 64-bit udev? Of course that may not be possible given the book's setup, I'm not sure.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Clfs-dev mailing list [email protected] http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
