CVS stable again, please update SDL ports

SDL Development
1

The reorganization of the SDL source is complete. If you maintain a port
or project files used to build SDL for a platform, please get the latest
CVS snapshot and send me any fixes or updated projects necessary to build
SDL on your platform:
http://www.libsdl.org/cvs/SDL-1.2.tar.gz
http://www.libsdl.org/cvs/SDL-1.2.zip

Here’s a rundown on what changed…

There is now SDL_config.h, which contains #defines configuring what
platform support there is, and what subsystems and drivers are built.
This header is distributed normally with the rest of the headers.

SDL can now be built without any C runtime support, depending on the
drivers and OS support available. There is a new directory src/stdlib,
and SDL_getenv.c has been moved there, and several other files have been
added to the source tree.

src/endian/SDL_endian.c is obsolete and has been removed.

src/SDL_loadso.c has been replaced by src/loadso/*/SDL_sysloadso.c

The SDL sources all include files in the correct path relative to their
location in the source tree (e.g. #include “…/SDL_sysvideo.h”)

There are lots of other little changes, but those are the ones you’ll
probably need to know the most to update project files and ports.

See ya!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment_______________________________________________
SDL-announce mailing list
SDL-announce at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl-announce

2

Congrats!!!

-bill!On Fri, Feb 24, 2006 at 02:06:06AM -0800, Sam Lantinga wrote:

The reorganization of the SDL source is complete.

3

As a test, I tried a VisualC.zip -> unzip -> build, tests\tests.dsw -> build.

When linking with SDLmain and SDL, any test program, the symbol __fltused is
multiple-defined.

Not sure if it’s a right solution (which impact on other build?), but, for a
standard win32 build, when defining HAVE_LIBC in SDL_config_win32.h, it works.

This remove the declaration "int declspec(selectany) _fltused=1; " done in
SDL_windows.h (I guess this is here for a build without any libc available).

VisualC++ decides to include a reference to this variable when doing any
float/double operation (to link floating point support from libc). I had to add
msvcrtd.lib(debug config) and msvcrt.lib (release) to the list of linked
library in SDL.dsp, to permit the reference to _ftol and such (used by VisualC++
when casting a float to an int, implicitly, etc).

RCS file: /home/sdlweb/libsdl.org/cvs/SDL12/include/SDL_config_win32.h,v
retrieving revision 1.3
diff -r1.3 SDL_config_win32.h
46a47,48

#define HAVE_LIBC 1

Sam Lantinga a ?crit :> The reorganization of the SDL source is complete. If you maintain a port

or project files used to build SDL for a platform, please get the latest
CVS snapshot and send me any fixes or updated projects necessary to build
SDL on your platform:
http://www.libsdl.org/cvs/SDL-1.2.tar.gz
http://www.libsdl.org/cvs/SDL-1.2.zip

Here’s a rundown on what changed…

There is now SDL_config.h, which contains #defines configuring what
platform support there is, and what subsystems and drivers are built.
This header is distributed normally with the rest of the headers.

SDL can now be built without any C runtime support, depending on the
drivers and OS support available. There is a new directory src/stdlib,
and SDL_getenv.c has been moved there, and several other files have been
added to the source tree.

src/endian/SDL_endian.c is obsolete and has been removed.

src/SDL_loadso.c has been replaced by src/loadso/*/SDL_sysloadso.c

