CVS update (CRITICAL)

SDL Development
1

This CVS snapshot fixes a couple of critical bugs, so please download
it instead of using the SDL 1.1.5 release code. I’m going to let it
simmer for a few days and release 1.1.6 very soon.

You can get the code from: http://www.libsdl.org/cvs.html

Changes:

  • Fixed middle-button handling on DirectInput
  • Added SDL_GetThreadID() to get a specific thread’s ID
  • Worked around a crash in pthreads on RedHat 7
  • Mattias fixed brown bag crash in RLE clipping code
  • Lots of warning cleanups, including a fbcon mouse bugfix.
  • Warnings are enabled by default when building with gcc
  • Optimizations can be enabled with configure --disable-debug

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

2

Sam Lantinga wrote:

This CVS snapshot fixes a couple of critical bugs, so please download
it instead of using the SDL 1.1.5 release code. I’m going to let it
simmer for a few days and release 1.1.6 very soon.

Yet again, Sam, could you please integrate some changes from FreeBSD Ports
Collection into forthcoming release? (most notably Svgalib support).
http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/devel/sdl-devel/patches/

-Maxim

3

Yet again, Sam, could you please integrate some changes from FreeBSD Ports
Collection into forthcoming release? (most notably Svgalib support).
http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/devel/sdl-devel/patches/

Got it, thanks!
The next CVS snapshot will have the timer and SVGAlib patches integrated.
If you could test them, that would be great, since I merged the Linux and
FreeBSD SVGAlib support, and I can’t test it on either platform.

Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

4

Sam Lantinga wrote:

Yet again, Sam, could you please integrate some changes from FreeBSD Ports
Collection into forthcoming release? (most notably Svgalib support).
http://www.FreeBSD.org/cgi/cvsweb.cgi/ports/devel/sdl-devel/patches/

Got it, thanks!
The next CVS snapshot will have the timer and SVGAlib patches integrated.
If you could test them, that would be great, since I merged the Linux and
FreeBSD SVGAlib support, and I can’t test it on either platform.

I tested in on FreeBSD - it compiles/works w/o any problems (unfortunately I
can’t test it on Linux, because I doesn’t have it). Thanks!

BTW, is it possible to modify SDL in such a way to append release suffix to all
pieces being installed (i.e. include/SDL -> include/SDL11, aclocal/sdl.m4 ->
aclocal/sdl11.m4 etc.)? It would allow several potentially incompatible releases
to be installed on the same machine w/o causing confusion and conflicts. We
already have home-grown hack for that in FreeBSD and it would be nice to see it
in the mainline. This is exactly how most long run projects with lots of
incomparable at API level releases behave (for example gtk/glib).

-Maxim

5

in the mainline. This is exactly how most long run projects with lots of
incomparable at API level releases behave (for example gtk/glib).

Yes, and it’s awful. This sort of problem should be handled
transparently with the SO_NAME such that applications linked against
1.1 can’t run-time load 1.0 libSDLs. The old 1.0 libSDL lives on
peacefully in the same directory, etc.

Qt messes this up also, requiring awful symbolic links and even
ld.so.conf hackage.

I can’t see why anyone would use SDL 1.0 anyway… it’s not like
there’s some huge body of programs out there that require it being
installed.

m.On Thu, Oct 05, 2000 at 08:47:54PM +0300, Maxim Sobolev wrote:

–
Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire

6

Michael Vance wrote:

in the mainline. This is exactly how most long run projects with lots of
incomparable at API level releases behave (for example gtk/glib).

Yes, and it’s awful. This sort of problem should be handled
transparently with the SO_NAME such that applications linked against
1.1 can’t run-time load 1.0 libSDLs. The old 1.0 libSDL lives on
peacefully in the same directory, etc.

I don’t see any reasons why it is awful (if done properly). Please note that
I’m not talking about shared library, which currently handled pretty well, but
about include/SDL, sdl-config, libSDLmain.a and sdl.m4.

Qt messes this up also, requiring awful symbolic links and even
ld.so.conf hackage.

