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

Mike_Castle · April 27, 2005, 9:11pm

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

Tyler_Montbriand · April 27, 2005, 10:46pm

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.

Mike_Castle · April 27, 2005, 11:19pm

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.

james_osburn · April 28, 2005, 12:24am

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

Mark_Bishop · April 28, 2005, 6:51pm

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

Powered by Outblaze

Mikael_Eriksson · April 28, 2005, 8:19pm

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

John_Knottenbelt · April 29, 2005, 9:25am

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://www.libsdl.org/mailman/listinfo/sdl