Original issue: https://github.com/midipix-project/slibtool/issues/17
Opened by: https://github.com/codebrainz

codebrainz commented on Sep 16, 2019

There are no instructions and the configure script just dies silently without generating a Makefile, and leaving behind a directory (ccenv) that causes the configure script to fail loudly the next run when it can't delete the non-empty directory.

It would be cool to use a real build system like Autotools for this project, instead of an own-rolled thing that is a nightmare to port and debug.

Platform: Win10 with up-to-date MSYS2 environment.

codebrainz commented on Sep 16, 2019

Just as a follow up, after reading through some of the bash scripts and seeing an error message which never fired, I tried doing an out-of-tree build, which still didn't work, so I commented out the set -eu at the start of the bash script and it finally completed leaving me a Makefile.

Unfortunately the homemade configure script doesn't appear to do any feature-checking like autoconf does so it didn't do any checks/tests to find them or error out. After hacking around the spawn.h issue, I got stuck with sys/wait.h issues.

I guess nobody ever tried to build this on msys/mingw before, which is sad since Libtool is SUPER slow on Windows and this seemed like a decent possibility to replace it.

midipix commented on Sep 17, 2019

Glad to help, but let's clear up some larger issues first. Every build system is rolled by someone, and sofort has now proven to be robust and solid on numerous systems (and much, much faster than autotools, btw.) which include not only linux and midipix, but also bsd, osx, and cygwin. The msys2/mingw combination hasn't been tried yet, indeed, and if you join us on irc I'll be glad to take a look at it and see whether this could be fixed.

The real blockers, however, are presumably spawn.h and sys/wait.h. I believe these can be worked around, possibly using a light downstream patch. So again, please join us on irc for a discussion on how to proceed in order to get a "native" (linked against msvcrt) sofort executable (but see below).

As for mingw support: slibtool is known to work out of the box with mingw as a target. So far, this has only been tried with mingw as a cross-target, that is, when compiling for mingw from either linux or midipix (which runs on NT but has linux-like semantics). This is possible thanks to how slibtool is written, its seamless support of cross-compilation, and its always-included support of .EXE-related semantics. Now, since msys2/mingw is already a cross compilation environment, one easy workaround for you would be to build slibtool inside of msys2's "native" shell. All targets are supported by slibtool no matter which system you're using, so there's no reason to try to build it in msys2's mingw environment.

This brings me to the last point, which is why no header presence checks are performed at startup. slibtool assumes that the host compiler supports -std=c99 (that's in the README), and is also reasonably posix-ish. Now, that seems to be absent from the README, and so should be added. And more noise at configure time should probably be added as well. As a build system, sofort certainly does support a variety of tests (in a cleaner and faster way than autotools, btw. just saying...), and can be used, for instance, even for much larger tasks, e.g. to perform a clean, cross-building of python (https://git.midipix.org/python/sbpython3/).

So to sum up: you can already use slibtool in your mingw environment for as long as you build it in msys2's native environment (which is the same as building on cygwin). That is pretty much how all other mingw-targeting tools get built, and as soon as you do that the problems you've experienced should be gone. Perhaps you thought that slibool needed to be specifically on the target for which you'll be using it, but as stated below, that is not the case. Cheers.

codebrainz commented on Sep 17, 2019

I'm sorry if I sounded frustrated/curt towards the build system; I don't like developing/compiling on Windows and especially with MSYS2, and I just wanted something to "just work". Even if super slow on Windows, the crufty old Autotools seem to "just work" for MSYS2.

FWIW, I was trying to use this project as a replacement to compare if it was GNU Libtool that was slow in our MSYS2 Autotools build, see issue here.

midipix commented on Sep 17, 2019

Word well taken, perfectly understood:=) In the meantime, I just tested again that building slibtool on cygwin (same as msys2) works out of the box (both the build and the tool) and that is still the case. I currently do not have an msys2 installation on this machine, but it should be the same, so if you run into any issues please let me know.

codebrainz commented on Sep 17, 2019

I just tested again that building slibtool on cygwin (same as msys2) works out of the box

I don't believe cygwin and msys/mingw are the same. As far as I know cygwin has a special emulation layer/library to make more Posix-ey stuff work, whereas msys/mingw just makes "native" win32 binaries without the cygwin.dll stuff. I guess that's probably why it works with one and not the other.

midipix commented on Sep 18, 2019

While this easily goes unnoticed, msys2/mingw is in fact a cross-compilation environment; and if memory serves, you should find under your msys2 installation two shortcuts, the first for msys2/msys2 (when building msys2's own tools), and msys2/mingw (the default, and what most users use).

You could easily verify that msys2 is based on cygwin via the following command:

$ objdump -x $(which bash) | grep NEED

What you need, then, is to build slibtool in the msys2/msys2 environment, and then use it in the msys2/mingw environment.

midipix commented on Oct 16, 2019

Any updates on the above? Were you able to build slibtool under msys2 and then use it under mingw?

codebrainz commented on Oct 21, 2019

No updates, I never tried again. Feel free to close this issue or treat it as an "enhancement" issue for documentation improvements, like how to install in general and also on Windows.

midipix commented on Oct 21, 2019

Thanks for following up and taking the time to report. Leaving this open for now until at the following is in place:

1. proper documentation regarding mingw support (build under msys2, run under mingw's shell environment).
2. more verbose configure error output in general.
3. and a proper config.log output in particular.

midipix commented on Jan 4

Following up on the above:

1. proper documentation regarding mingw support (build under msys2, run under mingw's shell environment).

Added in commit 4da8c1b.

2. more verbose configure error output in general.

Added with commit 54797a9.

3. and a proper config.log output in particular.

added with commit a8f1884.

midipix closed this on Jan 4