The SDL sources all include files in the correct path relative to their
location in the source tree (e.g. #include “…/SDL_sysvideo.h”)

There are lots of other little changes, but those are the ones you’ll
probably need to know the most to update project files and ports.

See ya!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

SDL-announce mailing list
SDL-announce at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl-announce

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

4

I realize that you really wanted to undef HAVE_LIBC to build SDL.dll under
visual C++

#define HAVE_LIBC 1
in SDL_config_win32.h
is certainly not a solution !

The problem shows up when linking SDLmain.lib in a user program. Not when
building SDL.dll.

If you “#define HAVE_LIBC 1” in SDL_win32_main.c before including the unmodified
SDL_config_win32.h, this modifies only SDLmain.lib.

the tests build without any error. This “solution” is certainly better as it
permit to build an app without link to msvcrt if one wants to use his own
SDLmain.lib which doesn’t need MSVCRT (and if his own app doesn’t need it).

RCS file: /home/sdlweb/libsdl.org/cvs/SDL12/src/main/win32/SDL_win32_main.c,v
retrieving revision 1.8
diff -r1.8 SDL_win32_main.c
9a10

#define HAVE_LIBC 1

William Petiot [exoide] a ?crit :> As a test, I tried a VisualC.zip -> unzip -> build, tests\tests.dsw -> build.

When linking with SDLmain and SDL, any test program, the symbol __fltused is
multiple-defined.

Not sure if it’s a right solution (which impact on other build?), but, for a
standard win32 build, when defining HAVE_LIBC in SDL_config_win32.h, it works.

This remove the declaration "int declspec(selectany) _fltused=1; " done in
SDL_windows.h (I guess this is here for a build without any libc available).

VisualC++ decides to include a reference to this variable when doing any
float/double operation (to link floating point support from libc). I had to add
msvcrtd.lib(debug config) and msvcrt.lib (release) to the list of linked
library in SDL.dsp, to permit the reference to _ftol and such (used by VisualC++
when casting a float to an int, implicitly, etc).

RCS file: /home/sdlweb/libsdl.org/cvs/SDL12/include/SDL_config_win32.h,v
retrieving revision 1.3
diff -r1.3 SDL_config_win32.h
46a47,48

#define HAVE_LIBC 1

SDL can now be built without any C runtime support, depending on the
drivers and OS support available. There is a new directory src/stdlib,
and SDL_getenv.c has been moved there, and several other files have been
added to the source tree.

5

As a test, I tried a VisualC.zip -> unzip -> build, tests\tests.dsw -> build.

When linking with SDLmain and SDL, any test program, the symbol __fltused is
multiple-defined.

This should be fixed in CVS, thanks!

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
6

Hi,

Some problems are caused on Tru64 UNIX.
If applying SDL12-osf1.path, these problems are fixed.

  1. configure-script say “recursive mutexes… no” and “pthread
    semaphores… no”.
    checking for pthreads… yes
    checking for recursive mutexes… no
    checking for pthread semaphores… no

This is because it compiled without pthread_cflags and pthread_lib when
checking recursive mutexes and pthread semaphores.

  1. Compiling src/audio/mme/SDL_mmeaudio.c fails.
    cc: Severe: ./src/audio/mme/SDL_mmeaudio.c, line 25: Cannot find file
    <mme_api.h> specified in #include directive. (noinclfilef)
    #include <mme_api.h>
    -^

This is because BUILD_CFLAGS is wrong.

  1. Compiling src/cdrom/osf/SDL_syscdrom.c fails.
    cc: Warning: ./src/cdrom/osf/SDL_syscdrom.c, line 176: Too few actual
    parameters in the invocation of the macro “SDL_stack_alloc”. (toofewactuals)
    cdpath = SDL_stack_alloc(len);
    ------------------------------------^
    cc: Error: ./src/cdrom/osf/SDL_syscdrom.c, line 176: Invalid expression.
    (badexpr)
    cdpath = SDL_stack_alloc(len);
    -----------------^

SDL_stack_alloc is defined in include/SDL_stdinc.h.
#define SDL_stack_alloc(type, count) (type*)alloca(sizeof(type)*count)

  1. Linking fails if running configure with --enable-x11-shared=yes.
    /usr/ccs/bin/ld:
    Warning: Unresolved:
    p_XData32

  2. Compiling src/video/x11/SDL_x11dyn.c fails if running configure with
    –enable-x11-shared=no.
    cc: Error: ./src/video/x11/SDL_x11sym.h, line 149: In this statement,
    "_SmtBufferOverflow" is not declared. (undeclared)
    SDL_X11_SYM(1,void,_SmtBufferOverflow,(Display *dpy,register smtDisplayPtr))
    ^
    cc: Error: ./src/video/x11/SDL_x11sym.h, line 150: In this statement,
    "_SmtIpError" is not declared. (undeclared)
    SDL_X11_SYM(1,void,_SmtIpError,(Display *dpy,register smtDisplayPtr, int))
    ^–
    Hayashi Naoyuki <@Hayashi_Naoyuki>
    Key fingerprint = 60A0 D5D3 F58B 3633 2E52 0147 D17F 5578 3FDF F5B6
    -------------- next part --------------
    An embedded and charset-unspecified text was scrubbed…
    Name: SDL12-osf1.patch
    URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060226/89f70304/attachment.asc

7

Some problems are caused on Tru64 UNIX.
If applying SDL12-osf1.path, these problems are fixed.

Thanks, great patch! This is in CVS.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
8

Do you plan to remove stdio (HAVE_STDIO_H not defined) from standard win32 build
of SDL?
I noticed this because of Test programs in VisualC.zip which do not run without
support for RWops on files. SDL_RWFromFile() is not supported by default SDL.dll
build.

In that case, is there any provision to replace stdio_xxxx SDL internal
functions by straight Win32 Api calls (CreateFile/etc) ?
Would it be usefull if I try to add it, or someone is already working on this?
If yes, where would you put this stuff? In a new file/SDL_stdio.c?
stdlib/SDL_stdio.c? or in existing SDL_RWops.c?

Or, only update test programs to make them use SDL_RWFromMem()? ;p

9

In that case, is there any provision to replace stdio_xxxx SDL internal
functions by straight Win32 Api calls (CreateFile/etc) ?

Yes, that’s the plan.

Would it be usefull if I try to add it, or someone is already working on this?
If yes, where would you put this stuff? In a new file/SDL_stdio.c?
stdlib/SDL_stdio.c? or in existing SDL_RWops.c?

Go for it, you can add an implementation in SDL_rwops.c

Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

10

I managed to get a first implementation of it, which I tested for “simple” use
with tests sample apps, they work ok. I think this needs more tests.

Here is the diff against CVS/SDL12, attached.

Sam Lantinga a ?crit :

In that case, is there any provision to replace stdio_xxxx SDL internal
functions by straight Win32 Api calls (CreateFile/etc) ?

Yes, that’s the plan.

Would it be usefull if I try to add it, or someone is already working on this?
If yes, where would you put this stuff? In a new file/SDL_stdio.c?
stdlib/SDL_stdio.c? or in existing SDL_RWops.c?

Go for it, you can add an implementation in SDL_rwops.c

Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: sdl12_rwops_inc.diff
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060227/aa98ae04/attachment.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: sdl12_rwops.diff
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060227/aa98ae04/attachment.asc

11

I managed to get a first implementation of it, which I tested for “simple” use
with tests sample apps, they work ok. I think this needs more tests.

Here is the diff against CVS/SDL12, attached.

Looks great, your patch is in CVS, thanks!

Would you like to create a testfile.c in the test directory and run through
a few test cases to exercise the code?

Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

12

I switched CVS so that the Win32 API is always used for file rwops.
http://www.libsdl.org/cvs/SDL-1.2.zip

Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

13

Would you like to create a testfile.c in the test directory and run through
a few test cases to exercise the code?

Sure! I’m testing it today, switching between stdio/win32io to compare. If I
don’t find any bug today, I’m planning to send this testfile next week-end at
worse. Don’t worry if you don’t have any news in the next few days. I’ll be off
for 4-5 days (vacation… snow… cold… without any Internet connectivity)

William.

14

Hi all,

I tried to build the latest CVS for WinCE 4.10 and run into a problem with
sdl_thread.h. I got:

d:\delo_simonp\sdl12\include\sdl_thread.h(75) : error C2143: syntax error :
missing ‘)’ before '__cdecl’
d:\delo_simonp\sdl12\include\sdl_thread.h(75) : error C2143: syntax error :
missing ‘{’ before ‘__cdecl’
d:\delo_simonp\sdl12\include\sdl_thread.h(75) : error C2059: syntax error :
’)'
d:\delo_simonp\sdl12\include\sdl_thread.h(77) : error C2165: ‘left-side
modifier’ : cannot modify pointers to data
d:\delo_simonp\sdl12\include\sdl_thread.h(81) : error C2146: syntax error :
missing ‘)’ before identifier ‘pfnBeginThread’
d:\delo_simonp\sdl12\include\sdl_thread.h(81) : error C2081:
‘pfnSDL_CurrentBeginThread’ : name in formal parameter list illegal
d:\delo_simonp\sdl12\include\sdl_thread.h(81) : error C2061: syntax error :
identifier ‘pfnBeginThread’
d:\delo_simonp\sdl12\include\sdl_thread.h(81) : error C2059: syntax error :
’;‘
d:\delo_simonp\sdl12\include\sdl_thread.h(81) : error C2059: syntax error :
’,‘
d:\delo_simonp\sdl12\include\sdl_thread.h(81) : error C2059: syntax error :
’)’

