KDevelop/gcc linking to libraries I don't want with SDL

SDL Development
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I’m making a game in KDevelop using the SDL, and the first two people who
tried it out reported that the binary I sent them was missing a library. I
got the output of ldd on my computer and the binary one of the people made on
their computer, and it uses several libraries that I don’t specify in the
options that no one else has. When I watch the output during the build, the
two final gcc commands (with all the object files) show the options to use
these libraries.

I’m guessing that KDevelop is finding that libSDL.so uses these libraries (it
does on my system) and assumes that I need them. Is there any way to disable
this and only use libSDL directly? These are the four libraries shown from
ldd on another system, and they are all used by libSDL on my system but not
on another system that has the problem:

libasound.so.1 => not found
libesd.so.0 => not found
libXxf86dga.so.1 => not found
libXv.so.1 => not found

Richard Garand - r i c h a r d @ g a r a n d n e t . n e t
(L)ICQ: 12190132 - http://www.garandnet.net
"In the beginning the Universe was created. This has made a lot of people very
angry and been widely regarded as a bad move." - Douglas Adams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8KjE3juZKnjxs0fMRAn8uAJ4361SHI3d1aaTkXqVhWvF3313FOQCfV+Oy
MXUE5hZxTsd4V9JL1lgH1mo=
=BDqj
-----END PGP SIGNATURE-----

2

I don’t know exactly how to do it, but you can statically link to the SDL if
you use a license that keeps your program open source. (GPL is good, but
BSD is not as the code could become closed.)

You should dynamically link to the SDL because this allows people to get the
latest version of the SDL without having to reget your program.

The libraries you speak of are used as follows:
esd = Enlightenment Sound Daemon… the sound system used by Enlightenment
and Gnome
Xv = XVideo… it came in on XFree86 version 4. provides hardware
acceleration for YUV overlays.
Xxf86dga = X windows XFree86 Direct Graphics Access… it came in on XFree86
version 4. it allows for ways to access the graphics card very quickly.
asound = I dunno… some other sound daemon I suppose.

My guess is that either they don’t have the SDL installed correctly, or you
forced it to use YUV acceleration or other things in your code. More than
likely the first one. See if they can run anyother SDL code.> ----- Original Message -----

From: richard@garandnet.net (Richard Garand)
To:
Sent: Wednesday, December 26, 2001 2:21 PM
Subject: [SDL] KDevelop/gcc linking to libraries I don’t want with SDL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I’m making a game in KDevelop using the SDL, and the first two people who
tried it out reported that the binary I sent them was missing a library. I
got the output of ldd on my computer and the binary one of the people made
on
their computer, and it uses several libraries that I don’t specify in the
options that no one else has. When I watch the output during the build,
the
two final gcc commands (with all the object files) show the options to use
these libraries.

I’m guessing that KDevelop is finding that libSDL.so uses these libraries
(it
does on my system) and assumes that I need them. Is there any way to
disable
this and only use libSDL directly? These are the four libraries shown from
ldd on another system, and they are all used by libSDL on my system but
not
on another system that has the problem:

libasound.so.1 => not found
libesd.so.0 => not found
libXxf86dga.so.1 => not found
libXv.so.1 => not found

Richard Garand - r i c h a r d @ g a r a n d n e t . n e t
(L)ICQ: 12190132 - http://www.garandnet.net
"In the beginning the Universe was created. This has made a lot of people
very
angry and been widely regarded as a bad move." - Douglas Adams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8KjE3juZKnjxs0fMRAn8uAJ4361SHI3d1aaTkXqVhWvF3313FOQCfV+Oy
MXUE5hZxTsd4V9JL1lgH1mo=
=BDqj
-----END PGP SIGNATURE-----

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

3

Actually… that’s not totally the case. There is a way that an SDL program
can be closed source. Loki and others have done this with many of their
programs. I don’t know the full details to how they got around it, but it
has to do prominently with the SDL library being released under the LGPL and
not the GPL.

JarrodOn Thursday 27 December 2001 21:20, you wrote:

