I think this could be a libtool issue, but this one should be easy to figure out:
from a git master checkout, do:

git bisect bad origin/master
git bisect good 1.6.0
git bisect run make

And wait. Let's assume 1.6.0 is good, because otherwise you would've noticed it a lot earlier. git bisect will run make on every revision until it finds the one that broke things. Depending on how likely that commit looks like, we'll know if we busted something in libinput or if libtool is broken.

Had to bisect from a known-good commit from a few months ago (6ba530f2d8038c433d5e849f23815f528666d155) since there didn't seem to be a 1.6.0 tag available.

Nevertheless, I'm not sure it worked. It seems to have instead found the commit causing a *different* issue that it also died on while trying all those revisions:



/usr/bin/ld: libinput_debug_gui-libinput-debug-gui.o: undefined reference to symbol 'udev_new@@LIBUDEV_183'
//lib/x86_64-linux-gnu/libudev.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:620: recipe for target 'libinput-debug-gui' failed
make[2]: *** [libinput-debug-gui] Error 1
make[2]: Leaving directory '/home/nate/SpiderOak Hive/Software projects/git projects/FreeDesktop/libinput/tools'
Makefile:445: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/nate/SpiderOak Hive/Software projects/git projects/FreeDesktop/libinput'
Makefile:377: recipe for target 'all' failed
make: *** [all] Error 2
a69294251df92e818f695cd2456c8eb860e02522 is the first bad commit
commit a69294251df92e818f695cd2456c8eb860e02522
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed May 24 10:36:44 2017 +1000

    Fold the event-gui into the libinput tool
    
    It's common enough for users to want to debug libinput behavior without
    interference by the compositor or the X server. Being able to run a GUI
    without having to compile from git is helpful.
    
    Note that this changes --enable-event-gui autotools option to
    --enable-debug-gui and the event-gui mesonconf option to debug-gui.
    
    This also drops the standalone event-gui binary in both autotools and meson.
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

:100644 100644 338d385cc777bb4e94fd068576bd46b9526e0e39 3d60337cb7a5bbd76be99434d576d6eca9354c67 M   configure.ac
:100644 100644 0bd96a941d8090803d5a228998a7c91d019220b0 552f51ef940f7871ab0c2a956d42eca906ec7f0a M   meson.build
:100644 100644 5cd6d70ee7c2e34d26061b7a00e876fff0ef0ec3 f432e7ea1fd2028aaeb543fbcad830b036500dba M   meson_options.txt
:040000 040000 dd04c370e303e39c1d08a59b7390442a8976b542 16173187cb50f1effccf524e8f29610c922e7ca2 M   tools
bisect run success

doh. sorry, that was a linker error fixed since in ce12ea6f9. I think you may have to do the git bisect manually in that case, if the udev linker error comes up do a git bisect skip and see if that helps.

git bisect reset to finish the current one, then do the same except instead of git bisect run you have to run make manually, check the output and then run git bisect good/bad/skip depending on the output.

Think I mighta found it:


1603a4326a6e7e8197807f1330bd9b31f0634321 is the first bad commit
commit 1603a4326a6e7e8197807f1330bd9b31f0634321
Author: Paul Kocialkowski <contact@paulk.fr>
Date:   Fri Apr 28 15:32:59 2017 +0200

    udev: Add support for device-tree-based model selection
    
    This adds support for detecting input peripherals based on their name
    and the device-tree model of the device they're used with.
    
    This is mostly an equivalent to dmi-based model detection (e.g. on x86
    devices) for device that use device-tree (e.g. on ARM devices).
    
    Note that this requires systemd updates, see
    https://github.com/systemd/systemd/pull/5837
    
    Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
    Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

:040000 040000 f0aff58b8f3015e65955b2c86b5b053c490e371c 7a723a599700d67f860708fca1b7f882f5781f9c M   udev
bisect run success

That looks like a false positive too, sorry. That patch doesn't do anything with the build system, it's just the first one after the one we skipped to (the one that fixed the udev linker error). But if e9fc59efc853485cb builds fine and 1603a4326a6e7e819 breaks, then at least we know it's a libinput bug.

Can you bisect again between those two? if the build fails add the changes from 56ceac34d0f42f7f9 and ce12ea6f9a0 manually and build again. If that too fails or it succeeds, do a git checkout -f (to get rid of the local changes) or git stash (if you know how to handle stashes), then git bisect bad/good depending on the outcome and hopefully this should tell us the real commit then.

OK, I don't think this is our fault although it doesn't quite explain why it used to work. But googling around for libtool and spaces shows quite a few complaints about this and it's not fixed.

I reproduced it here starting with 56ceac34d0f42f7 but that change is correct. And the command that fails is:
/bin/sh ../libtool  --tag=CC   --mode=link gcc -Wall -Wextra -Wno-unused-parameter -g -fvisibility=hidden -Wmissing-prototypes -Wstrict-prototypes  -I/usr/include/libevdev-1.0/  -O0 -Wall -ggdb3 -Wformat=2 -Wlogical-op -fstack-protector-strong   -o libinput libinput-libinput-tool.o libshared.la ../src/libinput.la -ludev  -levdev  -lrt -lm 

Note how nothing here has the absolute path, that is expanded inside libtool.

If I go back to 20f5f2d962037888a1a, before the many makefile changes recently introduced and I add libinput.la to libshared I get the same error message. So it just didn't get triggered earlier because of a bug in our makefile - now that it's fixed we trigger the libtool bug.

Thanks for investigating. I've filed a bug against libtool. No link, since they don't seem to have a public bugtracker (I had to email it to bug-libtool@gnu.org).