Created attachment 442652 [details] build log x86_64-pc-linux-gnu-gcc -Wl,-O1 -Wl,--as-needed -shared -Wl,-soname=libmultipath.so.0 -Wunused -Wstrict-prototypes -O2 -g -pipe -Wformat-security -Wall -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fPIC -DLIB_STRING=\"lib64\" -DRUN_DIR=\"run\" -I../libmpathcmd -DLIBDM_API_FLUSH -D_GNU_SOURCE -DLIBDM_API_COOKIE -DLIBUDEV_API_RECVBUF -DUSE_SYSTEMD=1 -DLIBDM_API_DEFERRED -o libmultipath.so.0 memory.o parser.o vector.o devmapper.o callout.o hwtable.o blacklist.o util.o dmparser.o config.o structs.o discovery.o propsel.o dict.o pgpolicies.o debug.o defaults.o uevent.o switchgroup.o uxsock.o print.o alias.o log_pthread.o log.o configure.o structs_vec.o sysfs.o prio.o checkers.o lock.o waiter.o file.o wwids.o prioritizers/alua_rtpg.o -lpthread -ldl -ldevmapper -ludev -L../libmpathcmd -lmpathcmd -lsystemd-daemon /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lsystemd-daemon collect2: error: ld returned 1 exit status make[1]: *** [Makefile:59: libmultipath.so.0] Error 1 make[1]: Leaving directory '/var/tmp/portage/sys-fs/multipath-tools-0.6.2/work/multipath-tools-e165b73/libmultipath' make: *** [Makefile:42: recurse] Error 2 * ERROR: sys-fs/multipath-tools-0.6.2::gentoo failed (compile phase): * emake failed
Not sure why this version does not have a FILESDIR entry similar to multipath-tools-0.5.0-systemd-pkgconfig.patch ?
it compiles fine with one thread. -j1. i just went to /var/tmp/portage/sys-fs/multipath-tools-0.6.2/work/multipath-tools-e165b73, went make, then ebuild /usr/portage/sys-fs/multipath-tools/multipath-tools-0.6.2.ebuild merge. that should take care of it.
(In reply to Alexandru N. Barloiu from comment #2) > it compiles fine with one thread. -j1. It didn't here: MAKEOPTS="V=1 -j1"
(In reply to Chris Smith from comment #3) > (In reply to Alexandru N. Barloiu from comment #2) > > it compiles fine with one thread. -j1. > > It didn't here: > MAKEOPTS="V=1 -j1" Nor here.
Hi, I believe, these lines in the ebuild are causing the problem: ... src_compile() { # LIBDM_API_FLUSH involves grepping files in /usr/include, # so force the test to go the way we want #411337. emake LIBDM_API_FLUSH=1 CC="$(tc-getCC)" SYSTEMD=$(usex systemd 1 "") } ... To be exact, the expansion for SYSTEMD. During the make run, that leads to a command line below. # ebuild multipath-tools-0.6.2.ebuild compile ... make -j5 LIBDM_API_FLUSH=1 CC=x86_64-pc-linux-gnu-gcc SYSTEMD=1 ... If you look at the file /var/tmp/portage/sys-fs/multipath-tools-0.6.2/work/multipath-tools-e165b73/libmultipath/Makefile, you'll find the following construct: ifdef SYSTEMD ifeq ($(shell test $(SYSTEMD) -gt 209 && echo 1), 1) LIBDEPS += -lsystemd else LIBDEPS += -lsystemd-daemon endif endif Notice the test for greater 209. I've experimentally edited the ebuild and changed the SYSTEMD to read like "SYSTEMD=231", then everything compiles/links just fine.
Thanks Frank Ridderbusch
Confirmed, same here. single-threaded compilation with MAKEOPTS="-j1" does not help.
Hi, So what is the current solution? I assume systemd likes to link -lsystemd and not -lsystemd-deamon, right? Everyone fixed the ebuild themselves?
(In reply to Andreas Oehler from comment #8) > Hi, > > So what is the current solution? > I assume systemd likes to link -lsystemd and not -lsystemd-deamon, right? > Everyone fixed the ebuild themselves? Well, the fix in comment #5 works fine in itself but is not a long-term solution given that systemd-232, etc., will no doubt appear in due course. Personally I do think that accomodating the changes in different versions of systemd is not something the userbase should have to manage individually if multipath-tools is going to be actively maintained.
we only have >=sys-apps/systemd-218 in the tree, so the check from comment #5 is always true in Gentoo's case.. Maybe we should simply epatch the Makefile to unconditionally link against -lsystemd ?
Thanks for the answer - i anyway wonder what has drawn the multipath thing into my tree... - going to find that out and maybe remove it for now. For the suggestion of Christian: i think it is good practice to always handle the current (and potential future) working version as default and only handle specific fixes for past versions via exceptions (if xx==yy), unless there is a compelling reason for not doing so. In this case, if really no systemd-daemon is remaining in the tree, then why keeping this switch at all Thanks and Cheers Andreas
Why not just use 'best_version' to get the current version of systemd?
*** Bug 591614 has been marked as a duplicate of this bug. ***
I just pushed a fix in multipath-tools-0.6.2-r1 to the tree (using `pkg-config --version systemd`), as discussed on IRC.
One question: If we rely on the systemd version on compilation of multipath-tools (it is a information that is inject in the source compile function). Should we rebuild multipath-tools on every systemd bump to ensure that it is compiled against the correct version. As long as the compile time information is the version itself and not a flag if systemd should be used...?
