Greetings from MSYS2/MinGW64

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.

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.

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.