On Mon, May 28, 2012 at 01:52:38PM -0500, Bruce Dubbs wrote: > Continuing this thread. > > I built a current SVN and stopped at udev. Trying to run systemd > configure is a problem. > > 1. It wants intltool > 2. It wants intltool's dependency XML::Parser > 3. It wants libpcap2 and implicitly it's dependency attr > 4. It wants pkgconfig but that can be worked around > 4a. KMOD_CFLAGS=-I/usr/include KMOD_LIBS="-L/lib -llzma -lz" > 4b. BLKID_LIBS=-lblkid BLKID_CFLAGS=-I/usr/include Thanks > > 5. It wants usbutils and it's dependency libusb > 5b USBUTILS_CFLAGS, USBUTILS_LIBS, and path to usb.ids > --with-usb-ids-path=no works. Bryan pointed out this reports an error at runtime, but no worse than what we have been doing since at least udev180. > 6. It wants pciutils > 6b LIBPCI_CFLAGS, LIBPCI_LIBS, and path to pci.ids > similarly, --with-pci-ids-path=no > 7. It wants D-Bus: > 7a DBUS_CFLAGS=-I/usr/include DBUS_LIBS=-ldbus > > And that's just to get through configure.
For 1,2,3,7 thanks for testing. At the moment I've no idea if any of that is fixable (too busy looking at the results from builds and DESTDIR installs, and seeing if there is a "straightforward" way to just install udev. > > I tried to do: make udevadm, but it tied to the shared/ directory and > requires dbus. I wasn't able to work around that without major surgery. > > The problem is that none of these libraries are used for udev. On a > recent blfs system, where the systemd dependent libraries are installed, > I as able to build and looked at the executables and libraries. AFAIK, > the only ones are /bin/udevadm, /usr/lib/systemd/systemd-udevd, > /lib/libudev.so.1.0.0 and /usr/lib/udev/*. > > -- Bruce > [ snipping ldd, except for cdrom_id - the use of libudev by that is new since 181 (my 182 build is on another machine, can't check for the moment) ]. > cdrom_id: > linux-vdso.so.1 (0x00007fff95dff000) > libudev.so.1 => not found > librt.so.1 => /lib/librt.so.1 (0x00007f278504a000) > libc.so.6 => /lib/libc.so.6 (0x00007f2784ca6000) > /lib64/ld-linux-x86-64.so.2 (0x00007f2785252000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00007f2784a89000) I've also noticed the following changes beyond what is in the ticket (after building on a BLFS desktop): 8. The following have gone: rule_generator.functions write_cd_rules write_net_rules man8/scsi_id.8 No idea if any of those matter to anyone here. Brian posted a link to Slackware's DESTDIR install in the ticket (i.e. DESTDIR install, then move the required items to $PKG), at http://connie.slackware.com/~rworkman/standalone-udev-from-systemd/udev.SlackBuild In that they cp -a rules.d/ from $CWD/rule_generator/ and then cp / install the functions and write* progs from the same directory. There are easier ways to get the items in rules.d/ (e.g. from the DESTDIR) but my bigger problem with this is that my download of 183 doesn't have the rule_generator/ directory, nor the functions and write_ programs. 9. Trivially, udev.pc now has udevdir=/lib/systemd. I don't know if anything uses that field, but it should be easy enough to change it back to /lib/udev with a sed. One bright note : although it uses a lot of libtool-foo in the regular install, at the end of 'make' all the udev programs appear to be ready for a conventional install, and libudev.la appears as if it might be in a similar state [ needs further review ]. The static and shared libudev are also present in .libs, together with the version symlinks for .so. So, with judicious use of a few of the rules in the Makefile (install-udevlibexecPROGRAMS, install-includeHEADERS, install-dist_udevconfDATA, install-dist_udevrulesDATA) and a little use of 'install' plus seds to fix up man pages and udev.pc I think the LFS part of the install can be done fairly easily. Not useful until we can actually build it in LFS, but I'm hopeful we'll get there. For BLFS users who need gudev or any of the other parts that LFS can do without, it looks nastier. Do-able, but finding someone to build all the deps and then document how to install the other parts (which may, or may not, be present) in a without-systemd environment may be difficult. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page