Hello.
I’m having problems using sdl.m4 on my environment (MinGW + MSYS,
autoconf 2.59, automake 1.9.5).
This is my configure.ac:—
AC_INIT([just a test], 0.1)
AC_CONFIG_SRCDIR([test.c])
AC_CANONICAL_TARGET
AM_INIT_AUTOMAKE
AC_PROG_CC
SDL_VERSION=1.2.0
AM_PATH_SDL($SDL_VERSION, , AC_MSG_ERROR([SDL not found]))
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
I always get an error when running ./configure, complaining that SDL.dll
can’t be found (it’s in the path):
*** Could not run SDL test program, checking why…
*** The test program compiled, but did not run. This usually means
*** that the run-time linker is not finding SDL or finding the wrong
…
After a bit of investigation, I found the problem to be on sdl.m4, at
this line:
PATH="$prefix/bin:$prefix/usr/bin:$PATH"
But at this point, $prefix expands to “NONE”. Should I use some other
macro before AM_PATH_SDL to set $prefix to some value? Or should this
line on sdl.m4 be replace by something like
if test “X$prefix” != “XNONE”; then
PATH="$prefix/bin:$prefix/usr/bin:$PATH"
fi
?
Thanks in advance.
Daniel K. O.
After a bit of investigation, I found the problem to be on sdl.m4, at
this line:
PATH="$prefix/bin:$prefix/usr/bin:$PATH"
But at this point, $prefix expands to “NONE”. Should I use some other
macro before AM_PATH_SDL to set $prefix to some value? Or should this
line on sdl.m4 be replace by something like
if test “X$prefix” != “XNONE”; then
PATH="$prefix/bin:$prefix/usr/bin:$PATH"
fi
Once you fix this, does configure detect SDL?
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
When configuring on MinGW, assuming you configured SDL with
’–prefix=/mingw’ (and the DLL is in /mingw/bin), you’ve got to
configure all packages that use SDL with --prefix=/mingw.
If you don’t, you should get a standard ‘MessageBox’ complaining that
SDL.dll could not be found when configure tries to run the link test
program.
In short, even if SDL.dll is in the path, what matters is your configure
’–prefix’ 
JulienOn 29/04/2006 02:40, Daniel K. O. wrote:
I always get an error when running ./configure, complaining that SDL.dll
can’t be found (it’s in the path):
*** Could not run SDL test program, checking why…
*** The test program compiled, but did not run. This usually means
*** that the run-time linker is not finding SDL or finding the wrong
…
2006/4/29, Sam Lantinga :
But at this point, $prefix expands to “NONE”. Should I use some other
macro before AM_PATH_SDL to set $prefix to some value? Or should this
line on sdl.m4 be replace by something like
if test “X$prefix” != “XNONE”; then
PATH="$prefix/bin:$prefix/usr/bin:$PATH"
fi
Once you fix this, does configure detect SDL?
Yes. It also works if I run “./configure --prefix=”. The only problem
seems to be the $prefix variable. It also works if I simply comment
this line.
With a previous SDL version (I don’t remember which one) I never had
problems with it. I only noticed now that I upgraded to 1.2.9. (well,
I don’t think I did run aclocal on SDL projects under MSYS recently,
so I don’t know if this problem only happens with 1.2.9).
2006/4/29, Julien Lecomte :
When configuring on MinGW, assuming you configured SDL with
’–prefix=/mingw’ (and the DLL is in /mingw/bin), you’ve got to
configure all packages that use SDL with --prefix=/mingw.
If you don’t, you should get a standard ‘MessageBox’ complaining that
SDL.dll could not be found when configure tries to run the link test
program.
That doesn’t seem reasonable. That means that every single program
using SDL will have to go to the same directory where SDL is
installed.
The problem only happens because the PATH variable is messed up by
AM_PATH_SDL (prepending “NONE/bin:NONE/usr/bin”).—
Daniel K. O.
The problem only happens because the PATH variable is messed up by
AM_PATH_SDL (prepending “NONE/bin:NONE/usr/bin”).
I’m still curious how this would cause it to fail. Prepending those
to your path doesn’t actually change anything if those directories
don’t exist…
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Prepending ‘/bin’ to a MINGW environment can have the effect of making
the MINGW environment become a MSYS environment.
The MINGW compiler is usually/by default in /mingw/bin and thus the
MINGW default PATH is '/mingw/bin:/bin:…'
The MSYS tools are (by default) in /bin.
So if we prepend /bin to the current path, and the configure tries a
compile/link test with such a path, it will probably use the MSYS
compiler if the msys gcc has been installed (and thus will link against
msys dll and not MSVCRT.dll for example)
Daniel, I’ld like to know if you’ve got the MSYS gcc installed (it’s a
gcc version 2.95, not installed by default MSYS installation), cause
that would probably explain much.
JulienOn 30/04/2006 05:34, Sam Lantinga wrote:
The problem only happens because the PATH variable is messed up by
AM_PATH_SDL (prepending “NONE/bin:NONE/usr/bin”).
I’m still curious how this would cause it to fail. Prepending those
to your path doesn’t actually change anything if those directories
don’t exist…
Julien Lecomte escreveu:
Daniel, I’ld like to know if you’ve got the MSYS gcc installed (it’s a
gcc version 2.95, not installed by default MSYS installation), cause
that would probably explain much.
I don’t have any other compiler on my Win32 environment but MinGW’s GCC
(3.4.5).
The behavior is reproducible: if I try to run any program that depends
on a DLL that is not in the system directory (but on system’s path) with
this:
PATH=foo:bar:$PATH
(where “foo” can be anything, and “bar” is any non-existing path)
I always get the same error about the DLL not being found.
Maybe adding non-existing directories to the path doesn’t cause problems
on a native *nix… but unfortunately MSYS can’t handle it. I think it’s
reasonable to add 2 lines to the .m4 script to handle this.—
Daniel K. O.
After a bit of investigation, I found the problem to be on sdl.m4, at
this line:
PATH="$prefix/bin:$prefix/usr/bin:$PATH"
But at this point, $prefix expands to “NONE”. Should I use some other
macro before AM_PATH_SDL to set $prefix to some value? Or should this
line on sdl.m4 be replace by something like
if test “X$prefix” != “XNONE”; then
PATH="$prefix/bin:$prefix/usr/bin:$PATH"
fi
This is in CVS, thanks. I’m still mystified why this fixes it though.
Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment