Page MenuHome GnuPG

Windows builds use "winepath" when it is available
Open, LowPublic

Description

Build time of for example of libgpg-error is very slow for me when wine is installed.

A clean libgpg-error windows build time for me is 33 seconds with 25 make jobs on a 24 thread machine.
If I replace "winepath" with /usr/bin/false this same build is reduced to 4.5 seconds.

I don't understand why the compile and ltmain.sh in libgpg-error uses winepath. Maybe for some integrated testing to run tests when wine is installed?

Has low prio for me because I now have a workaround but it took me a bit to find the problem.

Event Timeline

Winepath starts calls the full Wine engine just convert file names to DOS format. This is used by libtool but if winepath can't be executed, it doesn't care. So the given solution (using /etc/alternatives/winepath -> /bin/false) can be used.

We can of course update our copy of libtools (i.e. ltmain.sh) to disable this. Might be a good idea the next time we need to fix something.

I learned that Unix build environment needs Wine emulation (with winepath) for MinGW host (when uninstalled executable should run correctly).
https://www.gnu.org/software/libtool/manual/html_node/File-name-conversion.html

For me each time wine is upgraded I get for the first time an error when building something, but it is not slow anymore. Is this resolved?

My summary here:

  • Use of winepath by libtool is correct way for semi-hosted environment to run tests built by cross-build.
  • (cross-)Build itself is possible with no winepath (or winepath -> /bin/false), if you don't need make check with semi-hosted environment.
  • I don't see that it's too slow, these days. My environment is bookworm Debian (having Wine 8.0 something).

Noticed this again that it was very slow. I guess how fast it is depends on your wine configuration. I worked it around by disabling winepath for me again. But do we want to change anything here or just move this to wontfix?