The code in question:

#ifdef OS2
typedef int (*pfnSDL_CurrentBeginThread)(void (*func)(void *), void *,
unsigned, void *arg);
typedef void (*pfnSDL_CurrentEndThread)(void);
#else
#ifdef GNUC
#include <stdint.h>
#endif
typedef uintptr_t (__cdecl *pfnSDL_CurrentBeginThread) (void *,
unsigned, <----- (75)
unsigned (__stdcall *func)(void *), void *arg,
unsigned, unsigned *threadID);
typedef void (__cdecl *pfnSDL_CurrentEndThread)(unsigned code);
#endif

It looks to me that eVC++ (4.0 with sp4) choked on complicated typedef. Any
ideas how to solve it?

Also process.h does not exist on WinCE and OpenGL should not be enabled in
SDL_config_win32.h.

Regards SimonOn 2/26/06, Sam Lantinga wrote:

Some problems are caused on Tru64 UNIX.
If applying SDL12-osf1.path , these problems are fixed.

Thanks, great patch! This is in CVS.

    -Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

15

I found a bug or two in previous patch, so here is a patch to correct this.
Also a testfile.c + VisualC/tests/testfile/testfile.dsp attached. (sorry the
testfile.dsp is in VC6 format, I don’t have VC5 up and running on my PC).

