XBMC 'realloc not defined'

WernerL · 2009-01-22 22:12:32

Hello folks,

I'm trying to install xbmc on my computer.

This one from the aur: http://aur.archlinux.org/packages.php?ID=21608

But while compiling it stops at this line:

32: error: '::realloc' has not been declared
make[1]: *** [ActionManager.o] Error 1
make[1]: Leaving directory `/tmp/yaourt-tmp-wernerl/aur-xbmc/xbmc/src/XBMC/guilib'
make: *** [guilib] Error 2

I already updated my whole computer but that didn't solve the problem.
I really want to try this out. So if anyboy could help me..

Last edited by WernerL (2009-01-23 17:22:00)

rossic · 2009-01-23 16:50:27

For now I will append to your post, as we have a common goal. Hopefully someone will dive in and help us. If you can, it'd be beneficial to have a more explicit explanation in your subject. Something like "XBMC 'realloc not defined' compile error, [x86_64 | i686]," would probably help people understand your issue. A passerby who might know of an issue with realloc, but have no interest in XBMC could pop in and give us a hint.

Anyway, here's the issue:

Build works fine on my i686, but fails with same realloc error on my x86_64. I diffed packages between them and all compiler related packages are matching (that I am aware of).

I went through the make output and noticed this difference (among others):
i686: checking for GNU libc compatible realloc... yes
x86_64: checking for GNU libc compatible realloc... no

Another branch of this problem is that in cstdlib, realloc is undefined, and then referenced. Comments suggest that it is forcing it to use the non std versions of functions (such as realloc). One fix I found (and have not tried) is to comment out the undefine, effectively allowing it to use the std. Worst case is it doesn't work, best case is that it works, but I may be violating licenses (I have no idea if that's true).

Does anyone know of a good solution?

WernerL · 2009-01-23 17:21:38

Changed the subject.
I have a 32bits installation btw.

rossic · 2009-01-23 17:50:43

Interesting... When you compile, does it find a "GNU libc compatible realloc?"

gorus · 2009-01-23 20:08:24

ive had this same exact error on my arch 64bit .. so i figured hey its only a htpc ill install arch 32bit on it since i only got couple packages on the box anyways and all the files are on raid. so i did .. fresh install (my cpu on that box is core2duo), same error.. that made me thiking and because i spent days trying to compile it on this box i figured to hell with it ill try it on my desktop ( athlon xp x2 , arch 32bit ), same revision compiled without a glitch. at this moment im loosing it and thinking about installing ubuntu on my htpc !

rossic · 2009-01-23 20:27:24

Don't do anything rash, gorus! Arch is the greatest (from what I've tinkered with, Ubuntu is nice, too... but...).

The fact that you've had this problem in both builds, and the maker of the xbmc package has had success in both builds, means there's something we're missing. It's only a matter of time until this is solved (I'm hoping soon, because I'd really like to try this out on my htpc!).

gorus · 2009-01-23 20:56:48

ive installed arch in my parents house on 2 machines and on my little sisters university computer as well. myself been using arch for years and have it installed on all my computers atm. i know how good arch is; trust you me. .. but i spent days (many) trying to get this one f**n' thing to work on it, reading forums talking to people, reinstalling arch back and forth .. not much else i can do and xbmc is just too nice of a program (for htpc) for me not to have it.

[vEX] · 2009-01-23 21:55:35

As the package manager of XBMC I'm equally annoyed. Though I've somehow managed to "break" my i686 machine as it does not build XBMC anymore. At least that means I can replicate the issue and have something to work against. I've also compared my build outputs and I think the following might be a clue:

-checking whether lstat dereferences a symlink specified with a trailing slash... no
-checking whether lstat accepts an empty string... yes
-checking whether lstat dereferences a symlink specified with a trailing slash... (cached) no
-checking for working memcmp... no
+checking whether lstat dereferences a symlink specified with a trailing slash... yes
+checking whether lstat accepts an empty string... no
+checking whether lstat dereferences a symlink specified with a trailing slash... (cached) yes
+checking for working memcmp... yes
 checking for sys/time.h... (cached) yes
 checking for unistd.h... (cached) yes
 checking for utime.h... (cached) yes
@@ -192,9 +191,9 @@
 checking for stdlib.h... (cached) yes
 checking for unistd.h... (cached) yes
 checking for getpagesize... yes
-checking for working mmap... no
+checking for working mmap... yes
 checking for stdlib.h... (cached) yes
-checking for GNU libc compatible realloc... no
+checking for GNU libc compatible realloc... yes

The negative prefixed ones are from i686 while the positive prefixed ones are from my x86_64 machine.

[vEX] · 2009-01-23 22:30:36

Okay, now this is just weird and might work for you. After running makekpg and watching it fail, try the following:

cd src/XBMC
vim (or whichever editor you prefer) config.h

Change line 245 so it says that you have REALLOC:
#define HAVE_REALLOC 1

And uncomment line 528:
/*#define realloc rpl_realloc*/

Save and close the file, now try and run make. That makes it compile here, or at least it seems like that, it's really late and I'm off to get some sleep. If someone can verify that it compiles and that the resulting binary works then it can't be a missing package, now can it? Perhaps the automake tools in Arch are too new?

EDIT: This "hack" might should also trick autoconf: http://wiki.buici.com/wiki/Autoconf_and … he_Problem.

EDIT2: I noticed this in the build log:

line 197: checking for GNU libc compatible realloc... no
line 2622: checking for GNU libc compatible realloc... yes

Eh? The second one is output by /var/abs/local/xbmc/src/XBMC/xbmc/lib/libass.. This makes me think it's some bug in autoconf.

Last edited by [vEX] (2009-01-23 22:56:27)

gorus · 2009-01-23 23:48:02

i will try that the minute i get home .. but at least we are onto something and we get ppl with the knowhow looking into this .. im drinking to that

rossic · 2009-01-24 02:00:08

Excellent sleuthing, vEX! I regret to inform that it segfaults late in the build... for me anyway. It faults when compiling the skins. I tried both methods you mentioned - modifying config.h, as well as running

ac_cv_func_realloc_0_nonnull=yes makepkg

I find it interesting that it segfaults. Null realloc cause that you suppose?

I'm curious how others fair with this. Off to run some build comparisons. Will post results later.

gorus · 2009-01-24 15:03:21

rossic is right, from now on ill call [vEX] - Mr. Poirot,

[vEX] wrote:

cd src/XBMC
vim (or whichever editor you prefer) config.h
Change line 245 so it says that you have REALLOC:
#define HAVE_REALLOC 1
And uncomment line 528:
/*#define realloc rpl_realloc*/

different line # for me here and in my config.h line 528 was already commented out. how is that ?
anyway, that took care of guilibc errors, it errors for me while making faad2 now but that might just be the newest revision ( it wouldnt compile on my athlon as well ) ill try something older and report. Mr. Poirot you are the man.

Last edited by gorus (2009-01-24 16:27:46)

[vEX] · 2009-01-25 09:40:44

Damn, it segfaulted while compiling the skins for me as well. I looked through the src/XBMC/config.log and it seems that the test for realloc segfaults with return code 139 for me. The config.log also dumps out the data that it used for the test.

configure:11967: checking for GNU libc compatible realloc
configure:12001: gcc -o conftest -march=i686 -mtune=native -O2 -pipe            conftest.c -lhal-storage -ldbus-1 -lcurl -lpcre -lXrandr -lXmu -lXt -lenca -lfaac -ljpeg -ljasper -lpng12 -lresolv -lrt -lasound -lmysqlclient -lsqlite3 -llzo2 -lfribidi -lbz2 -lfontconfig -lfreetype -ldl -lSDL_mixer -lSDL_image -lSDL -lvorbis -logg -ltre -lmad -lXinerama -lGLU -lGLEW -lGL  >&5
configure:12004: $? = 0
configure:12010: ./conftest
./configure: line 12011:  2248 Segmentation fault      ./conftest$ac_exeext
configure:12013: $? = 139
configure: program exited with status 139
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME ""xbmc""
| #define PACKAGE_TARNAME "-xbmc-"
| #define PACKAGE_VERSION "2.1"
| #define PACKAGE_STRING ""xbmc" 2.1"
| #define PACKAGE_BUGREPORT "bugs@xbmc.org"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_LIBGL 1
| #define HAVE_LIBGLEW 1
| #define HAVE_LIBGLU 1
| #define HAVE_LIBXINERAMA 1
| #define HAVE_LIBMAD 1
| #define HAVE_LIBTRE 1
| #define HAVE_LIBOGG 1
| #define HAVE_LIBVORBIS 1
| #define HAVE_LIBSDL 1
| #define HAVE_LIBSDL_IMAGE 1
| #define HAVE_LIBSDL_MIXER 1
| #define HAVE_LIBDL 1
| #define HAVE_LIBFREETYPE 1
| #define HAVE_LIBFONTCONFIG 1
| #define HAVE_LIBBZ2 1
| #define HAVE_LIBFRIBIDI 1
| #define HAVE_LIBLZO2 1
| #define HAVE_LIBSQLITE3 1
| #define HAVE_LIBMYSQLCLIENT 1
| #define HAVE_LIBASOUND 1
| #define HAVE_LIBRT 1
| #define HAVE_LIBRESOLV 1
| #define HAVE_LIBPNG12 1
| #define HAVE_LIBJASPER 1
| #define HAVE_LIBJPEG 1
| #define HAVE_LIBFAAC 1
| #define HAVE_LIBENCA 1
| #define HAVE_LIBXT 1
| #define HAVE_LIBXMU 1
| #define HAVE_LIBXRANDR 1
| #define HAVE_LIBPCRE 1
| #define HAVE_LIBCURL 1
| #define HAVE_LIBDBUS_1 1
| #define HAVE_LIBHAL_STORAGE 1
| #define HAVE_DIRENT_H 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_WAIT_H 1
| #define HAVE_ARPA_INET_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_FLOAT_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_LIMITS_H 1
| #define HAVE_LOCALE_H 1
| #define HAVE_MALLOC_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_NETDB_H 1
| #define HAVE_NETINET_IN_H 1
| #define HAVE_STDDEF_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_SYS_FILE_H 1
| #define HAVE_SYS_IOCTL_H 1
| #define HAVE_SYS_MOUNT_H 1
| #define HAVE_SYS_PARAM_H 1
| #define HAVE_SYS_SOCKET_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_SYS_TIMEB_H 1
| #define HAVE_SYS_VFS_H 1
| #define HAVE_TERMIOS_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_UTIME_H 1
| #define HAVE_WCHAR_H 1
| #define HAVE_WCTYPE_H 1
| #define HAVE_LZO_LZO1_H 1
| #define HAVE__BOOL 1
| #define HAVE_STDBOOL_H 1
| #define restrict __restrict
| #define HAVE_STRUCT_STAT_ST_RDEV 1
| #define TIME_WITH_SYS_TIME 1
| #define HAVE_ALLOCA_H 1
| #define HAVE_ALLOCA 1
| #define HAVE_UNISTD_H 1
| #define CLOSEDIR_VOID 1
| #define HAVE_FSEEKO 1
| #define HAVE_LSTAT_EMPTY_STRING_BUG 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_UTIME_H 1
| #define HAVE_ALARM 1
| #define HAVE_STDLIB_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_GETPAGESIZE 1
| #define HAVE_STDLIB_H 1
| /* end confdefs.h.  */
| #if defined STDC_HEADERS || defined HAVE_STDLIB_H
| # include <stdlib.h>
| #else
| char *realloc ();
| #endif
| 
| int
| main ()
| {
| return ! realloc (0, 0);
|   ;
|   return 0;
| }
configure:12029: result: no

I took the code and saved it in a new file (and of course removed the prefixed "| " from each line) and than compiled it with the same command as stated in the log. Running the executable and checking the return code (echo $?) shows a 0, just as on my x86_64 machine. I have no idea why it segfaults in the configure script but not when run alone.

EDIT: Okay, the problem might be in fakeroot. Compiling the test and then running it inside fakeroot triggers the segfault:

$ fakeroot
[root@loke tmp]# gcc -o conftest -march=i686 -mtune=native -O2 -pipe   conftest.c  -lGLU -g
[root@loke tmp]# ./conftest
Segmentation fault
[root@loke tmp]# gdb conftest
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) run
Starting program: /tmp/conftest 

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0xb803a583 in tmp___xstat () from /usr/lib/libfakeroot/libfakeroot.so
#2  0xb80399b3 in __xstat () from /usr/lib/libfakeroot/libfakeroot.so
#3  0xb7df13b4 in ?? () from /usr/lib/libGL.so.1
#4  0x00000003 in ?? ()
#5  0xb7e2e0e1 in ?? () from /usr/lib/libGL.so.1
#6  0xb7e692a0 in ?? () from /usr/lib/libGL.so.1
#7  0xb7e3d080 in ?? () from /usr/lib/libGL.so.1
#8  0x00000001 in ?? ()
#9  0x00000000 in ?? ()
(gdb)

However if I skip the -lGLU flag it will not segfault.

I should mention that I use an ATi card in this machine and an Nvidia one in the HTPC, so it could be that fakeroot doesn't play nicely with the nvidia drivers.

Last edited by [vEX] (2009-01-25 10:09:31)

rossic · 2009-01-25 13:08:42

Very interesting indeed. The computer I was compiling with had Intel (that worked without needing to fuss with realloc), Nvidia (that failed) and I have another that I haven't tested with an ATI card. It's a dual boot with windows and has been encoding the past couple days. It should be done in just a few more hours, so I'll test it soon. I'm surprised that something like this could be the result of a video driver.

What is the -lGLU flag? I'm assuming it's somewhere in the makefile... do you suggest we remove it?

[vEX] · 2009-01-25 15:30:55

Doing pacman -Rd nvidia-utils; pacman -S libgl; makepkg -c; pacman -Rd libgl; pacman -S nvidia-utils seems to be the workaround. I'm in the middle of makepkg now so it looks promising. I'll edit this post when it's done and report whether the binary actually works afterwards or not.

EDIT: Yeah, that did the trick, builds and runs fine.

Last edited by [vEX] (2009-01-25 16:07:24)

rossic · 2009-01-25 20:45:32

HOLY CRAP!!

You're amazing, vEX! That was totally it. I took a slightly different route. (I use yaourt...)

modprobe -r nvidia
yaourt -S xbmc

Worked like a champ! Thanks! Of all work arounds I've seen, this is by far the cleanest! Now if I could only get japanese file names to display properly in xbmc....

EDIT:
I ran into a little snag in XBMC - clicking the speaker (audio/subtitle) while playing video crashed. I figured I'd try the svn build to see if it had been fixed. It bombed for unrelated reasons so I went back to vEX's build. It failed for the same reason as before. My previous method no longer worked. Unknown as to why. vEX's solution worked perfectly. Weird, and once again proved vEX's awesomeness

Thanks again!

Last edited by rossic (2009-01-26 04:16:20)

gorus · 2009-01-26 19:55:36

i 2nd that .. compiled and running the newest xbmc-svn revision, thanks to [vEX] (Poirot) and his investigative skills.
not saying i have a problem with removing nvidia when building xbmc, but where do we go from here? how do we get it so that we can compile xbmc without any extra steps ?

[vEX] · 2009-01-30 19:42:24

I'm on to something thanks to google, it appears that with gcc 4.3 they streamlined the header includes [1]. Hopefully some added includes should do the trick.

[1] http://gcc.gnu.org/gcc-4.3/porting_to.html

EDIT: I just uploaded xbmc 8.10-8 to AUR, it should now build fine and not complain about undeclared realloc. Also removed some unneeded Mac OS X files.

Last edited by [vEX] (2009-01-30 21:17:04)

gorus · 2009-01-31 14:39:12

very very nice [vEX] did you hear anything about xbmc and libtool problems / solutions ?

[vEX] · 2009-01-31 15:48:39

Well, if you look at the gentoo ebuild they it does some stuff with/for autoconf:
- 8.10 http://bugs.gentoo.org/attachment.cgi?id=177426
- svn http://bugs.gentoo.org/attachment.cgi?id=177427
- tracker ticket http://bugs.gentoo.org/198849

TheLateJC · 2009-02-06 11:16:51

Hey vEX

Looks like you changed the PKGBUILD depends to include 'tre' but this does not seem to resolve to anything in core or extra.

Is there an unsupported repo that has it, or do you know where to get it from? The letters 'tre' are generic and it's hard to find any info on it

[vEX] · 2009-02-06 16:08:38

'tre' is available in AUR just as XBMC. The list of dependencies are actually links, so you can click on 'tre' to get to the AUR page. However I'll just link it in here for convinience.

http://aur.archlinux.org/packages.php?ID=1659

[vEX] · 2009-02-08 11:15:38

gorus wrote:

very very nice [vEX] did you hear anything about xbmc and libtool problems / solutions ?

xbmc 8.10-9 should take care of the few broken libtool problems. I simply replace the ltmain.sh scripts that generate the libtool files with the one supplied with libtool installed by Arch.

Arch Linux

#1 2009-01-22 22:12:32

XBMC 'realloc not defined'

#2 2009-01-23 16:50:27

Re: XBMC 'realloc not defined'

#3 2009-01-23 17:21:38

Re: XBMC 'realloc not defined'

#4 2009-01-23 17:50:43

Re: XBMC 'realloc not defined'

#5 2009-01-23 20:08:24

Re: XBMC 'realloc not defined'

#6 2009-01-23 20:27:24

Re: XBMC 'realloc not defined'

#7 2009-01-23 20:56:48

Re: XBMC 'realloc not defined'

#8 2009-01-23 21:55:35

Re: XBMC 'realloc not defined'

#9 2009-01-23 22:30:36

Re: XBMC 'realloc not defined'

#10 2009-01-23 23:48:02

Re: XBMC 'realloc not defined'

#11 2009-01-24 02:00:08

Re: XBMC 'realloc not defined'

#12 2009-01-24 15:03:21

Re: XBMC 'realloc not defined'

#13 2009-01-25 09:40:44

Re: XBMC 'realloc not defined'

#14 2009-01-25 13:08:42

Re: XBMC 'realloc not defined'

#15 2009-01-25 15:30:55

Re: XBMC 'realloc not defined'

#16 2009-01-25 20:45:32

Re: XBMC 'realloc not defined'

#17 2009-01-26 19:55:36

Re: XBMC 'realloc not defined'

#18 2009-01-30 19:42:24

Re: XBMC 'realloc not defined'

#19 2009-01-31 14:39:12

Re: XBMC 'realloc not defined'

#20 2009-01-31 15:48:39

Re: XBMC 'realloc not defined'

#21 2009-02-06 11:16:51

Re: XBMC 'realloc not defined'

#22 2009-02-06 16:08:38

Re: XBMC 'realloc not defined'

#23 2009-02-08 11:15:38

Re: XBMC 'realloc not defined'

Board footer