I don’t know exactly how to do it, but you can statically link to the SDL
if you use a license that keeps your program open source. (GPL is good,
but BSD is not as the code could become closed.)

4

Yes there is a way. They dynamically link to the SDL library.> ----- Original Message -----

From: magnwa@home.com (magnwa)
To:
Sent: Thursday, December 27, 2001 9:48 AM
Subject: Re: [SDL] KDevelop/gcc linking to libraries I don’t want with SDL

On Thursday 27 December 2001 21:20, you wrote:

I don’t know exactly how to do it, but you can statically link to the
SDL

if you use a license that keeps your program open source. (GPL is good,
but BSD is not as the code could become closed.)

Actually… that’s not totally the case. There is a way that an SDL
program
can be closed source. Loki and others have done this with many of their
programs. I don’t know the full details to how they got around it, but it
has to do prominently with the SDL library being released under the LGPL
and
not the GPL.

Jarrod

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

5

The libraries you speak of are used as follows:
esd = Enlightenment Sound Daemon… the sound system used by Enlightenment
and Gnome
Xv = XVideo… it came in on XFree86 version 4. provides hardware
acceleration for YUV overlays.
Xxf86dga = X windows XFree86 Direct Graphics Access… it came in on XFree86
version 4. it allows for ways to access the graphics card very quickly.
asound = I dunno… some other sound daemon I suppose.

Some distributions ship with dynamic versions of these libraries, and others
don’t. It sounds like you rebuilt SDL on your box which has them as shared
libraries. The SDL RPM should only have libesd dynamically linked.

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

6

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On December 27, 2001 09:20 pm, Fro Joe wrote:

You should dynamically link to the SDL because this allows people to get
the latest version of the SDL without having to reget your program.

That is my goal, but I don’t know how to do it…

Richard Garand - r i c h a r d @ g a r a n d n e t . n e t
(L)ICQ: 12190132 - http://www.garandnet.net
"Inform all the troops that communications have completely broken down."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8K5+cjuZKnjxs0fMRApGXAKCKbmoHfPxHEoefqvlRA9j08HhqzQCgibjx
vhdLXNJUITy9E2nsX0TKabA=
=sA7h
-----END PGP SIGNATURE-----

7

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On December 27, 2001 04:26 pm, Sam Lantinga wrote:

Some distributions ship with dynamic versions of these libraries, and
others don’t. It sounds like you rebuilt SDL on your box which has them as
shared libraries. The SDL RPM should only have libesd dynamically linked.

Does that mean SDL is still statically linked and only uses one library, or
it’s dynamically linked? I’ll try changing my libraries and see what it
does…

Richard Garand - r i c h a r d @ g a r a n d n e t . n e t
(L)ICQ: 12190132 - http://www.garandnet.net
"In the beginning the Universe was created. This has made a lot of people very
angry and been widely regarded as a bad move." - Douglas Adams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8K6HPjuZKnjxs0fMRAp9wAJ4i1DaLsFytghji+/cwPpyAoILnZgCgox9b
dqjfCKMFKpGUVlhn38yFt9U=
=HIiM
-----END PGP SIGNATURE-----

8

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On December 27, 2001 04:33 pm, Richard Garand wrote:

Does that mean SDL is still statically linked and only uses one library, or
it’s dynamically linked? I’ll try changing my libraries and see what it
does…

I installed the mandrake SDL and SDL-devel RPMS and force KDevelop to
reconfigure; same results. I also tried building from source with

  • –enable-shared --disable-static and it did the same thing.

Richard Garand - r i c h a r d @ g a r a n d n e t . n e t
(L)ICQ: 12190132 - http://www.garandnet.net
"…systems wrongly configured with Microsoft SQL Server software…" – ZDNet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8K651juZKnjxs0fMRArn7AJ9JdqQ8NfGngXjTOQw60v9Q/4OlnwCg9gcR
K6Rf63QOdbxNCpac1XRpysM=
=UcGE
-----END PGP SIGNATURE-----

9

Richard Garand wrote:

