Could not determine the host path corresponding to '/work/windows/.libs'

[tresf]

This is a request for help, not a bug report.

When cross-compiling hidapi using llvm-mingw wrapper (a mingw-w64 wrapper around clang, capable of producing ARM64 binaries for Windows, it shows the following error:

Bad output from llvm-mingw build logs:

  make[2]: Entering directory '/work/hidtest'
    CCLD     hidtest.exe
- libtool:   error: Could not determine the host path corresponding to
- libtool:   error:   '/work/windows/.libs'
  libtool:   error: Continuing, but uninstalled executables may not work.
  libtool:   error: Could not determine the host path corresponding to
  libtool:   error:   '/work/windows/.libs:/usr/local/lib:/usr/local/bin'
  libtool:   error: Continuing, but uninstalled executables may not work.

I assume this is due to /work/hidtest/hidtest.exe not being knowledgeable of /work/windows/.libs, but if that's the case, why does this NOT fail when building using mingw-w64 directly?

Good output from mingw-w64 build logs:

make[2]: Entering directory '/work/hidtest'
  CC       test.o
  CCLD     hidtest.exe
make[2]: Leaving directory '/work/hidtest'
make[2]: Entering directory '/work'
make[2]: Leaving directory '/work'
make[1]: Leaving directory '/work'

Naturally, the build produces usable binaries, only the hidtest.exe seems to fail, which is benign to this particular build system.

Questions:

1. Can I configure make to skip building hidtest.exe to eliminate the error?
2. What types of things can I look at to patch this? Why would the build system fail for this environment only?

Note 1: As a reminder, llvm-mingw uses clang under the covers, so if there are any GNU-specific assumptions in the compiler, I'd be happy to dig deeper. Any help is appreciated!

Note 2: I've searched before asking and found #187, #68. Neither seem to be the same exact problem, but I wanted to link them incase they are. 🍻

[mcuee]

Try using the latest git head and CMake. You may get better result there. And by default, CMake build does not build hidtest.

[mcuee]

BTW, #187 and #68 talk about the legacy Fox based Test GUI application, it has nothing to do with hidtest.

[mcuee]

Another thing, I believe clang is not the issue here. After all, there is no issue to build hidapi under macOS which use clang.

[Youw]

Can I configure make to skip building hidtest.exe to eliminate the error?

autotools doesn't have such option, but you could remove this and this lines to skip hidtest build

---

We're not looking to support nor improve autotools build system. If you come up with a clean working patch - we will accept it, but otherwise prefer using CMake instead.

[tresf]

remove this

Thanks, that's helpful, I'll see what's going on with that additional makefile.

If you come up with a clean working patch

That's what I'm hoping.

but otherwise prefer using CMake instead.

I'm normally not afraid to using CMake, but this particular downstream project uses autotools currently for 10 separate targets, so I'll take a swing at a quick patch first.

[tresf]

latest git head

For clarification, it is the latest HEAD from master branch.

[tresf]

Using this bug report as a scratch pad, I hope that's ok? So for starters, the linking in the hidtest.exe is as follows:

LINK = $(LIBTOOL) $(AM_V_lt) --tag=CC $(AM_LIBTOOLFLAGS) \
	$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
	$(AM_LDFLAGS) $(LDFLAGS) -o $@

The first AM_V_lt is verbosity. Digging into this shows I can call make V=1 to increase verbosity of the automake system, which successfully outputs a more verbose command:

/bin/bash ../libtool  --tag=CC   --mode=link /usr/xcc/aarch64-w64-mingw32-cross/bin/aarch64-w64-mingw32-gcc  
   -g -O2  -no-undefined -o hidtest.exe test.o ../windows/libhidapi.la -lsetupapi

libtool: link: /usr/xcc/aarch64-w64-mingw32-cross/bin/aarch64-w64-mingw32-gcc -g -O2 -o 
.libs/hidtest.exe test.o  ../windows/.libs/libhidapi.dll.a -lsetupapi -L/usr/local/lib

... which seems to be properly referencing the archive by relative path.

What's particularly interesting is that the libtool command is properly linking ../windows/.libs/, however according to libtool's documentation, may simply be a file name conversion failure? Maybe not though...

First thing that comes to mind is the lib suffix, but I don't see how this could cause issues, I'd expect this to fail on mingw too, but it doesn't, so I'll scrap that idea... Next, I stumbled upon this similar post: VirusTotal/yara#933 (comment), which mentions this could go away if the required library is installed. Oddly, it doesn't. make install does seem to install it, but it doesn't fix the problem.

libtool: install: aarch64-w64-mingw32-ranlib /usr/local/lib/libhidapi.a
 /bin/mkdir -p '/usr/local/include/hidapi'
 /usr/bin/install -c -m 644 ../hidapi/hidapi.h '/usr/local/include/hidapi'

Same error:

libtool: link: /usr/xcc/aarch64-w64-mingw32-cross/bin/aarch64-w64-mingw32-gcc -g -O2 -o .libs/hidtest.exe test.o  ../windows/.libs/libhidapi.dll.a -lsetupapi -L/usr/local/lib
libtool:   error: Could not determine the host path corresponding to
libtool:   error:   '/work/windows/.libs'
libtool:   error: Continuing, but uninstalled executables may not work.
libtool:   error: Could not determine the host path corresponding to
libtool:   error:   '/work/windows/.libs:/usr/local/lib:/usr/local/bin'
libtool:   error: Continuing, but uninstalled executables may not work.

Then I stumbled upon this post which offers some additional troubleshooting commands such as objdump and (prefix)-nm -B -f POSIX -A libhidapi.a, but this didn't really offer any more insight. The files looked fine from what I can tall.

... but this looks like a linker issue, so I decided to take one final look, run make V=1 and see if I could observe any obvious differences between libtool calls for mingw "proper" and mingw "wrapper". The main difference I can find is this:

• The "wrapper" makes use of a dedicated aarch64-w64-mingw32-ranlib, whereas mingw uses the system-provided one. This is likely to do with the clang dependency of the wrapper. Changing this to the system ranlib doesn't fix it either, but at this point I'm shooting in the dark.

So I thought that was it... I couldn't find any discernible differences between mingw proper and the clang wrapper tool. This leads me to believe that the error is actually a misconfiguration with the mingw wrapper and autotools, specifically the function that tries to convert unix paths to w32 paths, func_convert_file_nix_to_w32, but when I dump out the libtool code between builds, this func_convert_file_nix_to_w32 function is identical.

Edit: Mistakes hidden, click to show.

So, what else could be different? Well, I stumbled up on the BUILD.autotools.md file which states the following config option is available:

--disable-shared
     By default, both shared and static libraries are going to be built/installed.
     This option disables shared library build, if only static library is required.

So I took a second look at libtool and spotted the following differences:

mingw "proper" versus "wrapper":

  # Whether or not to build shared libraries.
- build_libtool_libs=no
+ build_libtool_libs=yes

Is this just a matter of the wrapper I'm using defaulting to building shared libraries? If so, is that something the environment does automagically or something that hidapi has defined somewhere in an automake file?

So long story short, this seems to fix it:

./configure --disable-shared 

... but I'd love to fix this project-side if possible. If not, this can be closed. :)

Edit: Re: hidden stuff above... my tests were wrong, they both build shared libraries, if they don't, no .dll is generated... Still digging...

[tresf]

Sorry, had to edit out some stuff above. I've left it and hidden it for historical purposes.

Anyway... I think I found something that fixes this, but I'm not sure if it's welcome in the codebase:

hidtest/Makefile.am:

  hidtest_SOURCES = test.c
+ hidtest_LDFLAGS = -all-static
  hidtest_LDADD = $(top_builddir)/$(backend)/libhidapi.la

I still have a sneaking suspicion something is toggling this on for mingw, I just don't know where to look. 😅

[tresf]

WIthout changing the hidtest/Makefile.am, LDFLAGS="-static" or CFLAGS="-static" seems to fix this as well. I'm not really sure the impact of this, so I'll test the resulting binary on a Windows ARM64 computer to make sure it still works.

[tresf]

The produced binary works just fine in my tests using ./configure LDFLAGS="-static", so I'm closing this out as a configuration issue (my problem)/possible upstream issue (not hidapi's problem, perhaps llvm-mingw's or upstream clang/llvm).

Anyway, I hope the information above is useful to someone else running into a similar problem down the road. If anyone has more information to add, please let me know. :)