bug#52253: mingw cross-compilation issue - possibly as of commit ac40b5f37a

On 12/3/21, Alex Ameen <[email protected]> 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.