Mattias Engdeg?rd wrote:
Sorry for the question mark above, my mail reader doesn’t have the best
Drazen Kacar <@Drazen_Kacar> wrote:
I used Sun’s compiler and everything went fine except 64-bit data type.
SDL_types.h has a rather poor way of detecting if it’s available and the
method failed, because this compiler wasn’t listed.
yes that code is a smelly heap of dung. I thought I had band-aided it for
the WorkShop compiler; I’ll look at it when I can
If you want to put a quick fix just for that compiler, the symbol it
defines is __SUNPRO_C.
- checked if <inttypes.h> header is available on the system
- if so, check if int_least64_t and uint_least64_t are defined
3. if so, those types are exactly what’s needed
4. if there are no *_least64_t types, check for int64_t and uint64_t
5. if they exist, they can hold at least 64 bits, but might be
larger, so use them if they are exactly 64-bits wide.
while we’ll probably use the configure script to find a 64-bit data
type the above is an overkill — we need a type exact 64 bit or none
at all. Nothing for 1.2 at any rate
It is an overkill, I agree. However, that’s what C99 and pre-C99
implementations call for. I’ve been told that there are systems which
don’t have 32-bit type among the basic types (char, short, int, long),
although they do have int32_t. I’ve never had access to one of those, so I
can’t verify from the first hand experience. And they are probably not
very important for SDL. So I don’t know.
Whenever I suggested checking for int64_t, somebody replied that C99
doesn’t make the existance of that type mandatory. Now I’ve sent the
description of the whole thing and I’m being told that it’s an overkill.
SDL_x11image.c has a function num_CPU() which tries to determine number of
processors from kstat structures. The code mostly works, but it would be
somewhat simpler to replace it with:
“mostly works”, meaning that it sometimes does not. Please be more
There are two issues.
You are checking for the number of processors phisically present.
The above sysconf() call would check for the number of processors which
are on-line, ie. the number of processors that any application can
actually use. I suppose that’s the number you’re interested in. You
could dig it up from kstat as well, though.
Sun doesn’t guarantee binary compatibility for applications using
libkstat. The API is stable, I think, but the names of the data
structures are not guaranteed to be. Which means that you might be
forced to #ifdef for a future version of the OS, just as you already
have #ifdef for symbols which were changed between 2.5.1 and 2.6.
I’ll be happy to replace if with the sysconf() if you can verify its
availability for Solaris 2.5.1 and onwards
Currently I don’t have access to 2.5.1 system, but I can say that
sysconf() was working fine for me on 2.5.1, 2.6, 7 and 8 when I was working on
libgtop. And here’s the URL for Sun’s on-line sysconf() documentation for
Solaris 2.5 which lists the above symbol:
The URL could probably be shorter, but the man page is not reachable from
the browsing interface, so I had to use the search facility.
The linking method has a small problem. “sdl-config --libs” outputs only
-lpthread. This is enough to make things work, but there’s one case when
it won’t give the expected results
the 1:1 thread lib is new in sol 8 and I didn’t want to special-case
That’s perfectly fine, you shouldn’t because you are working on the
library. The application should be able to choose which thread library to
use. Or the user who is compiling the application.
When does it not give expected results? I’m not sure what
faults in the Solaris scheduler you are referring to, but shouldn’t
it be enough to request the threads to be bound?
Most of the time, but then the effect you are getting is as if you’re
using 1:1 library with some overhead, so I’d like to get rid of the
overhead. Besides, if you want to have bound threads on Solaris, then the
application has to #ifdef for Solaris. And if that can be avoided by using
alternate thread library implementation when linking, that course of
action should be available. (Admittedly, it doesn’t help if you’re on the
older OS release.)
The joke with libpthread and libthread is that libpthread is a filter for
libthread, ie. if you link with libpthread, run-time linker will load
libthread as well, because that’s where the code is. However, if you link
the application with -R/usr/lib/lwp, that search path will be used only
for direct dependencies of the executable, but not for their dependencies.
So you end up with using /usr/lib/libthread.so, although you intended to
use /usr/lib/lwp/libthread.so. The way to get around that is to also
specify -lthread when linking the application. That way libthread becomes
a direct dependency and search path for the application is honored when
ld.so.1 searches for it.
Thanks for your comments though, I’ll look at it when I get better
There’s one more thing. Recursive mutexes are disabled by configure
script, because it thinks they don’t work on Solaris. I don’t know how
important is to have recursive mutexes in SDL and I don’t know which
problem you encountered.
Is it perhaps bugid 4288299 (Recursive mutexes are not properly released)?
That one has been fixed for Solaris 7 and 8 and patches are available.–
.-. .-. Errors have been made. Others will be blamed.
(_ \ / _)