I cannot build GDLMM (hardcoded D:/a/_temp path to m4.exe)

[acidtonic]

I have mingw64 on windows64 trying to build gdlmm and I cannot get the autotools code generation to work. It keeps building a path to a non-existent D drive for the m4 command which then fails and the build cannot complete.

$ clone git repo from -> https://github.com/Fabo/gdlmm.git
$ ./autogen.sh
$ ./configure
$ make
(various entering directory lines)
sh: line 1: D:/a/_temp/msys64/usr/bin/m4.EXE: No such file or directory
m4 failed with exit code 127. Aborting...

I believe this is related to the issue #7481 with hardcoded paths but in that case it with Python, but for me it's M4. Any help or workarounds would be appreciated. I have a binary release build to drop shortly and this is a blocker.

Cheers

[Biswa96]

You can see the procedure about how to build that project here https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-gdlmm2. See the PKGBUILD file.

[acidtonic]

I apologize for any confusion but I had installed that package and it seemed it was not the same version. Thus my attempt to build from source.

That package seems to build gdlmm-1.0 but my project is expecting gdlmm-3.0. Are they the same? The .pc file fails my cmake pkgconfig_check for gdlmm.

Also reading the PKGBUILD file I am not sure where the variables are coming from as I do not have experience with building packages on mingw.

I think I'll review the patch it tried to apply and see if that helps me doing it manually. I will report back.

[stahta01]

To acidtonic did you update your MSys2 packages?

pacman -Syuu

Tim S.

[stahta01]

That package seems to build gdlmm-1.0 but my project is expecting gdlmm-3.0. Are they the same? The .pc file fails my cmake pkgconfig_check for gdlmm.

No, the gdlmm2 package is version 2 not version 3. But, the package might help you. To get rid of the error you posted you need to first update your msys2 packages because that issue has likely been fixed.

Tim S.

[chennes]

sh: line 1: D:/a/_temp/msys64/usr/bin/m4.EXE: No such file or directory

I'm having a similar problem (different program, but same hardcoded path, and same idea of trying to compile something locally that is normally installed via pacman) -- a search of /mingw64 for this path yields over 5000 hits. If memory serves, that looks like the path that GitHub Actions uses for its builds, so maybe this is a problem with the build artifacts?

[chennes]

See also: #9411

[acidtonic]

I ran pacman -Syuu and only had 3 packages updated (pacman itselt, a tty library, and something else non-related). Still have the same issue if I try again with a fresh checkout.

Is there a way to specify the path to m4 or edit a makefile or something? I find it odd the path gets embedded inside an EXE file that generates code.

[acidtonic]

The other issue is similar but the suggested fixes are for missing symbols which I do not have a problem with. I do see this path if I run gcc --print-search-dirs and I'd presume it's in other places as well.

[acidtonic]

Alright well I decided I couldn't wait so I started going deep into this... Managed to hack it and got it to build.

C:/msys64/mingw64/lib/glibmm-2.4/proc/pm/Output.pm

line 1053 -> system("$$self{m4path} $$self{m4args}... (rest of string)

Changed to

line 1053 -> system("/usr/bin/m4 $$self{m4args}... (rest of string)

Now she builds. So perl inside glibmm is trying to do magical things to get the m4 path and it's flat out WRONG.

Have a nice day :)

[Biswa96]

Agree. This seems to be an issue of glibmm package. Some files of that package contain full path reference of build environment. e.g.

$ grep -wr _temp /ucrt64/lib/glibmm-2.4
/ucrt64/lib/glibmm-2.4/proc/generate_wrap_init.pl:#! D:\a\_temp\msys\msys64\usr\bin/perl.EXE
/ucrt64/lib/glibmm-2.4/proc/gmmproc:#! D:\a\_temp\msys\msys64\usr\bin/perl.EXE
/ucrt64/lib/glibmm-2.4/proc/gmmproc:  $main::m4path = "D:/a/_temp/msys/msys64/usr/bin/m4.EXE";

[Biswa96]

What command did you use to build the gdlmm project? In my case, ./configure shows

checking location of documentation utilities... configure: error: not found
The required module mm-common-util could not be found on this system.  If you
are running a binary distribution and the mm-common package is installed,
make sure that any separate development package for mm-common is installed
as well.  If you built mm-common yourself, it may be necessary to adjust
the PKG_CONFIG_PATH environment variable for pkg-config to find it.

[acidtonic]

./autogen.sh
./configure (mine passed, no such error, but I do install mm-common as part of my staging prior to building this software.)
make

[acidtonic]

Also in case it matters, at one point I ran an autoreconf in there per another suggestion via a different resource.

[Biswa96]

Can anyone test if the pull request (#9731) fixes this issue?