It is not a reson why SDL could not handle it properly…

I can’t see why anyone would use SDL 1.0 anyway… it’s not like
there’s some huge body of programs out there that require it being
installed.

Again it is not a sufficient reason why not to provide such feature - there may
be users who want to use both SDL11 and SDL10 (for example developers, who want
to ensure correct functioning of their software with both 1.0 and 1.1 - don’t
forget that 1.0 is officially advertised “stable” version) and they certainly
would welcome such feature. After all, I hope 1.1 is not going to be the last
version of SDL, so logically we could expect SDL1.2, 2.0 etc., which probably
will have some incompatabilities with older releases. Thus taking into account
number of software written for SDL currently and its growth rate it is obvious
that such feature will be eventually unavoidable to ensure smoth transition
process from one release to another.

-Maxim> On Thu, Oct 05, 2000 at 08:47:54PM +0300, Maxim Sobolev wrote:

7

“Maxim” == Maxim Sobolev writes:

[…]

Maxim> there may be users who want to use both SDL11 and SDL10
Maxim> (for example developers, who want to ensure correct
Maxim> functioning of their software with both 1.0 and 1.1 -
Maxim> don’t forget that 1.0 is officially advertised "stable"
Maxim> version) and they certainly would welcome such feature.

I don’t really see the benefits of your proposal. People who
want multiple version of SDL can install them in different
places (e.g. /opt/SDL-1.0.8, /opt/SDL-1.1.5, etc.). What’s
wrong with this?

On my host, I have SDL 1.0.x in /usr/{lib,include,bin} and SDL 1.1.x
in /home/adl/usr/{lib,include,bin}. I configure my package with
–with-sdl=/usr or --with-sdl=$HOME/usr whether I want to link my
game the former or the later. I’m perfectly happy with this setup.

[…]–
Alexandre Duret-Lutz

8

Alexandre Duret-Lutz wrote:

“Maxim” == Maxim Sobolev writes:

[…]

Maxim> there may be users who want to use both SDL11 and SDL10
Maxim> (for example developers, who want to ensure correct
Maxim> functioning of their software with both 1.0 and 1.1 -
Maxim> don’t forget that 1.0 is officially advertised "stable"
Maxim> version) and they certainly would welcome such feature.

I don’t really see the benefits of your proposal. People who
want multiple version of SDL can install them in different
places (e.g. /opt/SDL-1.0.8, /opt/SDL-1.1.5, etc.). What’s
wrong with this?

On my host, I have SDL 1.0.x in /usr/{lib,include,bin} and SDL 1.1.x
in /home/adl/usr/{lib,include,bin}. I configure my package with
–with-sdl=/usr or --with-sdl=$HOME/usr whether I want to link my
game the former or the later. I’m perfectly happy with this setup.

I do not see any benefits of your setup either.

-Maxim

9

I do not see any benefits of your setup either.

His doesn’t require changes to the SDL source.

m.On Fri, Oct 06, 2000 at 05:37:10PM +0300, Maxim Sobolev wrote:

–
Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire

10

“Maxim” == Maxim Sobolev writes:

Maxim> Alexandre Duret-Lutz wrote:

[…]

I don’t really see the benefits of your proposal. People who
want multiple version of SDL can install them in different
places (e.g. /opt/SDL-1.0.8, /opt/SDL-1.1.5, etc.). What’s
wrong with this?

[…]

Maxim> I do not see any benefits of your setup either.

Maxim,

Your answer probably means my followup sounded offensive, though
it was not my intention: I’m not trying to reprove you idea,
I’m just trying to understand it. You want to be able to handle
multiple versions of SDL and therefore you propose to add some
new support for that. I’m showing that multiple versions can
already be handed. Hence, the question is: if a new feature
is added, what’s the benefits over the current possibility.
I’m sure there are advantages to what you suggest (otherwise you
would not have asked for it) but I don’t see them.

[…]–
Alexandre Duret-Lutz

11

