Wanted to try out SDL 1.3 and see if I could get it to build. Downloaded
the tarball from http://www.libsdl.org/hg.php Am using MinGW 4.5.0 along
with msys.
It ran okay when I tried make, but make install failed. If I clean out the
build subdirectory, it works again. Seems some of the .d files (such as
SDL_video.d) in the build subdirectory are created pointing to gl.h at
C:/mingw/msys/include/GL/gl.h Using /mingw/msys/include/GL/gl.h or
/C/mingw/msys/include/GL/gl.h works fine in my installation of msys, but
not C:/mingw/msys/include/GL/gl.h I don’t use the GNU autotools much
myself (other than when building other people’s projects), so I’m not quite
sure how to fix it. As a work-around, you can delete the build directory
before running make consecutive times.
It ran okay when I tried make, but make install failed.
Alberto Luaces wrote:
I assume it is a file copying problem, then. You can change the
destination directory with configure --prefix=<root_dir>.
Guess I should have been clearer. It’s not a file copying problem. It’s a
make dependency issue. If you run make twice in a row (without the
install), it fails as well. Running make creates several .d files in the
build directory. One of the header files (.h) files the .d files reference
has an incorrect directory path.
It ran okay when I tried make, but make install failed.
Alberto Luaces <@Alberto_Luaces_Ferna> wrote:
I assume it is a file copying problem, then. You can change the
destination directory with configure --prefix=<root_dir>.
Guess I should have been clearer. It’s not a file copying problem. It’s a
make dependency issue. If you run make twice in a row (without the
install), it fails as well. Running make creates several .d files in the
build directory. One of the header files (.h) files the .d files reference
has an incorrect directory path.
But… what is exactly the error? I can run `make && make && make…'
without problems with today’s mercurial version. Note that I’m not using
msys but cross-compiling.
Could it be that the .d file issue is a red herring? Certainly those
should not be worried about, since they are automatically generated, but
include paths might have something to do with it.–
Alberto
But… what is exactly the error? I can run `make && make && make…'
without problems with today’s mercurial version. Note that I’m not using
msys but cross-compiling.
This is the output when I run make including the actual error message:
$ make
/bin/sh build-scripts/updaterev.sh
make: *** No rule to make target C:/mingw/msys/include/GL/gl.h', needed bybuild/SDL_render_gl.lo’. Stop.
I don’t think you’ll ever find this error if you’re using a cross-compiler,
because the tools won’t generate information that your gl.h file is located
on the C: drive in Linux.
The gl.h file is there and you can see it in msys if you do:
ls /mingw/msys/include/GL/gl.h
ls /C/mingw/msys/include/GL/gl.h
but the way it’s written, msys returns:
ls: C:/mingw/msys/include/GL/gl.h: No such file or directory
Alberto Luaces wrote:
Could it be that the .d file issue is a red herring? Certainly those
should not be worried about, since they are automatically generated, but
include paths might have something to do with it.
The .d files are being automatically generated improperly on MinGW on
Windows. They may be fine when cross-compiling on Linux, but they do not
work properly on Windows using msys because of the way the drive letters
are handled by msys. Msys typically needs /C/ not C:/
Alberto Luaces <aluaces at udc.es (aluaces at udc.es)> wrote:
$ make
/bin/sh build-scripts/updaterev.sh
make: *** No rule to make target C:/mingw/msys/include/GL/gl.h', needed bybuild/SDL_render_gl.lo’.? Stop.
This is probably a stupid question, but what is your configure line?
is it something like:
configure --prefix=/mingw
But… what is exactly the error? I can run `make && make && make…'
without problems with today’s mercurial version. Note that I’m not using
msys but cross-compiling.
This is the output when I run make including the actual error message:
$ make
/bin/sh build-scripts/updaterev.sh
make: *** No rule to make target C:/mingw/msys/include/GL/gl.h', needed bybuild/SDL_render_gl.lo’. Stop.
Thanks for the error message.
I don’t think you’ll ever find this error if you’re using a
cross-compiler, because the tools won’t generate information that your
gl.h file is located on the C: drive in Linux.
The gl.h file is there and you can see it in msys if you do:
ls /mingw/msys/include/GL/gl.h
ls /C/mingw/msys/include/GL/gl.h
but the way it’s written, msys returns:
ls: C:/mingw/msys/include/GL/gl.h: No such file or directory
I have installed mingw on Windows. My msys doesn’t have any problems
with paths with unit drives in them (as C:). Maybe it’s an issue in your
configuration. I did:
Get mingw-get-inst-20111118.exe installer from Mingw’s Sourceforge
download page.
Run the installer and select all options (except ObjC and gfortran,
maybe).
Run that recently installed msys and clone the repository with
Could it be that the .d file issue is a red herring? Certainly those
should not be worried about, since they are automatically generated, but
include paths might have something to do with it.
The .d files are being automatically generated improperly on MinGW on
Windows. They may be fine when cross-compiling on Linux, but they do not
work properly on Windows using msys because of the way the drive letters
are handled by msys. Msys typically needs /C/ not C:/
I though it handled both seamlessly. At least mine does. I recommend you
to start over and follow my instructions, it takes roughly fifteen minutes
and you’ll save a lot of trouble.–
Alberto
Autogen.sh was not needed on windows with mingw, and only caused
complications when I did it on my windows build. In my build steps I
do run it on every other platform though.On Fri, Dec 2, 2011 at 3:39 AM, Alberto Luaces wrote:
LM writes:
Alberto Luaces wrote:
But… what is exactly the error? I can run `make && make && make…'
without problems with today’s mercurial version. Note that I’m not using
msys but cross-compiling.
This is the output when I run make including the actual error message:
$ make
/bin/sh build-scripts/updaterev.sh
make: *** No rule to make target C:/mingw/msys/include/GL/gl.h', needed bybuild/SDL_render_gl.lo’. ?Stop.
Thanks for the error message.
I don’t think you’ll ever find this error if you’re using a
cross-compiler, because the tools won’t generate information that your
gl.h file is located on the C: drive in Linux.
The gl.h file is there and you can see it in msys if you do:
ls /mingw/msys/include/GL/gl.h
ls /C/mingw/msys/include/GL/gl.h
but the way it’s written, msys returns:
ls: C:/mingw/msys/include/GL/gl.h: No such file or directory
I have installed mingw on Windows. My msys doesn’t have any problems
with paths with unit drives in them (as C:). Maybe it’s an issue in your
configuration. I did:
Get mingw-get-inst-20111118.exe installer from Mingw’s Sourceforge
download page.
Run the installer and select all options (except ObjC and gfortran,
maybe).
Run that recently installed msys and clone the repository with
Could it be that the .d file issue is a red herring? Certainly those
should not be worried about, since they are automatically generated, but
include paths might have something to do with it.
The .d files are being automatically generated improperly on MinGW on
Windows. ?They may be fine when cross-compiling on Linux, but they do not
work properly on Windows using msys because of the way the drive letters
are handled by msys. ?Msys typically needs /C/ not C:/
I though it handled both seamlessly. At least mine does. I recommend you
to start over and follow my instructions, it takes roughly fifteen minutes
and you’ll save a lot of trouble.
Autogen.sh was not needed on windows with mingw, and only caused
complications when I did it on my windows build. In my build steps I
do run it on every other platform though.
No problem here with latest versions, as reported. Anyway, I did it
because I’m used to projects were configure is not versioned, so I
didn’t even notice that it was already there. I even recall some other
time when I didn’t notice the autogen.sh file and executed autoreconf
-vi directly.
I cloned again, rebuilt and ran this time straight from the
configure. No difference from previous build.–
Alberto
I recommend you to start over and follow my instructions, it takes
roughly fifteen minutes
and you’ll save a lot of trouble.
Following your instructions, unfortunately, I’ll never get this working.
Get mingw-get-inst-20111118.exe installer from Mingw’s Sourceforge
download page.
mingw-get doesn’t work behind our firewall. I’ve posted this issue to the
MinGW list quite a while ago and went through quite a lot of debugging on
it. The issue was never fixed for our case.
What directory did your OpenGL include files get installed to?
MBrening wrote:
This is probably a stupid question, but what is your configure line?
is it something like:
configure --prefix=/mingw
I ran it with ./configure
My .profile file has:
export PATH=$PATH:/usr/bin:/usr/local/bin:/mingw/bin:/perl/bin
export CFLAGS="-I/include -I/usr/include -I/usr/local/include"
export LDFLAGS="-L/mingw/lib -L/lib -L/usr/lib -L/usr/local/lib"
I use mingw, msys and SDL 1.3 everyday, and I’ve had no build problems, so
the issue is one of the following:
Your mingw is broken - some programs that get installed there may have
change the directory structure or something? (can you do a second mingw32
install and see if it works?)
You have a previous build of SDL that’s causing some sort of conflict?
(you can change the --prefix in ./configure to something different to avoid
conflicts)
Your SDL build got broken? (delete the repository you made in hg, and
grab another completely fresh copy)
When I build SDL 1.3, I do this (from msys, of course):
$ ./configure
$ mingw32-make
$ mingw32-make install
Some mingw builds aren’t very happy with make.exe but mingw32-make.exe
works just fine. Give that a try
There are no directory issues, as Alberto said, and there shouldn’t ever be
because msys takes care of some of the directory matching issues.
If that doesn’t work, then I’m not sure what the issue is, since I can’t
reproduce the problem.
I hope that helps,
-AlexOn Fri, Dec 2, 2011 at 7:47 AM, LM wrote:
Re: [SDL] SDL 1.3, MinGW and msys
Alberto Luaces wrote:
I recommend you to start over and follow my instructions, it takes
roughly fifteen minutes
and you’ll save a lot of trouble.
Following your instructions, unfortunately, I’ll never get this working.
Get mingw-get-inst-20111118.exe installer from Mingw’s Sourceforge
download page.
mingw-get doesn’t work behind our firewall. I’ve posted this issue to the
MinGW list quite a while ago and went through quite a lot of debugging on
it. The issue was never fixed for our case.
What directory did your OpenGL include files get installed to?
MBrening wrote:
This is probably a stupid question, but what is your configure line?
is it something like:
configure --prefix=/mingw
I ran it with ./configure
My .profile file has:
export PATH=$PATH:/usr/bin:/usr/local/bin:/mingw/bin:/perl/bin
export CFLAGS="-I/include -I/usr/include -I/usr/local/include"
export LDFLAGS="-L/mingw/lib -L/lib -L/usr/lib -L/usr/local/lib"
