[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ozkan Sezer
Subject: 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@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).

# 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
   --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'

> Hopefully we can get to the bottom of this.

Thanks.  Ask me any more info you need.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]