# SDL-1.2.\[78\] and strange C++ dependencies

**URL:** <https://discourse.libsdl.org/t/sdl-1-2-78-and-strange-c-dependencies/12127>\
**Category:** SDL Development\
**Created:** [April 27, 2005, 9:11pm UTC](https://discourse.libsdl.org/t/sdl-1-2-78-and-strange-c-dependencies/12127 "2005-04-27T21:11:22Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mike\_Castle](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/a9adbd/32.png) [@Mike\_Castle](https://discourse.libsdl.org/u/Mike_Castle)\
**Post date:** [April 27, 2005, 9:11pm UTC](https://discourse.libsdl.org/t/sdl-1-2-78-and-strange-c-dependencies/12127/1 "2005-04-27T21:11:22Z")

</div>

Home grown Linux x86 system, pretty bleeding edge on everything.

It looks like, starting with SDL-1.2.7, that [libSDL.so](http://libSDL.so) now depends on  
libstdc++:

nexus at thune[1:24pm]/usr/src/SDL(417) ldd ./SDL-1.2.8-build/src/.libs/libSDL.so  
libstdc++.so.6 =\> /usr/lib/libstdc++.so.6 (0x4009c000)  
libm.so.6 =\> /lib/libm.so.6 (0x40179000)  
libdl.so.2 =\> /lib/libdl.so.2 (0x4019e000)  
libX11.so.6 =\> /usr/X11R6/lib/libX11.so.6 (0x401a2000)  
libXext.so.6 =\> /usr/X11R6/lib/libXext.so.6 (0x4026b000)  
libpthread.so.0 =\> /lib/libpthread.so.0 (0x40279000)  
libc.so.6 =\> /lib/libc.so.6 (0x402cc000)  
libgcc\_s.so.1 =\> /usr/lib/libgcc\_s.so.1 (0x403e1000)  
/lib/ld-linux.so.2 (0x80000000)

As a result, when other apps try to find if SDL is installed, and they use  
gcc instead of g++, they fail with linkage errors during configure. Here’s  
an example from config.log from libdv that’s pretty typical:

configure:19648: checking for sdl-config  
configure:19666: found /usr/X11R6/bin/sdl-config  
configure:19679: result: /usr/X11R6/bin/sdl-config  
configure:19687: checking for SDL - version \>= 1.1.6  
configure:19779: i486-linux-gcc -o conftest -g -O2 -Wall -g -I/usr/X11R6/include /SDL -D\_REENTRANT -I/usr/X11R6/include -L/usr/X11R6/lib conftest.c -L/usr/X11R6 /lib -Wl,-rpath,/usr/X11R6/lib -lSDL -lpthread \>&5  
/usr/lib/libstdc++.so.6: undefined reference to `_Unwind_DeleteException at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to`\_Unwind\_Resume at GCC\_3.0’  
/usr/lib/libstdc++.so.6: undefined reference to `_Unwind_RaiseException at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to`\_Unwind\_GetRegionStart at GCC\_3.0’  
/usr/lib/libstdc++.so.6: undefined reference to `_Unwind_GetDataRelBase at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to`\_Unwind\_SetGR at GCC\_3.0’  
/usr/lib/libstdc++.so.6: undefined reference to `_Unwind_GetLanguageSpecificData at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to`\_Unwind\_Resume\_or\_Rethrow at GCC\_3.3’  
/usr/lib/libstdc++.so.6: undefined reference to `_Unwind_GetIP at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to`\_Unwind\_GetTextRelBase at GCC\_3.0’  
/usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_SetIP at GCC\_3.0’  
collect2: ld returned 1 exit status

It looks like the problem is, starting with SDL-1.2.7, switching from  
automake-1.4 to automake-1.8.

As a result, we end up with this section in src/main/Makefile.in:

[libarch.la](http://libarch.la): $(libarch\_la\_OBJECTS) $(libarch\_la\_DEPENDENCIES)  
$(CXXLINK) $(libarch\_la\_LDFLAGS) $(libarch\_la\_OBJECTS) $(libarch\_la\_LIBADD) $(LIBS)

In 1.2.6, that was LINK, not CXXLINK. Running automake-1.9 against  
SDL-1.2.6 ended up with a CXXLINK there as well, so I’m pretty sure it’s  
automake.

I believe the problem comes from this in [Makefile.am](http://Makefile.am):

if TARGET\_BEOS  
ARCH\_SRCS = beos/SDL\_BeApp.cc beos/SDL\_BeApp.h  
else  
ARCH\_SRCS = arch.c  
endif

Because there is at least one path that has a potential .cc file, it uses  
CXXLINK instead of LINK. Actually, cheating and changing SDL\_BeApp.cc to  
SDL\_BeApp.c and rerunning automake results in LINK instead CXXLINK.

Anyway, I use this patch locally when building:

diff -ru SDL-1.2.8.orig/src/main/Makefile.in SDL-1.2.8/src/main/Makefile.in  
— SDL-1.2.8.orig/src/main/Makefile.in 2004-12-13 01:04:02.000000000 -0800  
+++ SDL-1.2.8/src/main/Makefile.in 2005-04-27 13:08:18.000000000 -0700  
@@ -411,7 +411,7 @@  
rm -f “$${dir}/so\_locations”;   
done  
[libarch.la](http://libarch.la): $(libarch\_la\_OBJECTS) $(libarch\_la\_DEPENDENCIES)

- 

```
  $(CXXLINK) $(libarch_la_LDFLAGS) $(libarch_la_OBJECTS) $(libarch_la_LIBADD) $(LIBS)

```

- 

```
  $(LINK) $(libarch_la_LDFLAGS) $(libarch_la_OBJECTS) $(libarch_la_LIBADD) $(LIBS)

```

mostlyclean-compile:  
-rm -f \*.$(OBJEXT)

And that makes for a happyier library:

nexus at thune[2:07pm]/usr/src/SDL(328) ldd ./SDL-1.2.8-build/src/.libs/libSDL.so  
libm.so.6 =\> /lib/libm.so.6 (0x4009c000)  
libdl.so.2 =\> /lib/libdl.so.2 (0x400c2000)  
libX11.so.6 =\> /usr/X11R6/lib/libX11.so.6 (0x400c6000)  
libXext.so.6 =\> /usr/X11R6/lib/libXext.so.6 (0x4018f000)  
libpthread.so.0 =\> /lib/libpthread.so.0 (0x4019d000)  
libc.so.6 =\> /lib/libc.so.6 (0x401f0000)  
/lib/ld-linux.so.2 (0x80000000)

What I don’t understand is, how does this work on distributions like  
debian? I didn’t see a similar patch for their libSDL. So does it link  
against libstdc++ there? If so, how do they get other applications to  
build against that libSDL?

I’m not sure what to suggest here. Just pointing out the problem and my  
local work around.

Thoughts?  
mrc

---

<div class="post-metadata">

**Author:** ![Tyler\_Montbriand](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/t/7bcc69/32.png) [@Tyler\_Montbriand](https://discourse.libsdl.org/u/Tyler_Montbriand)\
**Post date:** [April 27, 2005, 10:46pm UTC](https://discourse.libsdl.org/t/sdl-1-2-78-and-strange-c-dependencies/12127/2 "2005-04-27T22:46:06Z")

</div>

I’m not sure the library and the link error are related. My libSDL.so also  
depends on libstdc++.so.6 and I get no linkage problems at all compiling with  
pure C.

All the same, last I checked SDL was pure C, it shouldn’t need libstdc++. If  
that can be trimmed out it’ll make the whole library leaner at no extra cost,  
that’s got to be a good thing.On Wednesday 27 April 2005 15:11, Mike Castle wrote:

> Home grown Linux x86 system, pretty bleeding edge on everything.
> 
> It looks like, starting with SDL-1.2.7, that libSDL.so now depends on  
> libstdc++:
> 
> nexus at thune[1:24pm]/usr/src/SDL(417) ldd  
> ./SDL-1.2.8-build/src/.libs/libSDL.so libstdc++.so.6 =\>  
> /usr/lib/libstdc++.so.6 (0x4009c000)  
> libm.so.6 =\> /lib/libm.so.6 (0x40179000)  
> libdl.so.2 =\> /lib/libdl.so.2 (0x4019e000)  
> libX11.so.6 =\> /usr/X11R6/lib/libX11.so.6 (0x401a2000)  
> libXext.so.6 =\> /usr/X11R6/lib/libXext.so.6 (0x4026b000)  
> libpthread.so.0 =\> /lib/libpthread.so.0 (0x40279000)  
> libc.so.6 =\> /lib/libc.so.6 (0x402cc000)  
> libgcc\_s.so.1 =\> /usr/lib/libgcc\_s.so.1 (0x403e1000)  
> /lib/ld-linux.so.2 (0x80000000)
> 
> As a result, when other apps try to find if SDL is installed, and they use  
> gcc instead of g++, they fail with linkage errors during configure.

---

<div class="post-metadata">

**Author:** ![Mike\_Castle](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/m/a9adbd/32.png) [@Mike\_Castle](https://discourse.libsdl.org/u/Mike_Castle)\
**Post date:** [April 27, 2005, 11:19pm UTC](https://discourse.libsdl.org/t/sdl-1-2-78-and-strange-c-dependencies/12127/3 "2005-04-27T23:19:35Z")

</div>

If I get rid of the dependency on libstdc++, everything is happy.

However, you may be right in that there are other issues.

For example, if I install binutils 2.15.94.0.2.2, MesaLib builds, but if I  
install 2.16.90.0.1, then MesaLib also fails with:

/usr/lib/libstdc++.so.6: undefined reference to `_Unwind_DeleteException at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_Resume at GCC\_3.0’  
/usr/lib/libstdc++.so.6: undefined reference to `_Unwind_RaiseException at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_GetRegionStart at GCC\_3.0’  
/usr/lib/libstdc++.so.6: undefined reference to `_Unwind_GetDataRelBase at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_SetGR at GCC\_3.0’  
/usr/lib/libstdc++.so.6: undefined reference to `_Unwind_GetLanguageSpecificData at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_Resume\_or\_Rethrow at GCC\_3.3’  
/usr/lib/libstdc++.so.6: undefined reference to `_Unwind_GetIP at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_GetTextRelBase at GCC\_3.0’  
/usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_SetIP at GCC\_3.0’  
collect2: ld returned 1 exit status

It may be that I need to rebuild the entire heirachy with the older  
binutils. That’s just a nuisance. :-/

mrcOn Wed, Apr 27, 2005 at 04:46:06PM -0600, Tyler Montbriand wrote:

> I’m not sure the library and the link error are related. My libSDL.so also  
> depends on libstdc++.so.6 and I get no linkage problems at all compiling with  
> pure C.
> 
> All the same, last I checked SDL was pure C, it shouldn’t need libstdc++. If  
> that can be trimmed out it’ll make the whole library leaner at no extra cost,  
> that’s got to be a good thing.

---

<div class="post-metadata">

**Author:** ![james\_osburn](https://discourse.libsdl.org/letter_avatar_proxy/v4/letter/j/85e7bf/32.png) [@james\_osburn](https://discourse.libsdl.org/u/james_osburn)\
**Post date:** [April 28, 2005, 12:24am UTC](https://discourse.libsdl.org/t/sdl-1-2-78-and-strange-c-dependencies/12127/4 "2005-04-28T00:24:40Z")

</div>

i have had the same issue when i compiled SDL agains uclibc system  
mike frysmiker on the gentoo embedded list said it my be  
related to the useage of libtool … i gave up for now  
i have other task to worry about.  
jim

\>From: Tyler Montbriand \>Reply-To: "A list for developers using the SDL library. \>(includesSDL-announce)" \>To: Mike Castle ,"A list for developers using the \>SDL library. (includesSDL-announce)" \>Subject: Re: [SDL] SDL-1.2.[78] and strange C++ dependencies \>Date: Wed, 27 Apr 2005 16:46:06 -0600 \> \>On Wednesday 27 April 2005 15:11, Mike Castle wrote: \> \> Home grown Linux x86 system, pretty bleeding edge on everything. \> \> \> \> It looks like, starting with SDL-1.2.7, that libSDL.so now depends on \> \> libstdc++: \> \> \> \> nexus at thune[1:24pm]/usr/src/SDL(417) ldd \> \> ./SDL-1.2.8-build/src/.libs/libSDL.so libstdc++.so.6 =\> \> \> /usr/lib/libstdc++.so.6 (0x4009c000) \> \> libm.so.6 =\> /lib/libm.so.6 (0x40179000) \> \> libdl.so.2 =\> /lib/libdl.so.2 (0x4019e000) \> \> libX11.so.6 =\> /usr/X11R6/lib/libX11.so.6 (0x401a2000) \> \> libXext.so.6 =\> /usr/X11R6/lib/libXext.so.6 (0x4026b000) \> \> libpthread.so.0 =\> /lib/libpthread.so.0 (0x40279000) \> \> libc.so.6 =\> /lib/libc.so.6 (0x402cc000) \> \> libgcc\_s.so.1 =\> /usr/lib/libgcc\_s.so.1 (0x403e1000) \> \> /lib/ld-linux.so.2 (0x80000000) \> \> \> \> As a result, when other apps try to find if SDL is installed, and they \>use \> \> gcc instead of g++, they fail with linkage errors during configure. \>I'm not sure the library and the link error are related. My libSDL.so also \>depends on libstdc++.so.6 and I get no linkage problems at all compiling \>with \>pure C. \> \>All the same, last I checked SDL was pure C, it shouldn't need libstdc++. \>If \>that can be trimmed out it'll make the whole library leaner at no extra \>cost, \>that's got to be a good thing. \> \>\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ \>SDL mailing list \>SDL at libsdl.org \>http://www.libsdl.org/mailman/listinfo/sdl

---

<div class="post-metadata">

**Author:** ![Mark\_Bishop](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/mark_bishop/32/292_2.png) [@Mark\_Bishop](https://discourse.libsdl.org/u/Mark_Bishop)\
**Post date:** [April 28, 2005, 6:51pm UTC](https://discourse.libsdl.org/t/sdl-1-2-78-and-strange-c-dependencies/12127/5 "2005-04-28T18:51:33Z")

</div>

Greetings, I’m also encountering this problem trying to  
compile the SDL template project distributed with KDevelop  
(on Knoppix 3.7), having installed SDL from RPM earlier  
today (only the run-time libraries are included by  
default); unfortunately, I’m not proficient enough with  
Linux to attempt to compile SDL (patched) from source, so  
I’m just wondering if a kind soul 🙂 on this mailing list  
could email me a copy of the 1.2.6 development RPM?

Thanks,

Mark Bishop–

* * *

Surf the Web in a faster, safer and easier way:  
Download Opera 8 at [http://www.opera.com](http://www.opera.com)

Powered by Outblaze

---

<div class="post-metadata">

**Author:** ![Mikael\_Eriksson](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/mikael_eriksson/32/433_2.png) [@Mikael\_Eriksson](https://discourse.libsdl.org/u/Mikael_Eriksson)\
**Post date:** [April 28, 2005, 8:19pm UTC](https://discourse.libsdl.org/t/sdl-1-2-78-and-strange-c-dependencies/12127/6 "2005-04-28T20:19:59Z")

</div>

Mark Bishop wrote:

> Greetings, I’m also encountering this problem trying to  
> compile the SDL template project distributed with KDevelop  
> (on Knoppix 3.7), having installed SDL from RPM earlier  
> today (only the run-time libraries are included by  
> default); unfortunately, I’m not proficient enough with  
> Linux to attempt to compile SDL (patched) from source, so  
> I’m just wondering if a kind soul 🙂 on this mailing list  
> could email me a copy of the 1.2.6 development RPM?

Knoppix is debian based, isn’t it?  
In that case you should run: apt-get install libsdl1.2-dev  
to install the SDL development files.\> Thanks,

> Mark Bishop

---

<div class="post-metadata">

**Author:** ![John\_Knottenbelt](https://discourse.libsdl.org/user_avatar/discourse.libsdl.org/john_knottenbelt/32/436_2.png) [@John\_Knottenbelt](https://discourse.libsdl.org/u/John_Knottenbelt)\
**Post date:** [April 29, 2005, 9:25am UTC](https://discourse.libsdl.org/t/sdl-1-2-78-and-strange-c-dependencies/12127/7 "2005-04-29T09:25:44Z")

</div>

Hi Mike

I recommend doing using readelf instead. The problem with ldd is that  
it will list also the dependencies of SDL itself.

readelf -d will list the library dependencies of SDL

On my system:  
% readelf -d /usr/lib/libSDL.so  
Dynamic segment at offset 0x62db4 contains 37 entries:  
Tag Type Name/Value  
0x00000001 (NEEDED) Shared library: [libartsc.so.0]  
0x00000001 (NEEDED) Shared library:  
[libgmodule-2.0.so.0]  
0x00000001 (NEEDED) Shared library:  
[libgthread-2.0.so.0]  
0x00000001 (NEEDED) Shared library:  
[libglib-2.0.so.0]  
0x00000001 (NEEDED) Shared library: [libesd.so.0]  
0x00000001 (NEEDED) Shared library:  
[libaudiofile.so.0]  
0x00000001 (NEEDED) Shared library: [libaudio.so.2]  
0x00000001 (NEEDED) Shared library: [libXt.so.6]  
0x00000001 (NEEDED) Shared library: [libX11.so.6]  
0x00000001 (NEEDED) Shared library: [libXext.so.6]  
0x00000001 (NEEDED) Shared library: [libvga.so.1]  
0x00000001 (NEEDED) Shared library: [libaa.so.1]  
0x00000001 (NEEDED) Shared library:  
[libasound.so.2]  
0x00000001 (NEEDED) Shared library: [libm.so.6]  
0x00000001 (NEEDED) Shared library: [libdl.so.2]  
0x00000001 (NEEDED) Shared library:  
[libpthread.so.0]  
0x00000001 (NEEDED) Shared library: [libc.so.6]  
0x0000000e (SONAME) Library soname:  
[libSDL-1.2.so.0]  
0x0000000c (INIT) 0xa6e4

readelf -s will list the symbols

Cheers

JohnOn 27 Apr 2005, at 22:11, Mike Castle wrote:

> Home grown Linux x86 system, pretty bleeding edge on everything.
> 
> It looks like, starting with SDL-1.2.7, that libSDL.so now depends on  
> libstdc++:
> 
> nexus at thune[1:24pm]/usr/src/SDL(417) ldd  
> ./SDL-1.2.8-build/src/.libs/libSDL.so  
> libstdc++.so.6 =\> /usr/lib/libstdc++.so.6 (0x4009c000)  
> libm.so.6 =\> /lib/libm.so.6 (0x40179000)  
> libdl.so.2 =\> /lib/libdl.so.2 (0x4019e000)  
> libX11.so.6 =\> /usr/X11R6/lib/libX11.so.6 (0x401a2000)  
> libXext.so.6 =\> /usr/X11R6/lib/libXext.so.6 (0x4026b000)  
> libpthread.so.0 =\> /lib/libpthread.so.0 (0x40279000)  
> libc.so.6 =\> /lib/libc.so.6 (0x402cc000)  
> libgcc\_s.so.1 =\> /usr/lib/libgcc\_s.so.1 (0x403e1000)  
> /lib/ld-linux.so.2 (0x80000000)
> 
> As a result, when other apps try to find if SDL is installed, and they  
> use  
> gcc instead of g++, they fail with linkage errors during configure.  
> Here’s  
> an example from config.log from libdv that’s pretty typical:
> 
> configure:19648: checking for sdl-config  
> configure:19666: found /usr/X11R6/bin/sdl-config  
> configure:19679: result: /usr/X11R6/bin/sdl-config  
> configure:19687: checking for SDL - version \>= 1.1.6  
> configure:19779: i486-linux-gcc -o conftest -g -O2 -Wall -g  
> -I/usr/X11R6/include /SDL -D\_REENTRANT -I/usr/X11R6/include  
> -L/usr/X11R6/lib conftest.c -L/usr/X11R6 /lib  
> -Wl,-rpath,/usr/X11R6/lib -lSDL -lpthread \>&5  
> /usr/lib/libstdc++.so.6: undefined reference to  
> `_Unwind_DeleteException at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_Resume at GCC\_3.0’  
> /usr/lib/libstdc++.so.6: undefined reference to  
> `_Unwind_RaiseException at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_GetRegionStart at GCC\_3.0’  
> /usr/lib/libstdc++.so.6: undefined reference to  
> `_Unwind_GetDataRelBase at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_SetGR at GCC\_3.0’  
> /usr/lib/libstdc++.so.6: undefined reference to  
> `_Unwind_GetLanguageSpecificData at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_Resume\_or\_Rethrow at GCC\_3.3’  
> /usr/lib/libstdc++.so.6: undefined reference to `_Unwind_GetIP at GCC_3.0' /usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_GetTextRelBase at GCC\_3.0’  
> /usr/lib/libstdc++.so.6: undefined reference to `\_Unwind\_SetIP at GCC\_3.0’  
> collect2: ld returned 1 exit status
> 
> It looks like the problem is, starting with SDL-1.2.7, switching from  
> automake-1.4 to automake-1.8.
> 
> As a result, we end up with this section in src/main/Makefile.in:
> 
> libarch.la: $(libarch\_la\_OBJECTS) $(libarch\_la\_DEPENDENCIES)  
> $(CXXLINK) $(libarch\_la\_LDFLAGS) $(libarch\_la\_OBJECTS)  
> $(libarch\_la\_LIBADD) $(LIBS)
> 
> In 1.2.6, that was LINK, not CXXLINK. Running automake-1.9 against  
> SDL-1.2.6 ended up with a CXXLINK there as well, so I’m pretty sure  
> it’s  
> automake.
> 
> I believe the problem comes from this in Makefile.am:
> 
> if TARGET\_BEOS  
> ARCH\_SRCS = beos/SDL\_BeApp.cc beos/SDL\_BeApp.h  
> else  
> ARCH\_SRCS = arch.c  
> endif
> 
> Because there is at least one path that has a potential .cc file, it  
> uses  
> CXXLINK instead of LINK. Actually, cheating and changing SDL\_BeApp.cc  
> to  
> SDL\_BeApp.c and rerunning automake results in LINK instead CXXLINK.
> 
> Anyway, I use this patch locally when building:
> 
> diff -ru SDL-1.2.8.orig/src/main/Makefile.in  
> SDL-1.2.8/src/main/Makefile.in  
> — SDL-1.2.8.orig/src/main/Makefile.in 2004-12-13 01:04:02.000000000  
> -0800  
> +++ SDL-1.2.8/src/main/Makefile.in 2005-04-27 13:08:18.000000000  
> -0700  
> @@ -411,7 +411,7 @@  
> rm -f “$${dir}/so\_locations”;   
> done  
> libarch.la: $(libarch\_la\_OBJECTS) $(libarch\_la\_DEPENDENCIES)
> 
> - 
> 
> ```
> $(CXXLINK) $(libarch_la_LDFLAGS) $(libarch_la_OBJECTS) 
> 
> ```
> 
> $(libarch\_la\_LIBADD) $(LIBS)
> 
> - 
> 
> ```
> $(LINK) $(libarch_la_LDFLAGS) $(libarch_la_OBJECTS) 
> 
> ```
> 
> $(libarch\_la\_LIBADD) $(LIBS)
> 
> mostlyclean-compile:  
> -rm -f \*.$(OBJEXT)
> 
> And that makes for a happyier library:
> 
> nexus at thune[2:07pm]/usr/src/SDL(328) ldd  
> ./SDL-1.2.8-build/src/.libs/libSDL.so  
> libm.so.6 =\> /lib/libm.so.6 (0x4009c000)  
> libdl.so.2 =\> /lib/libdl.so.2 (0x400c2000)  
> libX11.so.6 =\> /usr/X11R6/lib/libX11.so.6 (0x400c6000)  
> libXext.so.6 =\> /usr/X11R6/lib/libXext.so.6 (0x4018f000)  
> libpthread.so.0 =\> /lib/libpthread.so.0 (0x4019d000)  
> libc.so.6 =\> /lib/libc.so.6 (0x401f0000)  
> /lib/ld-linux.so.2 (0x80000000)
> 
> What I don’t understand is, how does this work on distributions like  
> debian? I didn’t see a similar patch for their libSDL. So does it  
> link  
> against libstdc++ there? If so, how do they get other applications to  
> build against that libSDL?
> 
> I’m not sure what to suggest here. Just pointing out the problem and  
> my  
> local work around.
> 
> Thoughts?  
> mrc
> 
> * * *
> 
> SDL mailing list  
> SDL at [libsdl.org](http://libsdl.org)  
> [http://www.libsdl.org/mailman/listinfo/sdl](http://www.libsdl.org/mailman/listinfo/sdl)