I’ve used multiple SDL installations in different base directories for
a long time. People who aren’t root on their boxes can’t install the
stuff under /usr or /usr/local anyway, not to mention how convenient
it is to be able to nuke or move an entire installation without
affecting anything else

12

Alexandre Duret-Lutz wrote:

“Maxim” == Maxim Sobolev writes:

Maxim> Alexandre Duret-Lutz wrote:

[…]

I don’t really see the benefits of your proposal. People who
want multiple version of SDL can install them in different
places (e.g. /opt/SDL-1.0.8, /opt/SDL-1.1.5, etc.). What’s
wrong with this?

[…]

Maxim> I do not see any benefits of your setup either.

Maxim,

Your answer probably means my followup sounded offensive, though
it was not my intention: I’m not trying to reprove you idea,
I’m just trying to understand it. You want to be able to handle
multiple versions of SDL and therefore you propose to add some
new support for that. I’m showing that multiple versions can
already be handed. Hence, the question is: if a new feature
is added, what’s the benefits over the current possibility.
I’m sure there are advantages to what you suggest (otherwise you
would not have asked for it) but I don’t see them.

The problem really arises when you have to care about some package system (for
example one we have in FreeBSD). While I understand that each developer may
have some home-grown solution for the problem, for example one you have
described in your previous e-mail, but it’s just not suitable for generic
solution, when you have some constrains which you need to take into account.
Just to give you an idea, in FreeBSD we have so-called LOCALBASE (usually
/usr/local) into which all third party packages should be installed and
appropriate reference directories layout to store files of various purposes
(LOCALBASE/include for includes, LOCALBASE/lib for libraries, LOCALBASE/share
for shared data and so on) and all packages required to conform (or be hacked
to conform) to this reference layout.

Then please considering a following situation (pretty real): some package A
depends on SDL1.0, while package B depends on SDL1.1 and A, B are not mutually
exclusive, so the user potentially might want to install both. In this case we
have to cope somehow with problem that both SDL1.0 and SDL1.1 are trying to use
the same filenames, thus creating a conflict when user needs both SDL1.1 and
SDL1.0 to be installed. Of course we can tell the user “hey, you can’t have A
and B both installed because SDL1.0 and SDL1.1 can not coexist on the same
machine”, but this would be a pretty lame answer and simply not true enough, so
we have to develop some hack to workaround this problem. Of course maintaining
this hack is costly and ungrateful task, so as a maintainer of sdl and many
related packages in FreeBSD I’m trying to came with some generic solution,
which can satisfy both our and SDL’s long term goals.

-Maxim

13

“Maxim” == Maxim Sobolev writes:

[…]

Maxim> Then please considering a following situation (pretty
Maxim> real): some package A depends on SDL1.0, while package B
Maxim> depends on SDL1.1 and A, B are not mutually exclusive,
Maxim> so the user potentially might want to install both. In
Maxim> this case we have to cope somehow with problem that both
Maxim> SDL1.0 and SDL1.1 are trying to use the same filenames,
Maxim> thus creating a conflict when user needs both SDL1.1 and
Maxim> SDL1.0 to be installed. Of course we can tell the user
Maxim> “hey, you can’t have A and B both installed because
Maxim> SDL1.0 and SDL1.1 can not coexist on the same machine”,