I’m guessing that KDevelop is finding that libSDL.so uses these libraries (it
does on my system) and assumes that I need them. Is there any way to disable
this and only use libSDL directly? These are the four libraries shown from
ldd on another system, and they are all used by libSDL on my system but not
on another system that has the problem:

libasound.so.1 => not found
libesd.so.0 => not found
libXxf86dga.so.1 => not found
libXv.so.1 => not found

Heh. No this just has to do with how Linux does shared library
dependancies. This is why binaries are specific to distributions. You
end up having to make binaries for the popular distributions – but
untainted version of those distributions. Source is good!!
– David Snopek

/-- libksd –
| The C++ Cross-Platform Game Framework
| Only want to write it once??
| http://libksd.sourceforge.net
------------

10

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On December 26, 2001 03:16 pm, David Snopek wrote:

Heh. No this just has to do with how Linux does shared library
dependancies. This is why binaries are specific to distributions. You
end up having to make binaries for the popular distributions – but
untainted version of those distributions. Source is good!!

Which doesn’t seem to stop Loki… source is good, but no source is better
than no Linux build.

Richard Garand - r i c h a r d @ g a r a n d n e t . n e t
(L)ICQ: 12190132 - http://www.garandnet.net
"/pub/distributions/Mandrake/Mandrake/Mandrake/8.1/i586/Mandrake is new cwd."

    • Tucows FTP
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG v1.0.6 (GNU/Linux)
      Comment: For info see http://www.gnupg.org

iD8DBQE8K8f1juZKnjxs0fMRAlmTAKC+5uK4MN7qYt5yKRV5ocExJX11rwCffU+U
WZddJ+4L1BkgmTvW2GmOKWU=
=qVi0
-----END PGP SIGNATURE-----

11

I haven’t seen a clear solution to your problem, and I can not offer one
either, but I think I may have a “hackish” solution.

I’m guessing that KDevelop is finding that libSDL.so uses these libraries (it
does on my system) and assumes that I need them.

That would be my guess as well.

Is there any way to disable
this and only use libSDL directly?

There probably are, but it will probably require you to perform the
linking step manually - and read the ld info pages.

These are the four libraries shown from
ldd on another system, and they are all used by libSDL on my system but not
on another system that has the problem:

libasound.so.1 => not found
libesd.so.0 => not found
libXxf86dga.so.1 => not found
libXv.so.1 => not found

Quite clearly your binary ends up referencing these libraries, because
libSDL requires them on your system.

I see a number of possible options to solve your problem. Not all of them
may actually work, but I am just trying to suggest ideas.

a) Distribute as source
b) Distribute as not-finally-linked
c) Distribute as static
d) Load libSDL dynamically at run time
e) Use ld magic
f) Use extremely ugly hacks.

a) is not an option in your case (as I understood it).
b) may be OK for you, in this case you link all your objects into a large
nearlyanexecutable.o and delivers this with a script to link with the
local copy of libSDL. Prone to errors, and requires the recepient to
have suitable development tools. (I think you may need the -i or -r
option for this, btw).
c) Simply compile as static. AFAIK it is quite easy to link static only
against a simple library. IIRC something like
ld blablabla -Bstatic lSDL -Bdynamic moreblabla is enough. (Look it
up).
d) You could consider using ldopen to load libSDL at runtime. I do not
know if it is doable, but I suppose it is.
e) Linker magic. A number of options exists. I am not an expert, but I
believe that you can write a linker script that contains the needed
symbols from your collections of objects (stuff like SDL_SetVideoMode),
and use this for linking. Call the script libSDL.1.2.so (or whatever),
and I think the linker on the target machine will automatically resolve
all the symbols and dependencies.
Options that I found interessting are
–auxiliary
–filter
–script
–allow-shlib-undefined
f) What comes to mind here is simply deleting the dependencies from your
executable (using a hex editor or sed script to replace with \0
strings). Then supply a script to identify the actual SDL dependencies
on your target platform (using sdl-config) and preload the required
libraries (using LD_PRELOAD) before running your executable. Gets ugly
fairly quickly.

MadsOn Wed, 26 Dec 2001, Richard Garand wrote:

