I agree that working around libtool's issue by copying is not the best
solution. Let's hope it gets fixed in libtool someday.
I think it's worth to mention that if user manually creates a symbolic or hard
link named pthread.dll to winpthread-1.dll it will be sufficient to work around
this issue.
What about static and import library filenames when building from MSVC? If the
library is expected to be built only from mingw-w64 and msvc then there are
only two naming conventions to consider and using hardcoded library names is
rather easy. Using libtool's libwinpthread.la to construct alias filenames
seems convenient, but it probably has to be tested every time new version of
libtool is used.
- Kirill Makurin
________________________________
From: JonY via Mingw-w64-public <mingw-w64-public@lists.sourceforge.net>
Sent: Wednesday, November 13, 2024 9:22 AM
To: mingw-w64-public@lists.sourceforge.net
<mingw-w64-public@lists.sourceforge.net>
Cc: JonY <jo...@users.sourceforge.net>
Subject: Re: [Mingw-w64-public] Building winpthreads with MSVC tools
On 11/12/24 18:52, Kirill Makurin wrote:
> Hi,
>
> I have made some changes to the patch3, including using LN_S instead of `cp
> -f` (but see below).
>
> First of all, I split it into two different patches. One for Makefile.am and
> configure.ac, and another for tests/Makefile.am since the changes are not
> directly related.
>
> A few days after I submitted the patch, I have encountered some
> libtool-related issue. When libtool is used to produce a DLL which depends on
> another DLL and its LIBNAME.dll.{lib|a} import library is used, libtool
> searches the linker's runtime search path (that is, PATH on windows) for file
> named LIBNAME*.dll and if it is not found libtool complains and refuses to
> produce the DLL. Example of libtool's output is in libtool-complains.txt.
>
> This means that creating aliases only for static and import libraries in not
> sufficient. We also need to provide an alias for the DLL as well. This is
> getting more complicated given that users may choose to pass libtool's
> `-avoid-version` to LDFLAGS. (I find using `-avoid-version` convenient for
> local installations).
>
> I figured out that we could use names of library files from libtool's
> libwinpthread.la and simply replace `winpthread` with `pthread` to build
> alias names. This is what patch3-1b.txt does.
>
> I also find it reasonable to comment out lines of configure.ac which create
> Automake conditionals COPY_STATIC and COPY_SHARED, since they are no longer
> used in Makefile.am.
>
> Attached patches are:
>
> patch3-1a.txt: Makefile.am and configure.ac. Does not use libwinpthread.la to
> build alias names. Uses hardcoded names.
> patch3-1b.txt: Makefile.am and configure.ac. Uses libwinpthread.la to build
> alias names.
> patch3-2.txt: tests/Makefile.am.
patch3-2.txt is fine.
-avoid-version really shouldn't be used, especially if there is no
guarantees against future ABI change, it would cause dependency hell.
As for the warning, I prefer that file magic command be fixed for
libraries rather than working around by file copying.
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
