[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#52253: mingw cross-compilation issue - possibly as of commit ac40b5f
bug#52253: mingw cross-compilation issue - possibly as of commit ac40b5f37a
Fri, 3 Dec 2021 10:02:38 +0200
On 12/3/21, Alex Ameen <email@example.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.
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
$ 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).
# Names of this library.
# The name of the static archive.
# Linker flags that can not go in dependency_libs.
# Libraries that this one depends upon.
# Names of additional weak libraries provided by this library
# Version information for libSDL2main.
# Is this an already installed library?
# Should we warn about portability when linking against -modules?
# Files to dlopen/dlpreopen
# Directory that this library needs to be installed in:
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
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
> Hopefully we can get to the bottom of this.
Thanks. Ask me any more info you need.