–
Mads Bondo Dydensborg. @Mads_Bondo_Dydensbor
Before we’d usually say, there is a deep rumbling sound of penguins. Now
it’s time to begin with: The earth is quaking, hell yeah the penguins are
here!!

12

Mads Bondo Dydensborg wrote:

I haven’t seen a clear solution to your problem, and I can not offer one
either, but I think I may have a “hackish” solution.

I’m guessing that KDevelop is finding that libSDL.so uses these libraries (it
does on my system) and assumes that I need them.

That would be my guess as well.

No! In linux, the if you link against a shared library, your program
automatically depends on the dependancy of that library. Not all
operating systems do this but linux does.

Is there any way to disable
this and only use libSDL directly?

There probably are, but it will probably require you to perform the
linking step manually - and read the ld info pages.

Once again, it is the linking stage that does this!

These are the four libraries shown from
ldd on another system, and they are all used by libSDL on my system but not
on another system that has the problem:

libasound.so.1 => not found
libesd.so.0 => not found
libXxf86dga.so.1 => not found
libXv.so.1 => not found

Quite clearly your binary ends up referencing these libraries, because
libSDL requires them on your system.

There are only two real (binary) solutions. (1) Build your binaries for
each distribution. Or (2) rebuild libasound, libesd, libXxf86dga, and
libXv statically so they are copied directly into SDL.
– David Snopek

/-- libksd –
| The C++ Cross-Platform Game Framework
| Only want to write it once??
| http://libksd.sourceforge.net
------------> On Wed, 26 Dec 2001, Richard Garand wrote:

13

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On December 28, 2001 02:33 pm, David Snopek wrote:

There are only two real (binary) solutions. (1) Build your binaries for
each distribution. Or (2) rebuild libasound, libesd, libXxf86dga, and
libXv statically so they are copied directly into SDL.
– David Snopek

So if I were to build SDL with --disable-shared and --enable-static it should
work?

Richard Garand - r i c h a r d @ g a r a n d n e t . n e t
(L)ICQ: 12190132 - http://www.garandnet.net
"In the beginning the Universe was created. This has made a lot of people very
angry and been widely regarded as a bad move." - Douglas Adams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8LkawjuZKnjxs0fMRAvBaAKDFi9LjHwhOXlvZ61rrUp3o9pVDJwCg+VRr
m0pCjL6rqEuk2fvYVDEDZiE=
=fmb1
-----END PGP SIGNATURE-----

14

No! In linux, the if you link against a shared library, your program
automatically depends on the dependancy of that library. Not all
operating systems do this but linux does.

The linker does this, not liunx, I assume?

Once again, it is the linking stage that does this!

I think we do agree.

There are only two real (binary) solutions. (1) Build your binaries for
each distribution. Or (2) rebuild libasound, libesd, libXxf86dga, and
libXv statically so they are copied directly into SDL.

I am not convinced.

MadsOn Fri, 28 Dec 2001, David Snopek wrote:

–
Mads Bondo Dydensborg. @Mads_Bondo_Dydensbor
Oh well, all operating systems crash constantly right? This is normal, right?
It has to be, Microsoft couldn’t be so popular if their OS was so bad, could
they?
Yes they could, and they are. And if you fail to realize it, it’s your own
damn fault.
- Ron Coscorrosa, in response to MS France FUD

15

Hi,

Sorry, it can be a bit out of topic.
I have a problem with SDL_GL_LoadLibrary and static linking (it
segfaults).(it works very well without the -static option at compilation).
I searched and tried this very minimalist program:

#include <stdio.h>
#include <dlfcn.h>
int main(int argc, char **argv) {
void *handle;
char *error;

handle = dlopen ("/usr/lib/libGL.so",RTLD_NOW);
if (!handle) {
fputs (dlerror(), stderr);
exit(1);
}
dlclose(handle);
}

I compiled it with: gcc -o test test.c -ldl -rdynamic
Of course, this worked very well, but remember, I want static linking
(that’s for providing binaries easily installable on linux boxes, like
Loki does). That’s why I tried: gcc -o test test.c -ldl -rdynamic -static
…and it segfaulted when trying to execute dlopen(), like
SDL_GL_LoadLibrary.

