Shared linking errors

[drfiemost]

I'm trying to make a package for libopenmpt, a mod player library evolved from libmodplug and actively maintained, but facing the following error which prevents the shared lib to be built:

*** Warning: linker path does not have real file for library -lz.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libz and none of the candidates passed a file format test
*** using a file magic. Last file checked: C:/msys64/mingw64/lib/libz.dll.a

*** Warning: linker path does not have real file for library -lrpcrt4.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with librpcrt4 and none of the candidates passed a file format test
*** using a file magic. Last file checked: C:/msys64/mingw64/x86_64-w64-mingw32/lib/librpcrt4.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

Both libraries are installed and recognized like the other:

$ file /mingw64/lib/libz.dll.a
/mingw64/lib/libz.dll.a: current ar archive

$ file /mingw64/x86_64-w64-mingw32/lib/librpcrt4.a
/mingw64/x86_64-w64-mingw32/lib/librpcrt4.a: current ar archive

What's going wrong? I've tried also running autoreconf -fi in advance but no luck.
I'm attaching the pkgbuild for reference.

PKGBUILD.txt

[Biswa96]

I can not reproduce your issue in my PC. Maybe something was corrupted in your MSYS2 installer. Try with a new msys2 install or commit the PKGBUILD in your fork repository and let GitHub Actions to build it for you.

[drfiemost]

Ok thanks, I will try. Weird thing is that other packages using zlib builds fine.

[revelator]

there has been reports of this behaviour on win10 a workaround is to put this in before configuring in PKGBUILD
export lt_cv_deplibs_check_method=${lt_cv_deplibs_check_method='pass_all'}

[drfiemost]

Yep, that did the trick! Thanks

[revelator]

np we are here to help :) though it is kinda strange that it only seems to affect win10 users.

[GitMensch]

there has been reports of this behaviour on win10 a workaround is to put this in before configuring in PKGBUILD
export lt_cv_deplibs_check_method=${lt_cv_deplibs_check_method='pass_all'}

Just to recheck: if this is a common issue (I've just suggested the same to someone with a similar problem that a package on mingw64-shell did not compile any more after passing --enable-code-coverage to the configure script - should the export be part of the MSYS2 default profile? It seems a bunch of packages have added this in the PKGBUILD, which seems to be bad: if that is "commonly needed", why not exporting it by default?

[revelator]

perfectly sure :) i done it numerous times.

[revelator]

you need a small piece of code invoking loadlibrary on the dll with msvc but perfectly doable, gcc is easier though ;) the dll also needs to be located besides the program using it or on path but the same is true with mingw unless you specifically write code to load it from another location.

[revelator]

holy batman file's source code is quite a beast :S still trying to find where in the source it determines library types so far not much luck.
it seems it is using lookups based on bit types in the archive (guess that is what the magic part is for).

[GitMensch]

So the issue may be that we don't set the right bits in there to begin with?

[revelator]

that may very well be the case or file might hmm.
not sure where to go from here without getting a hold on the maintainer, he/she might know more about the internals.