[Openembedded-users] can't install busybox

Pawel Osmialowski pawelo at dcclabs.tv
Sat Jun 18 23:13:01 UTC 2011


W dniu 09.06.2011 00:24, Pawel Osmialowski pisze:
> W dniu 09.06.2011 00:16, Khem Raj pisze:
>> On 06/05/2011 06:07 AM, Pawel Osmialowski wrote:
>>> libfakechroot.lo libfakechroot.c
>>> i686-linux-libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I..
>>> -isystem/home/pawelo/h3660/openembedded/h3660/tmp/sysroots/i686-linux/usr/include
>>>
>>> -isystem/home/pawelo/h3660/openembedded/h3
>>> 660/tmp/sysroots/i686-linux/usr/include -Os -MT libfakechroot.lo -MD -MP
>>> -MF .deps/libfakechroot.Tpo -c libfakechroot.c  -fPIC -DPIC -o
>>> .libs/libfakechroot.o
>>> libfakechroot.c:1975: error: conflicting types for 'scandir'
>>> /usr/include/dirent.h:252: note: previous declaration of 'scandir'
>>> was here
>>> libfakechroot.c:1987: error: conflicting types for 'scandir64'
>>> /usr/include/dirent.h:275: note: previous declaration of 'scandir64' was
>>> here
>>> make[2]: *** [libfakechroot.lo] Error 1
>>> make[2]: Leaving directory
>>> `/home/pawelo/h3660/openembedded/h3660/tmp/work/i686-linux/fakechroot-native-2.5-r1/fakechroot-2.5/src'
>>>
>>> make[1]: *** [all-recursive] Error 1
>>> make[1]: Leaving directory
>>> `/home/pawelo/h3660/openembedded/h3660/tmp/work/i686-linux/fakechroot-native-2.5-r1/fakechroot-2.5'
>>>
>>> make: *** [all] Error 2
>>> FATAL: oe_runmake failed
>>> ERROR: Function do_compile failed
>>>
>>> Can you give me any hints on this?
>> whats your host os ? it seems fakechroot is not liking the headers
>>
> It is 32-bit ubuntu karmic installed inside of debootstrap environment
> inside of huge 64-bit OpenSuse machine. It is certain that headers are
> taken from ubuntu karmic. I had to mount /proc and bind-mount /dev into
> it to have bitbake/OE working properly. I'm entering it by typing
> 'chroot karmic i386' so 'uname -m' prints 'i686'.
> So far I was using the same environment for sh4 and mipsel devices and
> despite the fact I was building somewhat huge distros for them,
> fakechroot-native wasn't picked for them. I guess it is because I was
> using ipk/opkg packaging for them. Now I want to have rpm's for this
> armle PDA and I guess this is the reason why fakechroot-native was picked.
>
>
I've tried the same on few other hosts with different distros and the
error is the same.
I've also found that fakechroot recipe applies fix-readlink.patch which
solves the same problem with readlink() function.
So I prepared similar patch for scandir() and scandir64():

diff -ruN fakechroot-2.5.old/src/libfakechroot.c
fakechroot-2.5/src/libfakechroot.c
--- fakechroot-2.5.old/src/libfakechroot.c      2005-10-24
12:09:57.000000000 +0200
+++ fakechroot-2.5/src/libfakechroot.c  2011-06-18 23:22:20.173122104 +0200
@@ -610,10 +610,10 @@
 #endif
     nextsym(rmdir, "rmdir");
 #ifdef HAVE_SCANDIR
-    nextsym(scandir, "scandir");
+    nextsym(scandir, "own_scandir");
 #endif
 #ifdef HAVE_SCANDIR64
-    nextsym(scandir64, "scandir64");
+    nextsym(scandir64, "own_scandir64");
 #endif
 #ifdef HAVE_SETXATTR
     nextsym(setxattr, "setxattr");
@@ -1972,7 +1972,7 @@

 #ifdef HAVE_SCANDIR
 /* #include <dirent.h> */
-int scandir (const char *dir, struct dirent ***namelist,
SCANDIR_TYPE_ARG3, int(*compar)(const void *, const void *))
+int own_scandir (const char *dir, struct dirent ***namelist,
SCANDIR_TYPE_ARG3, int(*compar)(const void *, const void *))
 {
     char *fakechroot_path, *fakechroot_ptr,
fakechroot_buf[FAKECHROOT_MAXPATH];
     expand_chroot_path(dir, fakechroot_path, fakechroot_ptr,
fakechroot_buf);
@@ -1984,7 +1984,7 @@

 #ifdef HAVE_SCANDIR64
 /* #include <dirent.h> */
-int scandir64 (const char *dir, struct dirent64 ***namelist,
int(*filter)(const struct dirent64 *), int(*compar)(const void *, const
void *))
+int own_scandir64 (const char *dir, struct dirent64 ***namelist,
int(*filter)(const struct dirent64 *), int(*compar)(const void *, const
void *))
 {
     char *fakechroot_path, *fakechroot_ptr,
fakechroot_buf[FAKECHROOT_MAXPATH];
     expand_chroot_path(dir, fakechroot_path, fakechroot_ptr,
fakechroot_buf);

...and it worked. So I guess it is worth to add this patch to OE mainstream.

Paul





More information about the Openembedded-users mailing list