But there is something very strange: if I dlopen /lib/libm.so.6 instead of
/usr/lib/libGL.so, it DOES NOT segfaults, even with the -static option.

I tried to link (statically) with -L/usr/lib -lSDL -lpthread
-L/usr/X11R6/lib -lX11 -lXext -ldl -L/usr/X11R6/lib -lXxf86dga -lXxf86vm
-lXv -L/usr/lib/ -lm in case libGL.so needed some symbol (? in this case,
it should not segfault, but print the symbols on exit (because of
RTLD_NOW)),

Any help would be very appreciated…

-Clement.–
Clement “phneutre” Bourdarias
phneutre at mangoquest.org
www.mangoquest.org

16

No! In linux, the if you link against a shared library, your program
automatically depends on the dependancy of that library. Not all
operating systems do this but linux does.

The linker does this, not liunx, I assume?

The dynamic linker does this.

There are only two real (binary) solutions. (1) Build your binaries for
each distribution. Or (2) rebuild libasound, libesd, libXxf86dga, and
libXv statically so they are copied directly into SDL.

I am not convinced.

Believe it.

-Sam Lantinga, Software Engineer, Blizzard Entertainment> On Fri, 28 Dec 2001, David Snopek wrote:
17

Richard Garand wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There are only two real (binary) solutions. (1) Build your binaries for
each distribution. Or (2) rebuild libasound, libesd, libXxf86dga, and
libXv statically so they are copied directly into SDL.
– David Snopek

So if I were to build SDL with --disable-shared and --enable-static it should
work?

Not necessarily. The configure options control how SDL is built. If
you do --disable-shared --enable-static it will only build libSDL.a and
not libSDL.so. What you need to do is rebuild those dependancies as
static libraries (*.a) but with position independant compile (-fPIC) so
that you can still build libSDL.so. See the documentation for the
specific libraries in question for more information on how to do that.
– David Snopek

/-- libksd –
| The C++ Cross-Platform Game Framework
| Only want to write it once??
| http://libksd.sourceforge.net
------------> On December 28, 2001 02:33 pm, David Snopek wrote:

18

You can’t statically link an OpenGL program on Linux.
It’s as simple as that. The OpenGL drivers will not work.
It has nothing to do with SDL, other than that SDL takes advantage of the fact.

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

19

So, when “ldd tribes2” says “not a dynamic executable”, it is a lie ?
If I link all libs statically except -lGL and -lpthread (using
-Wl,-Bstatic and -Wl,-Bdynamic), ldd still says it is a dynamic
executables and prints the concerned libs. What did you do on the tribes2
binary ?

If I understand correctly, the only advantage of using SDL_GL_LoadLibrary
and SDL_GL_GetProcAdress is to have the choice of the GL library we want
to use, with a command line argument (–gllibrary in the case of Loki
games). Am I right ?

Thanks,
-Clement

You can’t statically link an OpenGL program on Linux.
It’s as simple as that. The OpenGL drivers will not work.
It has nothing to do with SDL, other than that SDL takes advantage of
the fact.>On Mon, 31 Dec 2001 10:58:43 -0800 Sam Lantinga wrote:
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

20

So, when “ldd tribes2” says “not a dynamic executable”, it is a lie ?
If I link all libs statically except -lGL and -lpthread (using
-Wl,-Bstatic and -Wl,-Bdynamic), ldd still says it is a dynamic
executables and prints the concerned libs. What did you do on the tribes2
binary ?

tribes2 is just a wrapper program. The real one is called tribes2.bin
(or something like that)

If I understand correctly, the only advantage of using SDL_GL_LoadLibrary
and SDL_GL_GetProcAdress is to have the choice of the GL library we want
to use, with a command line argument (–gllibrary in the case of Loki
games). Am I right ?

That’s right. It should be less necessary now, with more distributions
coming pre-configured with OpenGL hardware acceleration support.

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