Debian use a nice approach that solves this kind of problem [*]
(I’m speaking of Debian because I use it, but RedHat seems to do
the same, and probably other Linux distribution too). From an
upstream library package `foo’ they build TWO packages:

  libfoo       contains the library, used by other programs
  libfoo-dev   contains the header files, for developers

“library” packages for different versions of the same library
(e.g. libsdl1.0 and libsdl1.1) can easily coexist on the same
host because of the different SO names. Only the dev packages
(e.g. libsdl1.0-dev and libsdl1.1-dev) are mutualy exclusive.

As your A and B programs are concerned, there is no conflict
since both libsdl1.0 and libsdl1.1 can be installed.

Maxim> but this would be a pretty lame answer and simply not
Maxim> true enough, so we have to develop some hack to
Maxim> workaround this problem. Of course maintaining this
Maxim> hack is costly and ungrateful task,

undoubtedly

Maxim> so as a maintainer of sdl and many related packages in
Maxim> FreeBSD I’m trying to came with some generic solution,
Maxim> which can satisfy both our and SDL’s long term goals.

I don’t know how the FreeBSD packaging system works, I have
heard good comments on it, but maybe it doesn’t allow the above
approach. BTW, is there other packaging systems that does not
handle this?

Anyway, it seams to me that this issue is not SDL-specific: all
library packages which offer multiple versions are concerned,
right? Therfore it would be a waste of time to change only
SDL. If you want a generic solution, and if this solution
need some works, my opinion [2] is that this work is probably
better done in:
- the FreeBSD packaging systems, if possible
or
- automake, if you can convince them

Of course since I’m not a FreeBSD package maintainer, nor an
automake or SDL developer, my opinion is not really
significant…

Ciao,

[*] http://www.debian.org/doc/debian-policy/ch4.html#s4.3--
Alexandre Duret-Lutz

14

Alexandre Duret-Lutz wrote:

“Maxim” == Maxim Sobolev writes:

[…]

Maxim> Then please considering a following situation (pretty
Maxim> real): some package A depends on SDL1.0, while package B
Maxim> depends on SDL1.1 and A, B are not mutually exclusive,
Maxim> so the user potentially might want to install both. In
Maxim> this case we have to cope somehow with problem that both
Maxim> SDL1.0 and SDL1.1 are trying to use the same filenames,
Maxim> thus creating a conflict when user needs both SDL1.1 and
Maxim> SDL1.0 to be installed. Of course we can tell the user
Maxim> “hey, you can’t have A and B both installed because
Maxim> SDL1.0 and SDL1.1 can not coexist on the same machine”,

Debian use a nice approach that solves this kind of problem [*]
(I’m speaking of Debian because I use it, but RedHat seems to do
the same, and probably other Linux distribution too). From an
upstream library package `foo’ they build TWO packages:

  libfoo       contains the library, used by other programs
  libfoo-dev   contains the header files, for developers

“library” packages for different versions of the same library
(e.g. libsdl1.0 and libsdl1.1) can easily coexist on the same
host because of the different SO names. Only the dev packages
(e.g. libsdl1.0-dev and libsdl1.1-dev) are mutualy exclusive.

As your A and B programs are concerned, there is no conflict
since both libsdl1.0 and libsdl1.1 can be installed.

Unlike most Linux ones FreeBSD package system is mostly source-based, so the
user need to install whole SDL development tree to build/run an application.

Maxim> so as a maintainer of sdl and many related packages in
Maxim> FreeBSD I’m trying to came with some generic solution,
Maxim> which can satisfy both our and SDL’s long term goals.

I don’t know how the FreeBSD packaging system works, I have
heard good comments on it, but maybe it doesn’t allow the above
approach. BTW, is there other packaging systems that does not
handle this?

Anyway, it seams to me that this issue is not SDL-specific: all
library packages which offer multiple versions are concerned,
right? Therfore it would be a waste of time to change only
SDL. If you want a generic solution, and if this solution
need some works, my opinion [2] is that this work is probably
better done in:
- the FreeBSD packaging systems, if possible
or
- automake, if you can convince them

Nope, this issue is SDL-specific (and have nothing to do with aucomake stuff
IMO). Some modern packages handle this gracefully (for example gtk/glib) and I
don’t see any problems with getting SDL handling it properly.

OK, I see this thread run into dead-end and probably it would be better to let
it die. Time will show who is right. :wink:

-Maxim

15

IMO). Some modern packages handle this gracefully (for example
gtk/glib) and I don’t see any problems with getting SDL handling it

Well, again, I don’t think there’s anything remotely graceful about
the way gtk+ handled things in the 1.0 to 1.1/1.2 transition, or the
Qt guys, etc.

it die. Time will show who is right. :wink:

Ha :slight_smile:

m.On Mon, Oct 09, 2000 at 10:05:05AM +0300, Maxim Sobolev wrote:

–
Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire