Could not run SDL test program

[asbjornu]

As mentioned in #35, I'm trying to set up a continuous integration build of Schism Tracker on AppVeyor and I'm struggling with getting the thing to compile. The step that now fails is:

./configure --prefix=/mingw32/

As can be seen in the result from this build on AppVeyor, configure fails to link against SDL with the following error message:

checking for SDL - version >= 1.2.10... no
*** Could not run SDL test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occured. This usually means SDL was incorrectly installed
*** or that you have moved SDL since it was installed. In the latter case, you
*** may want to edit the sdl-config script: /mingw32/bin/sdl-config
configure: error: *** SDL version >= 1.2.10 not found.

I have tried installing 32-bit msys2, but since I can't figure out a way to execute msys2-i686-latest.exe "headless" or "silent" (see this Qt Installer Framework issue for details) I'm unable to progress the 32-bit build any further.

The 64-bit build, however, fails with the same exception so I'm now pretty confident that the problem isn't bitness, but something else. Have any of the @schismtracker developers seen this problem before and if so can you please provide some sorely needed assistance?

Thanks! :smile:

[asbjornu]

Here's the contents of /mingw64/bin/sdl-config, if that's meaningful to anyone of you:

#!/bin/sh
prefix=/mingw64
exec_prefix=${prefix}
exec_prefix_set=no
libdir=${exec_prefix}/lib
#usage="\
#Usage: sdl-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs]"
usage="\
Usage: sdl-config [--prefix[=DIR]] [--exec-prefix[=DIR]] [--version] [--cflags] [--libs] [--static-libs]"
if test $# -eq 0; then
      echo "${usage}" 1>&2
      exit 1
fi
while test $# -gt 0; do
  case "$1" in
  -*=*) optarg=`echo "$1" | LC_ALL="C" sed 's/[-_a-zA-Z0-9]*=//'` ;;
  *) optarg= ;;
  esac
  case $1 in
    --prefix=*)
      prefix=$optarg
      if test $exec_prefix_set = no ; then
        exec_prefix=$optarg
      fi
      ;;
    --prefix)
      echo $prefix
      ;;
    --exec-prefix=*)
      exec_prefix=$optarg
      exec_prefix_set=yes
      ;;
    --exec-prefix)
      echo $exec_prefix
      ;;
    --version)
      echo 1.2.15
      ;;
    --cflags)
      echo -I${prefix}/include/SDL -D_GNU_SOURCE=1 -Dmain=SDL_main
      ;;
    --libs)
      echo -L${exec_prefix}/lib  -lmingw32 -lSDLmain -lSDL  -mwindows
      ;;
    --static-libs)
#    --libs|--static-libs)
      echo -L${exec_prefix}/lib  -lmingw32 -lSDLmain -lSDL  -mwindows  -liconv -lm -luser32 -lgdi32 -lwinmm -ldxguid
      ;;
    *)
      echo "${usage}" 1>&2
      exit 1
      ;;
  esac
  shift
done

The only thing I can spot, are the -lmingw32, -luser32 and --lgdi32 arguments. Not sure if they should have been -lmingw64, -luser64 and --lgdi64 or not.

[ghost]

[n.b. I know nothing about Appveyor, what it does, or how to use it, so bear with me here]

This might be a deeply patronising question, but do you have SDL (the dev stuff, not just the dll?) installed? [edit: I guess you do since you have sdl-config] IIRC there is no 64 bit package of SDL dev stuff on the SDL website so I don't know if you will have it unless you built it yourself. Can you ssh into Appveyor and run sdl-config --versionor is that not how Appveyor works?

I'm free on Saturday and haven't been much use around here lately so I'll take a look, you might be on your own here though as I seriously don't have a clue what Appveyor is!

Thanks again for trying to get these things going! :)

[ghost]

nvm, it looks like you are following the new Windows build instructions which I haven't had a chance to look at yet!

[asbjornu]

@mb14 Thanks for asking patronising questions! You might actually be right, but I'm not sure. I'm trying the 32-bit route in appveyor/ci#994 and hope that it will be successful in the end. I'll report status back here as I progress.

And yes, I'm attempting the newest Windows build instructions, as they seemed easier to get going on AppVeyor than the old one.

Now, a TL;DR of AppVeyor: It's a continuous integration server, that basically does this:

1. Fetches source code from a configured repository every time someone pushes code to it.
2. Executes a build script within or referenced from an appveyor.yml file at the root of the repository.
3. If there are any, tests that verify the integrity of the code can be executed.
4. Based on the result of the build, releases can be created from artifacts produced during the build.

While AppVeyor is a Windows build environment, Travis CI is a Linux and OS X build environment. A Travis CI build was added in #29.

My hope is that when AppVeyor successfully builds the Schism Tracker source, we can automate the release-process of binaries for all platforms, so it's less work to release new versions for the @schismtracker developers and easier to get fresh versions as a user of Schism Tracker.

The only possible hurdle for this automated release process is that we need to discuss at which points releases should be created, based on what kind of development model you guys use in this repository.

[jangler]

(This is cool and thanks for working on it.)

Our general methodology has been that the master branch is only for code that's been tested and working. Anything nontrivial is developed on a branch and reviewed by someone else from the team (similar to a PR) before it's merged into master.

That being said, it's nice to have a bit of documentation for each "official" release besides the commit history (which may or may not be of particular use to the end user), so I'd say we don't want to have each revision automatically be a release.

[ghost]

That's awesome @asbjornu, sounds like a great idea!

I like the LGPT (and I guess Debian) system of "ghetto" and "stable" releases, ultimately giving people access to binaries of the latest code is just free UAT and we can always provide something a bit older that we know is working alongside that.

[asbjornu]

@jangler Sounds like you're using something very close to the GitHubFlow model, then. However, if you can't guarantee that all commits on the master branch are releaseable and if I'm correct by saying that each release should be accompanied by some release notes, it sounds like GitHub Releases might be the perfect match.

While I haven't tried it yet, I think GitHub Changelog Generator looks like a great tool to help semi-automate the work of writing release notes and if we can get Travis or AppVeyor to create GitHub releases for us and upload their compiled binaries to it, it's not much work left to do but to copy and paste the generated release notes into the created release on GitHub.

@mb14 A more Git-ish way of having "ghetto" and "stable" releases would be to have two different branches; develop and master. It's a rather simple expansion on the current model, but instead of merging directly to master, each feature branch is merged into develop which can have its own build and release cycle and every time you decide develop is well enough tested to be released, it's merged into master and tagged with a version number.

[jangler]

Yeah, it's my normal protocol to use GitHub releases for projects I work on. I made a GitHub release for the first Schism release since switching to GitHub.

[asbjornu]

I've tried just about everything I can think of and I'm still stuck with the same error message about SDL failing to link. Ideas?

[asbjornu]

@jangler, @mb14: Digging a bit more into this, I might have found the underlying reason why the SDL test fails:

configure:5172: checking for sdl-config
configure:5190: found /mingw32/bin/sdl-config
configure:5203: result: /mingw32/bin/sdl-config
configure:5213: checking for SDL - version >= 1.2.10
configure:5300: gcc -o conftest.exe -g -O2 -I/mingw32/include/SDL -D_GNU_SOURCE=1 -Dmain=SDL_main   conftest.c  -L/mingw32/lib -lmingw32 -lSDLmain -lSDL -mwindows >&5
/usr/lib/gcc/i686-pc-msys/5.3.0/../../../../i686-pc-msys/bin/ld: cannot find -lmingw32
collect2: error: ld returned 1 exit status

Does that say anything to anyone? How can I affect what autoreconf does when creating this erroneous part of the configure file, why is it an error and what should it do instead?

[asbjornu]

After endless amount of searching on the web, I found this comment mentioning that mingw shouldn't be linked. That might make sense, but I have no idea how to tell autoreconf or configure to not link a library. Ideas?

[asbjornu]

If someone has an infinite amount of time on their hands, here's the contents of various files generated during the build that might contain useful information to those who are more familiar with the GCC toolchain than I:

• config.log
• configure.ac
• configure
• sdl-config

[jangler]

Hm, sorry for the radio silence, but I've never built Schism on Windows and just don't know enough about autotools to diagnose or fix this problem.

[asbjornu]

@jangler I see. Perhaps @JosepMaJAZ as the submitter of #32 has ideas on how to fix this one? He was the one who put me on the MinGW track, anyway. 😄

[JosepMaJAZ]

@asbjornu : It seems that you are compiling the program from an incorrect shell.

If I open a shell on windows and write: "uname -a" I get: MSYS_NT-10.0 Win7 2.5.2(0.297/5/3) 2016-07-15 08:31 x86_64 Msys If I open the mingw32 shell and write: "uname -a" I get: MINGW32_NT-10.0 Win7 2.5.2(0.297/5/3) 2016-07-15 08:31 x86_64 Msys

My config.log, has this at the beginning:

## --------- ##
## Platform. ##
## --------- ##

hostname = Win7
uname -m = x86_64
uname -r = 2.5.2(0.297/5/3)
uname -s = MINGW32_NT-10.0
uname -v = 2016-07-15 08:31

while yours has this:

## --------- ##
## Platform. ##
## --------- ##
hostname = APPVYR-WIN
uname -m = i686
uname -r = 2.5.2(0.297/5/3)
uname -s = MSYS_NT-6.3-WOW
uname -v = 2016-07-15 09:04

Also, it seems that machine has gcc 5.3, while I am compiling with 6.1

gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.

As I wrote in the instructions, the shell needs to be opened with "msys2_shell.cmd -migw32", but since you are on a headless window , that will not work because it opens a new shell.

I found the following comment on this discussion:

Practically speaking, you can transform an msys2 shell into a mingw-w64 x86_64 shell for the execution of some-command as follows:
MSYSTEM=**MINGW64** . /etc/profile && some-command
If you look at /etc/profile, you'll see the env. variables that define the 'shell'. They are:

I tried it and set|grep PATH showed that it changed the PATH variables accordingly ( MINGW64 and MINGW32 ). So you probably need to run MSYSTEM=MINGW32 . /etc/profile && ../configure ( "../" if you do it from the buildx86 folder as suggested, or "./" if you do it from the root of the sources dir)

Edit: BTW, your files are correct, but there is a strange error in the "configure" file. The line 4755 in your file should be:

if (sscanf(tmp_version, "%d.%d.%d", &major, &minor, &micro) != 3) {

For some reason, there are some weird characters in place of &micro.

[asbjornu]

@JosepMaJAZ Thanks! After doing MSYSTEM=MINGW32 . /etc/profile && ./configure, it works! :smiley: Thank you so much for the help! I don't think I could have figured this out on my own.

Now, we need to figure out how to get the compiled binaries out of Travis and AppVeyor, so we can distribute them more easily.

Also, it seems that machine has gcc 5.3, while I am compiling with 6.1

I can upgrade the installed gcc, but as it now works with 5.3 are there other reasons to upgrade?

your files are correct, but there is a strange error in the "configure" file.

Yea, I can see that there's a micro sign in there (µ):

if (sscanf(tmp_version, "%d.%d.%d", &major, &minor, µ) != 3) {

That's weird! Why would &micro be replaced with µ? Not that it matters much as stuff now works, but still; that's bizarre.