[lfs-dev] LFS SVN and Systemd Report
zarniwhoop at ntlworld.com
Mon May 28 14:38:37 PDT 2012
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
> 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
> 6. It wants pciutils
> 6b LIBPCI_CFLAGS, LIBPCI_LIBS, and path to pci.ids
> 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) ].
> 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:
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
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
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-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.
das eine Mal als Tragödie, das andere Mal als Farce
More information about the lfs-dev