I've been happily using sdl 0.8.0 for quite a while now, and finally
decided to upgrade to 1.1.3 and it’s just killing me. I updated gcc to
get the “cpu” and “arch” options to work, but now am stuck on the
joystick. I don’t have one, and my kernel (2.0.36) doesn’t have
joystick.h. I config’d with --disable-joystick and --disable-threads
(I haven’t even started trying to track that one down yet) and got sdl
to compile, but linking to the library fails:
/usr/local/lib/libSDL.so: undefined reference to SDL_JoystickUpdate' /usr/local/lib/libSDL.so: undefined reference toSDL_numjoysticks’
collect2: ld returned 1 exit status
so it seems that the library itself references these routines(?) even if
it’s disabled. So now I’m staring at the code for kernels 2.1.132 and
2.2.16 (which have joystick.h) and hoping that maybe there’s another
way. If anyone could offer me some clarity, at least to say that sdl
1.1.3 requires this kernel and that library and such, I’d appreciate it
very much.
I updated gcc to get the “cpu” and “arch” options to work
That was a bad idea. The original intention was to get a speedup from
special compiler optimizations, but it turned out not to help that much.
SDL 1.1.4 will not use these flags.
I config’d with --disable-joystick and --disable-threads
(I haven’t even started trying to track that one down yet) and got sdl
to compile, but linking to the library fails:
It sounds like a bug, I’ll check it out.
BTW, the problem with threads is fixed in CVS - SDL 1.1.3 didn’t work
by default on glibc-2.0 systems.
The good news is that everything you’re doing should work fine, and
I’ll have a CVS snapshot for you to check out later today.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I config’d with --disable-joystick and --disable-threads
(I haven’t even started trying to track that one down yet) and got sdl
to compile, but linking to the library fails:
It sounds like a bug, I’ll check it out.
BTW, the problem with threads is fixed in CVS - SDL 1.1.3 didn’t work
by default on glibc-2.0 systems.
Thanks for the assist, Sam. Buoyed by your helpfulness, I tried again and
discovered that my problem was with make, not the code. I did:
./configure; make
than said “Ooops, no joystick” and did:
./configure --disable-joystick; make
which did not recompile any of the earlier files from the first run, thus
the missing references. I don’t know enough about config/make to say if
this is an accepted behavior, but it seems shaky since the difference in
config flags does alter the compile flags.
At any rate, 1.1.4 from CVS, with a clean ./configure --disable-joystick
–disable-pthreads, works just great. I guess the lack of pthreads is
legit on a 2.0.36/glibc 2.0 system?
Thanks for the assist, Sam. Buoyed by your helpfulness, I tried again and
discovered that my problem was with make, not the code. I did:
./configure; make
than said “Ooops, no joystick” and did:
./configure --disable-joystick; make
which did not recompile any of the earlier files from the first run, thus
the missing references. I don’t know enough about config/make to say if
this is an accepted behavior, but it seems shaky since the difference in
config flags does alter the compile flags.
The thing with make is that it only checks the timestamp of source and
object files to determine if they need to be rebuilt. If the Makefile
changed (because you ran configure with different options) and that the
compile options are different, that is not enough to have the files
recompiled, because make only sees that you didn’t change the source
files.
A “make clean” should fix this up.–
“You can have my Unix system when you pry it from my cold, dead
fingers.”
– Cal Keegan
At any rate, 1.1.4 from CVS, with a clean ./configure --disable-joystick
–disable-pthreads, works just great. I guess the lack of pthreads is
legit on a 2.0.36/glibc 2.0 system?
Maybe, but not necessarily. Me knowingly clone(), used by the glibc threads
implementation, has been in the kernel since the 2.0 days.
There is nothing wrong with using old stable kernels (there is supposedly
quite a few 1.2.x around with uptimes of several years), but I would
advise you to upgrade to a 2.2 kernel if possible. At least file system
operations are faster (you can actually feel it).
For the record, I’m using SDL with libc5 and it works well, threads and all,
once I upgraded to a thread-safe Xlib.
At any rate, 1.1.4 from CVS, with a clean ./configure --disable-joystick
–disable-pthreads, works just great. I guess the lack of pthreads is
legit on a 2.0.36/glibc 2.0 system?
Actually, you shouldn’t need to disable pthreads with the CVS code.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Maybe, but not necessarily. Me knowingly clone(), used by the glibc threads
implementation, has been in the kernel since the 2.0 days.
There are threading issues in glibc 2.0 that are fixed only in glibc
2.1. I know that Mozilla requires 2.1 because of that, they are real
showstoppers.
advise you to upgrade to a 2.2 kernel if possible. At least file system
operations are faster (you can actually feel it).
Literally. I remember booting into my 2.0.x system in single-user mode,
fiddling the options, compiling a (late) 2.1.x kernel, rebooting,
fiddling some options again, re-compiling the same kernel, and taking
about 60% of the time! It was amazing.–
“As usual, this being a 1.3.x release, I haven’t even compiled this
kernel yet. So if it works, you should be doubly impressed.”
– Linus Torvalds
Maybe, but not necessarily. Me knowingly clone(), used by the glibc threads
implementation, has been in the kernel since the 2.0 days.
There are threading issues in glibc 2.0 that are fixed only in glibc
2.1. I know that Mozilla requires 2.1 because of that, they are real
showstoppers.
Yes, you’ll see a warning as you compile SDL as it tries to work around
some of the problems.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Pierre> The thing with make is that it only checks the
Pierre> timestamp of source and object files to determine if
Pierre> they need to be rebuilt. If the Makefile changed
Pierre> (because you ran configure with different options) and
Pierre> that the compile options are different, that is not
Pierre> enough to have the files recompiled, because make only
Pierre> sees that you didn’t change the source files.
I guess this is a good argument in favor of using a
`config.h’-file to record these options, since that file will
change every time you change the options and will force the
dependant files to be recompiled.
I guess this is a good argument in favor of using a
`config.h’-file to record these options, since that file will
change every time you change the options and will force the
dependant files to be recompiled.
Well, all files need to be recompiled if config.h changes, because
they all have the same dependency.
Also, when recompiling SDL on UNIX, you need to remove the .la files
if you change source (manually or via make clean), otherwise automake
doesn’t know that it needs to relink the libraries with the new objects.
If anybody knows a workaround for this, PLEASE let me know.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I guess this is a good argument in favor of using a
`config.h’-file to record these options, since that file
will change every time you change the options and will force
the dependant files to be recompiled.
Sam> Well, all files need to be recompiled if config.h changes,
Sam> because they all have the same dependency.
Indeed. But isn’t that what most people expect when they
reconfigure a package? Even if it may compile more files than
needed, it will give the expected result.
Another solution would be to put one `config.h’-file per
directory, with relevant options in each, so that only
directories were options changed get recompiled. But I guess it
would be harder to maintain.
