GNU bug report logs - #52253
mingw cross-compilation issue - possibly as of commit ac40b5f37a

From: Ozkan Sezer <sezeroz <at> gmail.com>
To: bug-libtool <at> gnu.org
Subject: mingw cross-compilation issue - possibly as of commit ac40b5f37a
Date: Fri, 3 Dec 2021 03:39:47 +0300

Linking executables with a linux-to-windows cross-compilation setup
has issues:

$ export PATH=/opt/cross_win64/bin:$PATH
$ export PKG_CONFIG_PATH=/home/sz/x86_64-w64-mingw32/lib/pkgconfig

$ pkg-config --cflags sdl2
-Dmain=SDL_main -I/home/sz/x86_64-w64-mingw32/include/SDL2

$ pkg-config --libs sdl2
-mwindows -L/home/sz/x86_64-w64-mingw32/lib -lmingw32 -lSDL2main -lSDL2
$ cd SDL_net
$ ./configure --host=x86_64-w64-mingw32 --prefix=/home/sz/x86_64-w64-mingw32
[...]
$ make
[...]
libtool: link: ( cd ".libs" && rm -f "libSDL2_net.la" && ln -s
"../libSDL2_net.la" "libSDL2_net.la" )
/bin/sh ./libtool  --tag=CC   --mode=link x86_64-w64-mingw32-gcc  -g
-O2 -Dmain=SDL_main -I/home/sz/x86_64-w64-mingw32/include/SDL2     -o
showinterfaces.exe showinterfaces.o libSDL2_net.la -mwindows
-L/home/sz/x86_64-w64-mingw32/lib -lmingw32 -lSDL2main -lSDL2
libtool: link: x86_64-w64-mingw32-gcc -g -O2 -Dmain=SDL_main
-I/home/sz/x86_64-w64-mingw32/include/SDL2 -o .libs/showinterfaces.exe
showinterfaces.o -mwindows  ./.libs/libSDL2_net.dll.a
-L/home/sz/x86_64-w64-mingw32/lib -lws2_32 -liphlpapi -lmingw32
-lSDL2main -lSDL2 -L/home/sz/x86_64-w64-mingw32/lib
libtool:   error: Could not determine the host path corresponding to
libtool:   error:   '/home/sz/SDL_net/.libs'
libtool:   error: Continuing, but uninstalled executables may not work.
libtool:   error: Could not determine the host path corresponding to
libtool:   error:
'/home/sz/x86_64-w64-mingw32/lib:/home/sz/x86_64-w64-mingw32/bin:/home/sz/SDL_net/.libs'
libtool:   error: Continuing, but uninstalled executables may not work.
/opt/cross_win64/lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o):
In function `main':
/home/sz/Downloads/W64_4.5_189152-src/build-crt/../mingw-w64-crt/crt/crt0_c.c:18:
undefined reference to `WinMain'
collect2: ld returned 1 exit status
x86_64-w64-mingw32-strip: './showinterfaces.exe': No such file

The link library order, i.e. -lmingw32 -lSDL2main -lSDL2 is important here.
I am not exactly sure what libtool does here, because manual linking without
libtool getting in the way actually works, e.g.:
$ x86_64-w64-mingw32-gcc -g -O2 -Dmain=SDL_main
-I/home/sz/x86_64-w64-mingw32/include/SDL2 -o .libs/showinterfaces.exe
showinterfaces.o -mwindows  ./.libs/libSDL2_net.dll.a
-L/home/sz/x86_64-w64-mingw32/lib -lws2_32 -liphlpapi -lmingw32
-lSDL2main -lSDL2

The issue shows itself with libtool-2.4.2 and 2.4.6 -- libtool-2.2.6 does
not have this issue.

The problem likely started with this commit by Charles Wilson:
http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commit;h=ac40b5f37ae68a7b4a254e43364e2d297f563310

Is there a way of resolving this, please?

--
O.S.

From: Ozkan Sezer <sezeroz <at> gmail.com>
To: Alex Ameen <alex.ameen.tx <at> gmail.com>
Cc: 52253 <at> debbugs.gnu.org
Subject: Re: bug#52253: mingw cross-compilation issue - possibly as of commit
 ac40b5f37a
Date: Fri, 3 Dec 2021 10:02:38 +0200

On 12/3/21, Alex Ameen <alex.ameen.tx <at> gmail.com> wrote:
> Thank you for reporting this. I believe I've spotted the issue, but I
> want to reproduce it and experiment before I jump to any conclusions. It
> might be a change in `.la' files from 2.4.2 and 2.4.6 for installed vs
> uninstalled libs.
>
> Another possibility is that is easy to eliminate would be building with
> `--preserve-dup-deps' and see if that has any effect. `libtool' aims to
> prevent libraries from being linked multiple times so if things are
> listed as dependencies in multiple `.la' files the ordering that
> `libtool' lands on can be unexpected ( in this case possibly incorrect ).
>
> Is this the SZ Compression library? I pulled up a mirror and it looks
> like it might be the same project.

Nope - it is SDL_net, SDL_image, SDL_ttf and SDL_rtf. Easiest one to
work with is SDL_net because it has no dependencies other than SDL
itself. All those projects have in common is they build an SDL_xxx
library along with test programs, and they all utilize libtool _and_
automake. SDL_net with the failure (after it just upgraded to a new
libtool) is here: https://github.com/libsdl-org/SDL_net

>  Similarly I'm guessing SDL2 is the
> 2.0.8 version. I can try to reproduce on my Linux box. If you have any
> relevant flags from SDL2 build let me know.

The version I used is 2.0.18, but doubt the version will matter.
Download http://libsdl.org/release/SDL2-devel-2.0.18-mingw.tar.gz
extract it, and put the 'x86_64-w64-mingw32' directory from it to
a place of your choosing, and edit x86_64-w64-mingw32/bin/sdl2-config
and x86_64-w64-mingw32/lib/pkgconfig/sdl2.pc files so that their
'prefix' reflect the path of your setup.

> If you could dump the `.la' contents for all of the libraries involved
> that would help.

Do note that the issue is reproducible for me with the *.la files
deleted: never bothered editing them, just deleted. However, here
it is:

$ cat libSDL2main.la
# libSDL2main.la - a libtool library file
# Generated by libtool (GNU libtool) 2.4.2
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names=''

# The name of the static archive.
old_library='libSDL2main.a'

# Linker flags that can not go in dependency_libs.
inherited_linker_flags=''

# Libraries that this one depends upon.
dependency_libs=''

# Names of additional weak libraries provided by this library
weak_library_names=''

# Version information for libSDL2main.
current=0
age=0
revision=0

# Is this an already installed library?
installed=yes

# Should we warn about portability when linking against -modules?
shouldnotlink=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/Users/valve/release/SDL/SDL2-2.0.18/x86_64-w64-mingw32/lib'

libSDL2.la is similar.

>  The error message I'm seeing in your run suggests that
> you might be linking with an uninstalled form of the SDL2 libs. Could
> you provide info about the process you followed from that SDL2 build?

I didn't build SDL2 myself, just used the precompiled package I linked
above. I just did try building SDL2 myself with
   --host=x86_64-w64-mingw32 --prefix=xxxx
and then configuring + building SDL_net against it, nothing is changed
with or without the installed *.la files present.

> Whether you ran `make all;' vs `make install;' is really what I'm
> interested in here, as well as the output of `./config.status --config;'
> from that build area.

If you are referring to the SDL_net failed builds, here it is:
$ ./config.status --config
'--host=x86_64-w64-mingw32' '--prefix=/home/sz/x86_64-w64-mingw32'
'host_alias=x86_64-w64-mingw32'
'PKG_CONFIG_PATH=/home/sz/x86_64-w64-mingw32/lib/pkgconfig'

> Hopefully we can get to the bottom of this.

Thanks.  Ask me any more info you need.

--
O.S.

From: Ozkan Sezer <sezeroz <at> gmail.com>
To: 52253 <at> debbugs.gnu.org
Cc: Alex Ameen <alex.ameen.tx <at> gmail.com>
Subject: Re: bug#52253: mingw cross-compilation issue - possibly as of commit
 ac40b5f37a
Date: Fri, 3 Dec 2021 18:53:22 +0300

For the time being, we went back to libtool 2.2.6 in the affected SDL_
projects. Therefore, if you want to test things with SDL_net, you should
go back to commit 798a5a9e in its git history, i.e.:
https://github.com/libsdl-org/SDL_net/tree/798a5a9e279224d516dc74f151a917789642a880

From: Ozkan Sezer <sezeroz <at> gmail.com>
To: 52253 <at> debbugs.gnu.org
Subject: Re: bug#52253: mingw cross-compilation issue - possibly as of commit
 ac40b5f37a
Date: Wed, 16 Mar 2022 03:38:35 +0300

Is there any progress on this issue? Is there a way to contact Chris Wilson
about it?

From: Ozkan Sezer <sezeroz <at> gmail.com>
To: Alex Ameen <alex.ameen.tx <at> gmail.com>
Cc: 52253 <at> debbugs.gnu.org
Subject: Re: bug#52253: mingw cross-compilation issue - possibly as of commit
 ac40b5f37a
Date: Wed, 16 Mar 2022 07:34:11 +0300

On 3/16/22, Alex Ameen <alex.ameen.tx <at> gmail.com> wrote:
> I have a branch where I've been reproducing the issue, but I've been
> focusing on preparing the new release - largely testing different platforms
> which can be time consuming.
>
> Luckily I got the last check boxes from GNU for processing uploads so I
> plan to push that this week and then dive back into the bug list.

I can test patches if you make them available.

From: Alex Ameen <alex.ameen.tx <at> gmail.com>
To: Ozkan Sezer <sezeroz <at> gmail.com>
Cc: 52253 <at> debbugs.gnu.org
Subject: Re: bug#52253: mingw cross-compilation issue - possibly as of commit
 ac40b5f37a
Date: Tue, 15 Mar 2022 22:08:21 -0500

[Message part 1 (text/plain, inline)]
I have a branch where I've been reproducing the issue, but I've been
focusing on preparing the new release - largely testing different platforms
which can be time consuming.

Luckily I got the last check boxes from GNU for processing uploads so I
plan to push that this week and then dive back into the bug list.

On Tue, Mar 15, 2022, 7:43 PM Ozkan Sezer <sezeroz <at> gmail.com> wrote:

> Is there any progress on this issue? Is there a way to contact Chris Wilson
> about it?
>
>
>
> _______________________________________________
> Bug-libtool mailing list
> Bug-libtool <at> gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-libtool
>

[Message part 2 (text/html, inline)]

GNU bug report logs - #52253 mingw cross-compilation issue - possibly as of commit ac40b5f37a

GNU bug report logs - #52253
mingw cross-compilation issue - possibly as of commit ac40b5f37a