Greetings from MSYS2/MinGW64

Installing
1

I am trying to put together a mingw64 package for msys2, and I got quite far. But there is an interesting warning, and I can reproduce it in Linux too. This is the warning from makepkg-mingw:

...
[100%] Built target test_certificates
[100%] Built target library_index_library_cql
Install the project...
-- Install configuration: "Release"
==> Tidying install...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Stripping unneeded symbols from binaries and libraries...
  -> Compressing man and info pages...
==> Checking for packaging issues...
==> WARNING: Package contains reference to $srcdir
mingw64/bin/archive4pl.dll
mingw64/bin/bdb4pl.dll
mingw64/bin/cgi.dll
mingw64/bin/crypt.dll
(and a few more)
==> Creating package "mingw-w64-x86_64-swi-prolog"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Generating .MTREE file...
  -> Compressing package...
==> Finished making: mingw-w64-swi-prolog 8.4.2-1 (Thu Mar 17 15:14:39 2022)

Matthias@DESKTOP-A2T8IFC MINGW64 ~/mingw-w64-swi-prolog
$

I can actually reproduce it on Linux:

  • git clone…
  • cd swipl-devel
  • git submodule etc.
  • cmake …
  • make
  • make install

Now I search for the string “/home/matthias/swipl-devel/build” in the so-files of the installation:

matthias@DESKTOP-A2T8IFC:~/swipl-devel/build$ grep -R ~/swipl-devel/build /usr/local/lib/swipl/lib/x86_64-linux/
grep: /usr/local/lib/swipl/lib/x86_64-linux/socket.so: binary file matches
grep: /usr/local/lib/swipl/lib/x86_64-linux/prolog_stream.so: binary file matches
grep: /usr/local/lib/swipl/lib/x86_64-linux/libjpl.so: binary file matches
etc.

I am unsure, but may this indicate a problem? The location of the source or build folder is arbitrary, so in my opinion, it shouldn’t be kept.

2

On Linux, it turns out the matches are from the (debug) symbols. The normal build includes the debug symbols. This ensures we get a good deal of detail in the case we get a crash. After running strip(1) on the .so files there is no hit.

3

Ah, of course, I forgot. Yes, indeed, the source path is away after strip.

In the Windows dlls, it is still there, but for now, I close the case.