Bryan Kadzban wrote:
Udev's extras/volume_id program installs a static/shared library and a
pkgconfig file. (Currently, no other extras/ program does this.) With
the current 1.0.0rc4 multilib book instructions, these files get put
into /lib/libvolume_id.so.* (and /usr/lib/libvolume_id.{a,so}), and
/usr/lib/pkgconfig, because /lib and /usr/lib are the defaults.
There are several problems with this setup -- first, the 64-bit
volume_id won't run ("libvolume_id.so.0: cannot open shared object file:
No such file or directory", because it's in /lib not /lib64). Second,
any 32-bit program that links against libvolume_id.so won't get the
right version; it'll either fail to compile, or it'll fail at runtime
with a "wrong ELF class: ELFCLASS64" error on libvolume_id.so.0.
If we change the install step's instructions to be:
make DESTDIR=/ \
EXTRAS="extras/floppy extras/cdrom_id extras/firmware \
extras/scsi_id extras/volume_id extras/ata_id extras/usb_id \
extras/edd_id extras/dasd_id extras/path_id" udevdir=/dev \
libdir=/lib64 usrlibdir=/usr/lib64 install
(i.e. add libdir and usrlibdir), then the .so.* will go into /lib64,
the .so symlink and .a file will go into /usr/lib64, and the pkgconfig
file will go into /usr/lib64/pkgconfig. (This matches e.g. e2fsprogs'
pkgconfig files; the 64-bit version is in /usr/lib64/pkgconfig.) libdir
and usrlibdir are not used anywhere else in udev's build system (at
least not yet).
Since vol_id is built as a 64-bit binary and shared library, I think
this is a no-brainer.
We *may* also want to consider moving the /lib/udev directory to /lib64,
but that's not an easy change. It'd require a sed or patch to
udev_utils_run.c and maybe other udev source files, because they have
/lib/udev hardcoded. I don't think it's something to do between two
release candidates, in any case; udev should still work fine.
------------------------------------------------------------------------
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
Bryan,
We just noticed this a few days ago, we thought it was a udev 098
thing only. We have a way to fix it. We are debating about holding that
for the 1.0 update release.
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/cgi-bin/mailman/listinfo/clfs-dev
