MINGW-packages: Unable to build shared libraries with GTK and gcc

Description / Steps to reproduce the issue

It seems https://github.com/msys2/MINGW-packages/issues/16362 broke building Geany (https://github.com/geany/geany/actions/runs/4713827400/jobs/8359771474#step:9:13085).

We are building relatively straight forward using MINGW64, mingw-w64-x86_64-gcc and Autotools. Since the fix in https://github.com/msys2/MINGW-packages/commit/3a61ad53cf8b9baf9f677254dfce5146042b3ad5, for our builds no shared libraries are created anymore, just the ar archives.

In the logs there is a warning about libuuid which seems related to the mentioned fix.

I’m really bad at linking and especially linker flags though the fix seems reasonable to me, still in breaks the build in our setup.

Do you have any ideas what could be wrong? Once I revert the to the “-Wl,-luuid” variant the build is fine. Are we doing anything wrong?

This can be reproduced in the CI builds (cross compiled in a Docker container) as well as on a native Windows system.

The linker messages (note the first block appears also on successful builds, the two blocks below only appear when libuuid is not found):

/bin/bash ../libtool --silent  --tag=CXX   --mode=link /usr/bin/x86_64-w64-mingw32-g++ -std=gnu++17  -g -O2 -version-info 0:0:0 -Wl,-luuid -mwindows -mms-bitfields -no-undefined -static-libgcc  -o libgeany.la -rpath /bu
ild/geany-release/lib libgeany_la-about.lo libgeany_la-build.lo libgeany_la-callbacks.lo libgeany_la-dialogs.lo libgeany_la-document.lo libgeany_la-editor.lo libgeany_la-encodings.lo libgeany_la-filetypes.lo libgeany_la
-geanyentryaction.lo libgeany_la-geanymenubuttonaction.lo libgeany_la-geanyobject.lo libgeany_la-geanywraplabel.lo libgeany_la-highlighting.lo libgeany_la-keybindings.lo libgeany_la-keyfile.lo libgeany_la-log.lo libgean
y_la-libmain.lo libgeany_la-msgwindow.lo libgeany_la-navqueue.lo libgeany_la-notebook.lo libgeany_la-plugins.lo libgeany_la-pluginutils.lo libgeany_la-prefs.lo libgeany_la-printing.lo libgeany_la-project.lo libgeany_la-
sciwrappers.lo libgeany_la-search.lo libgeany_la-socket.lo libgeany_la-spawn.lo libgeany_la-stash.lo libgeany_la-symbols.lo libgeany_la-templates.lo libgeany_la-toolbar.lo libgeany_la-tools.lo libgeany_la-sidebar.lo lib
geany_la-ui_utils.lo libgeany_la-utils.lo   libgeany_la-win32.lo  ../scintilla/liblexilla.la ../scintilla/libscintilla.la ./tagmanager/libtagmanager.la -L/windows/mingw64/lib -lgtk-3 -lgdk-3 -lz -lgdi32 -limm32 -lshell3
2 -lole32 -luuid -lwinmm -ldwmapi -lsetupapi -lcfgmgr32 -lhid -lwinspool -lcomctl32 -lcomdlg32 -lpangowin32-1.0 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobj
ect-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lintl  -lintl /windows/mingw64/lib/libiconv.dll.a -L/windows/mingw64/lib -lole32 -lwsock32 -lcomdlg32 -liconv

*** Warning: Trying to link with static lib archive /windows/mingw64/lib/libiconv.dll.a.
*** 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 the file extensions .a of this argument makes me believe
*** that it is just a static archive that I should not use here.

*** Warning: linker path does not have real file for library -luuid.
*** 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 libuuid and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/x86_64-w64-mingw32/lib/libuuid.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.

Expected behavior

Shared libraries are created

Actual behavior

Shared libraries are not created

Verification

I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

cross-compile

MINGW environments affected

MINGW64
MINGW32
UCRT64
CLANG64
CLANG32
CLANGARM64

Are you willing to submit a PR?

No response

About this issue

Original URL
State: closed
Created a year ago
Comments: 15 (12 by maintainers)

Most upvoted comments

Switching to Meson could work but something seems still wrong with the linker or libuuid.

The only thing is wrong here is the autotools. The libuuid.a is an archive library and exporting some GUIDs. It can be used like other libraries -luuid.

Also, in the origin message, the /windows/mingw64/lib/libiconv.dll.a import library shows same message. That full path comes from various m4 files. If I replace that with -liconv that error is gone. autotools is doing something really weird that situation.

The above export lt_cv_deplibs_check_method='pass_all' workaround is used in many cases here for various autotools quirks.

Since the fix in https://github.com/msys2/MINGW-packages/commit/3a61ad53cf8b9baf9f677254dfce5146042b3ad5, for our builds no shared libraries are created anymore, just the ar archives.

That commit fixes issues in some golang projects. The linked issue with that commit can provide more info.

Biswa96 on Apr 19, 2023

ok if that line in config.site does not work then something is seriously mucked up. i did notice that the arch specific config.site files have been removed leaving only the one in C:\Msys64\etc not sure if a mingw build will pick up anything from that one so maybe just add export lt_cv_deplibs_check_method=‘pass_all’ to the build section in PKGBUILD before the configuring this should do the same as adding it to config.site if it still fails then well…

example ->

build() {
  mkdir -p "build-${MINGW_CHOST}"
  cd "build-${MINGW_CHOST}"

  # libiberty
  export LDFLAGS+=" -L${MINGW_PREFIX}/lib/binutils"

  # config.h
  export PLUGIN_CFLAGS+=" -I$(pwd)"

  # tell libtool to ignore file magic
  export lt_cv_deplibs_check_method='pass_all'

  ../${_realname}-${pkgver}/configure \
    --host=${MINGW_CHOST} \
    --target=${MINGW_CHOST} \
    --build=${MINGW_CHOST} \
    --prefix=${MINGW_PREFIX} \
    --enable-gtk3 \
    --disable-pdf-docs \
    --disable-api-docs

  make
}

revelator on Apr 19, 2023