[Buildroot] Build Fails with ruby-1.9.2-p0

[Buildroot] Build Fails with ruby-1.9.2-p0

[Christopher Boumenot]

I am trying to create a minimal x86 root image that includes ruby-1.9.2-p0,
but the build fails when compiling ruby.

/home/boumenot/src/buildroot-2011.05/output/build/ruby-1.9.2-p0/lib/mkmf.rb:365:in
`try_do': The complier failed to generate an executable file. (RuntimeError)
You have to install development tools first.
        from
/home/boumenot/src/buildroot-2011.05/output/build/ruby-1.9.2-p0/lib/mkmf.rb:446:in
`try_compile'
        from
/home/boumenot/src/buildroot-2011.05/output/build/ruby-1.9.2-p0/lib/mkmf.rb:496:in
`try_static_assert'
        from ../.././ext/bigdecimal/extconf.rb:5
        from ./ext/extmk.rb:156:in `load'
        from ./ext/extmk.rb:156:in `extmake'
        from ./ext/extmk.rb:445
        from ./ext/extmk.rb:441:in `each'
        from ./ext/extmk.rb:441
make: *** [mkmain.sh] Error 1

Here's the code that the ruby build process was trying to build.

boumenot at linux-5fgv:~/src/buildroot-2011.05/output/build/ruby-1.9.2-p0/ext/bigdecimal>
cat mkmf.log
"/home/boumenot/src/buildroot-2011.05/output/host/usr/bin/ccache
/home/boumenot/src/buildroot-2011.05/output/host/usr/bin/i686-unknown-linux-uclibc-gcc
-o conftest -I../../.ext/include/i686-linux -I../.././include
-I../.././ext/bigdecimal    -pipe -Os  conftest.c  -L. -L../.. -L.
 -rdynamic -Wl,-export-dynamic     -Wl,-R -Wl,/usr/lib -L/usr/lib
-lruby-static  -lpthread -lrt -ldl -lcrypt -lm   -lc"
/home/boumenot/src/buildroot-2011.05/output/host/usr/i686-unknown-linux-uclibc/sysroot/usr/lib/crt1.o:
In function `_start':
(.text+0x1d): undefined reference to `__uClibc_main'
collect2: ld returned 1 exit status
checked program was:
/* begin */
1: #include "ruby.h"
2:
3: int main() {return 0;}
/* end */

This is against buildroot-2011.05.  I am building on OpenSuSE v11.4
x86_64 targeting x86.  I am using the default toolchain values for this
version of buildroot.  I am not sure what other information would help.

GCC is 4.3.5.

These are the data for .config and .defconfig files.

BR2_TARGET_ROOTFS_SQUASHFS=y
BR2_TARGET_ROOTFS_SQUASHFS4=y
BR2_TARGET_ROOTFS_SQUASHFS4_XZ=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_2_6_38=y
BR2_LINUX_KERNEL_VERSION="2.6.38.7"
BR2_LINUX_KERNEL_PATCH=""
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="/usr/src/linux-2.6.38.7/.config"
BR2_LINUX_KERNEL_BZIMAGE=y
BR2_HAVE_DOT_CONFIG=y
BR2_i386=y
BR2_x86_i686=y
BR2_ARCH="i686"
BR2_ENDIAN="LITTLE"
BR2_GCC_TARGET_TUNE="i686"
BR2_GCC_TARGET_ARCH="i686"

I would like to fix the issue and submit a patch, but I am not sure how or
what to fix.  Help is very much appreciated.


Thanks!
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110529/cfbbac1b/attachment.html>

[Buildroot] Build Fails with ruby-1.9.2-p0

[Christopher Boumenot]

I bisected from the last commit against the ruby package to tip, and it
appears that this commit broke the ruby build.  If I revert it on tip, it
builds just fine.


commit 7e3e8ec040b06d6e2fb69e55c004f1ebc02c76d0
Author: Peter Korsgaard <jacmet@sunsite.dk>
Date:   Fri Apr 29 15:40:58 2011 +0200

    package/Makefile.in: CFLAGS/LDFLAGS: don't add -I / -L args for
STAGING_DIR

    Now that we use sysroot for all toolchains, the explicit -I / -L
arguments
    in CFLAGS / LDFLAGS aren't needed anymore (And having them makes the
build
    quite noisy for certain packages as STAGING_DIR/include normally doesn't
    exist).

    Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>



Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110530/499ff35e/attachment.html>

[Buildroot] Build Fails with ruby-1.9.2-p0

[Peter Korsgaard]

>>>>> "Christopher" == Christopher Boumenot <boumenot@gmail.com> writes:

Hi,

 Christopher> I am trying to create a minimal x86 root image that
 Christopher> includes ruby-1.9.2-p0, but the build fails when compiling
 Christopher> ruby.

 Christopher> "/home/boumenot/src/buildroot-2011.05/output/host/usr/bin/ccache /home/boumenot
 Christopher> /src/buildroot-2011.05/output/host/usr/bin/i686-unknown-linux-uclibc-gcc -o
 Christopher> conftest -I../../.ext/include/i686-linux -I../.././include -I../.././ext/
 Christopher> bigdecimal ? ?-pipe -Os ?conftest.c ?-L. -L../.. -L. ?-rdynamic
 Christopher> -Wl,-export-dynamic ? ? -Wl,-R -Wl,/usr/lib -L/usr/lib -lruby-static ?-lpthread
 Christopher> -lrt -ldl -lcrypt -lm ? -lc"
 Christopher> /home/boumenot/src/buildroot-2011.05/output/host/usr/i686-unknown-linux-uclibc/
 Christopher> sysroot/usr/lib/crt1.o: In function `_start':
 Christopher> (.text+0x1d): undefined reference to `__uClibc_main'

So it ends up looking at your host libraries which leads to a linker
error.

 Christopher> This is against buildroot-2011.05. ?I am building on
 Christopher> OpenSuSE v11.4 x86_64?targeting?x86. ?I am using the
 Christopher> default toolchain values for this version of buildroot. ?I
 Christopher> am not sure what other information would help.

The entire .config would be good. I just tried on my Debian x86-64
system with the following defconfig (i586, default gcc version):

BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_PACKAGE_RUBY=y
BR2_PACKAGE_LIBGLIB2=y

Which works without problems.

-- 
Bye, Peter Korsgaard

[Buildroot] Build Fails with ruby-1.9.2-p0

[Peter Korsgaard]

>>>>> "Christopher" == Christopher Boumenot <boumenot@gmail.com> writes:

Hi,

 Christopher> I bisected from the last commit against the ruby package
 Christopher> to tip, and it appears that this commit broke the ruby
 Christopher> build. ?If I revert it on tip, it builds just fine.


 Christopher> commit 7e3e8ec040b06d6e2fb69e55c004f1ebc02c76d0
 Christopher> Author: Peter Korsgaard <jacmet@sunsite.dk>
 Christopher> Date: ? Fri Apr 29 15:40:58 2011 +0200

 Christopher> ? ? package/Makefile.in: CFLAGS/LDFLAGS: don't add -I / -L args for STAGING_DIR

Thanks, but the -I / -L flags probably just masked away the fact that
ruby was looking at your /usr/lib. The real fix is presumably to not let
it do so, but it would be easier to do so if I could reproduce your
build issue.

-- 
Bye, Peter Korsgaard