William

Sam Lantinga a ?crit :

I switched CVS so that the Win32 API is always used for file rwops.
http://www.libsdl.org/cvs/SDL-1.2.zip

Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: testfile.c.diff
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060227/2372bffa/attachment.asc
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: SDL_rwops.h.diff
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060227/2372bffa/attachment.txt
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: SDL_rwops.c.diff
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060227/2372bffa/attachment-0001.asc
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: testfile.dsp
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060227/2372bffa/attachment-0001.txt

16

I found a bug or two in previous patch, so here is a patch to correct this.
Also a testfile.c + VisualC/tests/testfile/testfile.dsp attached. (sorry the
testfile.dsp is in VC6 format, I don’t have VC5 up and running on my PC).

Thanks, I’ve added it to CVS.

It’s perfectly legal to set “b” fopen mode on other platforms, so I removed
that bit of macro trickery in testfile.c.

I also put in a VC5 project for testfile, let me know if it works for you,
since I just hand edited one. :slight_smile:

Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

17

The dsp worked great!

But testfile.c has a “WIN32_xxx” macro left in test1 (patch attached). I,
evilly, replaced it with “a+b”, since “ab+” and “a+b” should work under win32. :))

Still, there are some differences left between HAVE_STDIO_H and this
implementation (I’m sorry for this partial support, will it be ok as is?):

  • text mode under win32 : treated as binary mode, this could lead to bugs for
    people relying on it to read text files under win32. transcoding \r\n to \n as
    we read/write is still possible, but does it worth it (is there anyone using
    SDL_rwops to read text files under win32?)?

  • no buffering at all, some code that do fread/fwrite 2 bytes at time 10000
    times could be slowed down dramatically. I could add a “buffer” layer, but again
    , does it worth it?

Anyway, I’m about to reboot under linux to test testfile.c with an old SDL
install. more on this later.

regards,
William.

Sam Lantinga a ?crit :

It’s perfectly legal to set “b” fopen mode on other platforms, so I removed
that bit of macro trickery in testfile.c.

Thought it was only on GNU libc, didn’t know for the other platforms (mac etc).
Thanks for the info !

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: testfile.c.1.diff
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060227/02b4caff/attachment.asc

18
  • text mode under win32 : treated as binary mode, this could lead to bugs for
    people relying on it to read text files under win32. transcoding \r\n to \n as
    we read/write is still possible, but does it worth it (is there anyone using
    SDL_rwops to read text files under win32?)?

It might be worth while, I’m not sure.

  • no buffering at all, some code that do fread/fwrite 2 bytes at time 10000
    times could be slowed down dramatically. I could add a “buffer” layer, but again
    , does it worth it?

Probably not an issue, but I’m open to suggestion…

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
19

Argh,

“test1” in testfile.c is making the current “HAVE_STDIO_H” SDL12 implementation
segfault. Test1 calls SDL_RWFromFile() with bad arguments to see if it dies
(NULL ptr or invalid mode strings), and it dies…

possible solutions:
a)remove this test as the “HAVE_STDIO_H” SDL version is the reference as it is
b)check arguments in HAVE_STDIO_H SDL implementation
c)remove agument checks in win32io_xxxx functions to behave as the stdio_xxx
functions, and do a).

Here is a diff for a)
Linux test is ok with it (so should be any HAVE_STDIO_H defined platform). Let
me know if you wanted anything else. Sorry for this one, I should have catched
this before.

Regards,
William.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed…
Name: testfile.c.a.diff
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060228/60b1a074/attachment.txt

20

Argh,

“test1” in testfile.c is making the current “HAVE_STDIO_H” SDL12 implementation
segfault.

Hah, beat you to it! This is fixed in CVS.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment