[PharaohsPaw]

FWIW, this is how I fixed segfaults I was getting on Fedora 10 and Fedora 11 builds of XBMC involving an unresolved symbol in the ImageLib .so library.

The segfaults I get give this type of output to stderr when launching xbmc from the commandline:

Code:

/usr/share/xbmc/xbmc.bin: symbol lookup error:
/usr/share/xbmc/system/ImageLib-x86_64-linux.so: undefined symbol:
__wrap___printf_chk

Somebody else gets unresolved symbol errors for the same lib function in libexif-i486-linux.so, as noted in the forum link posted below.

Note, this is a link to another post in another topic here on the forums. Not sure if anybody is paying attention to that thread anymore but since unresolved symbols with wrapper functions defined in wrapper.c seems to happen to a few folks, I thought it might be worth posting a new topic with link to the other post:

http://forum.xbmc.org/showpost.php?p=434162&postcount=5

I'm not an XBMC developer. But maybe the XBMC developers could evaluate this patch and do something useful with it.

It may be that an "#ifdef FORTIFY_SOURCE" would be a better test than a particular defined value. But if I don't remove the condition that prevents building these wrapper functions (evidently FORTIFY_SOURCE is not >1 on Fedora 10/11), I get a lot of segfaults, especially when trying to use skins like Aeon.

Cheers,
PharaohsPaw

[spiff]

patch is unacceptable - we have no idea what those functions might be if that define is not set. figure out how to do it properly, i.e. which bastardization of what normal distros do the fedora guys chose this time ;P

[spiff]

#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 1)

is an alternative perhaps

[spiff]

hmm, no. not good enough. all docu i can find fedora enabled this back in 2007 though so it's quite weird.

[PharaohsPaw]

Alright, well, I'm sorry the patch is unacceptable even though it fixes the problem here. I see what you're saying about this being a problem when those functions aren't defined. I can live with the notion that this is a Fedora-specific problem, and won't bother filing a traq for this.

Now, going back to the conditional definition of these functions, I do see "-Wp,-D_FORTIFY_SOURCE=2" among the g++ command lines pretty much throughout my build logs. So I don't know why the conditional is failing.

Maybe I can figure something out. Maybe _FORTIFY_SOURCE isn't 2 when wrapper.c gets built. I'll search the logs a little later and see if I can find anything.

Thanks for the feedback on the patch, it will make me look harder to find the real problem.

PharaohsPaw

[PharaohsPaw]

Well it looks like _FORTIFY_SOURCE=2 isn't defined when gcc compiles wrapper.c:

Code:

/usr/bin/ccache gcc \
-I/usr/lib64/dbus-1.0/include -I/usr/lib64/glib-2.0/include -O2 -I/usr/lib64/dbus-1.0/include \
-I/usr/lib64/glib-2.0/include -O2 -g -D_DEBUG -Wall -I/usr/lib64/dbus-1.0/include \
-I/usr/lib64/glib-2.0/include -O2 -g -D_DEBUG -Wall \
-D_LINUX -D_FILE_DEFINED -D_REENTRANT -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 \
-DINSTALL_PATH="\"/usr/share/xbmc\"" -DHAS_SDL_JOYSTICK -D'SVN_REV="Unknown"' \
-DHAVE_CONFIG_H  -fPIC -c -g -D_LINUX -D_REENTRANT -D_LARGEFILE64_SOURCE \
-D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64 \
-I. -I../../../ -I../../../linux -I../../../../guilib -I/usr/lib64/dbus-1.0/include  \
-I/home/rpmbuild/redhat/BUILD/XBMC-svn24458/xbmc/lib/cximage-6.0/jpeg \
-I/home/rpmbuild/redhat/BUILD/XBMC-svn24458     -I/usr/include/fribidi \
-I/usr/include/libpng12  -I/usr/include/ -I/usr/include/glib-2.0 \
-I/usr/lib64/glib-2.0/include  -I/usr/include/freetype2    -I/usr/include/alsa \
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -DDBUS_API_SUBJECT_TO_CHANGE \
-I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include  \
-D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL   -DDBUS_API_SUBJECT_TO_CHANGE \
-I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include  \
-I/usr/include/lzo \
wrapper.c -o wrapper.o

It seems to be defined pretty much whenever g++ is used (.cpp code) but not seeing it for wrapper.c.

So since _FORTIFY_SOURCE isn't 2 (or even defined at all) when building wrapper.c, these wrapper functions don't get built. Yet something somewhere related to loading images seems to expect __wrap___printf_chk() to be in ImageLib-($arch)-linux.so there anyway. Because it crashes xbmc when it isn't.

I do see that xbmc/cores/DllLoader/exports ships with a static Makefile. Maybe I'll go sniffing around in there and look for things that redefine compiler flags like INCLUDES etc, rather than += them to add stuff somebody thinks is important for that directory. Most of the problems I've ever had building XBMC in the last 8 months or so have been due to this. The rest have been with finding jpegint.h, which nobody is supposed to be #include'ing in source code anyway -- but XBMC does... I wonder if there is even a legitimate reason.

linky:
http://www.mail-archive.com/debian-bugs-...87464.html

PharaohsPaw

Edit: nothing gcc compiles has _FORTIFY_SOURCE set. But basically everything compiled with g++ does. So while adding _FORTIFY_SOURCE=2 may or may not be the solution for everybody, I'm thinking it might be what I need to do here on Fedora, since the C++ sources are getting built that way.

[PharaohsPaw]

Adding -D_FORTIFY_SOURCE=2 to the CFLAGS hacked into the RPM .spec file solves the problem as well. g++ defaults (apparently) to using this anyway, but gcc (apparently) does not. So to make these wrapper functions get built on Fedora 10/11 builds (and you might as well, because XBMC is going to crash in various places if you don't....) you have to tell gcc to use -D_FORTIFY_SOURCE=2 also.

PharaohsPaw