[davidgf]

Hi!!

Could you help me with this error?

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

It is caused when I open an image folder.
I downloaded the RPM XBMC-svn.r22427-1.fc11.i586.rpm and the XBMC-svn.r21875-1.fc11.i586.rpm.

Also I can't play videos. When I click them just does not happen anything. It justs stays in the current folder, and I can continue navigating.

I've got all the dependencies and all codecs.

Thank you all in advance!

David

[jmarshall]

Sounds like a problem with the RPM you downloaded. Take it to whoever does those RPMs (it isn't us).

[davidgf]

Hi,

I know it's a distro-related problem, but I'm trying to solve it.
I've solved the image problem by removing the .so provided and soft-linking the system exif lib. Now images work.

Videos still don't work. Is there any verbose mode in xbmc so I can know what is happening and solve it?

Thanks!

David

[PharaohsPaw]

I get a similar error, especially when trying to use the Aeon skin and add/browse videos, although the complaint on mine is with ImageLib-x86_64-linux.so.

When it occurs, xbmc immediately segfaults. If I launch xbmc from an X terminal I get to see the error message and it is always this:

Code:

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

Not to say this can't be an OS problem, but I did a recursive grep through /usr/include (system headers) and the XBMC source tree to try to find either a defintion of the function or other references to it, and this is all I get for results:

Code:

$ grep -R __wrap___printf_chk .    <- from the top of the unpacked xbmc source tree:
./xbmc/cores/DllLoader/exports/wrapper.c:int __wrap___printf_chk(int flag, const char *format, ...)
./xbmc/cores/DllLoader/exports/.svn/text-base/wrapper.c.svn-base:int __wrap___printf_chk(int flag, const char *format, ...)

I get no results grepping in /usr/include.

So I have the impression (though I could definitely be wrong and would welcome any re-edumacation), especially after reading the comments around these wrapper function definitions, that __wrap___printf_chk() is an XBMC-defined function, not a system function, and therefore if there is a portion of code elsewhere that needs this symbol defined (library call...?), I don't understand why this would be a system (OS) problem.

For some reason I am thinking this is a linker problem when building the .so's, but I'm not really sure. I'm trying to figure this out. Maybe newer gcc or g++ (linker) does things differently?

PharaohsPaw

[PharaohsPaw]

Sounds like a problem with the RPM you downloaded. Take it to whoever does those RPMs (it isn't us).

Hi jmarshall,

As it turns out I fixed this on my builds (Fedora 10 and 11) by removing the conditional compile preprocessor statements. In other words, build the wrapper functions anyway.

No more segfaults.

here's the whole patch, diffed against svn24458. Feel free to do whatever you like with it.

Code:

$ cat XBMC-svn24458-wrapper.c-always-build-wrapper-funcs.patch

diff -up XBMC-svn24458/xbmc/cores/DllLoader/exports/wrapper.c.fortify XBMC-svn24458/xbmc/cores/DllLoader/exports/wrapper.c
--- XBMC-svn24458/xbmc/cores/DllLoader/exports/wrapper.c.fortify    2009-11-09 12:14:04.000000000 -0500
+++ XBMC-svn24458/xbmc/cores/DllLoader/exports/wrapper.c    2009-11-09 12:15:29.000000000 -0500
@@ -404,7 +404,9 @@ struct mntent *__wrap_getmntent(FILE *fp
// are actually #defines which are inlined when compiled with -O. Those defines
// actally call __*chk (for example, __fread_chk). We need to bypass this whole
// thing to actually call our wrapped functions.
-#if _FORTIFY_SOURCE > 1
+//
+// let's try dropping conditional compile and do these anyway...
+//#if _FORTIFY_SOURCE > 1

size_t __wrap___fread_chk(void * ptr, size_t ptrlen, size_t size, size_t n, FILE * stream)
{
@@ -446,4 +448,4 @@ size_t __wrap___read_chk(int fd, void *b
   return dll_read(fd, buf, nbytes);
}

-#endif
+//#endif

Is there any harm done in just building these wrapper functions anyway? This solves the problem with RPM's I build on F10 and F11.

Cheers,
PharaohsPaw

[PharaohsPaw]

Just a heads-up for anybody reading this... this patch wasn't the correct way to solve this problem.

Evidently in Fedora 10 and 11, the rpmbuild environment may default to g++ using -D_FORTIFY_SOURCE=2, but does NOT default that for gcc. wrapper.c gets compiled by gcc -- so to make it use -D_FORTIFY_SOURCE=2 (so these wrapper functions that somehow end up being expected to be present in various local XBMC libs actually get built) -- you have to add it to the CFLAGS in the RPM .spec file.

So the problem is solved, and hopefully even the developers can agree that this is the more correct way to solve it for Fedora 10/11.

PharaohsPaw