[Buildroot] Various problem using buildroot-2012.05

[Buildroot] Various problem using buildroot-2012.05

[Ming-Ching Tiew]

--- On Mon, 6/18/12, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Subject: Re: [Buildroot] Various problem using buildroot-2012.05
> To: buildroot at busybox.net
> Date: Monday, June 18, 2012, 6:45 AM
> Le Sun, 17 Jun 2012 20:35:15 -0700
> (PDT),
> Ming-Ching Tiew <mctiew@yahoo.com>
> a ?crit :
> 
> > I encountered various problems using buildroot-2012.05,
> all to do
> > with using buildroot as a chroot build environment.
> 
> Why would you do this?
> 

Because there are many packages are not made to compile in a cross environment. For many, it's not a trial task to adapt those packages for cross compiling. 

[Buildroot] Various problem using buildroot-2012.05

[Thomas Petazzoni]

Le Mon, 18 Jun 2012 00:46:05 -0700 (PDT),
Ming-Ching Tiew <mctiew@yahoo.com> a ?crit :

> Because there are many packages are not made to compile in a cross
> environment. For many, it's not a trial task to adapt those packages
> for cross compiling. 

Which packages are you talking about? If there are of general interest,
some people might be interested in helping to get them to cross-compile.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Various problem using buildroot-2012.05

[Bernd Kuhls]

Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
@public.gmane.org> wrote in news:20120618103657.721db39b at skate:

> Le Mon, 18 Jun 2012 00:46:05 -0700 (PDT),
> Ming-Ching Tiew <mctiew@yahoo.com> a ??crit :
>> Because there are many packages are not made to compile in a cross
>> environment. For many, it's not a trial task to adapt those packages
>> for cross compiling. 
> Which packages are you talking about? If there are of general interest,
> some people might be interested in helping to get them to cross-compile.

Hi,

in my case it?s Perl, along with Spamassassin to be build on-top of it. The 
current effort to cross-compile Perl is problematic in regard to cross-
compile CPAN modules, so now I am trying to compile Perl on the target 
machine using a buildroot-made gcc_target toolchain along with some 
dependency libs.

Kind regards, Bernd

[Buildroot] Various problem using buildroot-2012.05

[Stefan Fröberg]

Hi Bernd

10.11.2012 16:28, Bernd Kuhls kirjoitti:
> Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
> @public.gmane.org> wrote in news:20120618103657.721db39b at skate:
>
>> Le Mon, 18 Jun 2012 00:46:05 -0700 (PDT),
>> Ming-Ching Tiew <mctiew@yahoo.com> a ??crit :
>>> Because there are many packages are not made to compile in a cross
>>> environment. For many, it's not a trial task to adapt those packages
>>> for cross compiling. 
>> Which packages are you talking about? If there are of general interest,
>> some people might be interested in helping to get them to cross-compile.
> Hi,
>
> in my case it?s Perl, along with Spamassassin to be build on-top of it. The 
> current effort to cross-compile Perl is problematic in regard to cross-
> compile CPAN modules, so now I am trying to compile Perl on the target 
> machine using a buildroot-made gcc_target toolchain along with some 
> dependency libs.

Yes, Perl is a (as you can see from various patches and problems related
to perl in this mailing list) is a really
major PITA to cross-compile.

If you try to use buildroot-made target gcc to compile perl, that is,
you use buildroot to cross-compile gcc to run natively inside
uClibc (?) environment, then you might encounter problems.

As Thomas has said in few times here for people telling about problems
of native gcc-toolchain, buildroot is about cross-compiling stuff
and buildroot produced native gcc-toolchain is really not supported and
might be still broken
(I don't know what the current status of it is now).

I remember that I promised to Thomas to investigate the native gcc for
x86 (under uClibc) thing and the only solution I have so far
managed to cook is by making a completely self-sustaining, buildroot
independent environment with working perl 5.16, python 2.7,
gcc 4.7, binutils 2.22 and lot's of other stuff. I decided to use RPM
for package management and spend healthy amount of three
weekends of studying how to make RPMs.

Maybe, when I have more time, I will compare my working native uClibc
gcc-toolchain and buildroot produced native uClibc gcc-toolchain
and cook some patches.

In case that buildroot produced native toolchain won't work, I will be
happy to send you my native uClibc-based gcc-toolchain
that you can chroot into, and see if that is of any help.

Mind you that it's still in beta-phase...

Best Regards
Stefan

> Kind regards, Bernd
>
>
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121110/080ae49e/attachment.html>

[Buildroot] Various problem using buildroot-2012.05

[Bernd Kuhls]

Hi,

Stefan Fr?berg <stefan.froberg@petroprogram.com>
wrote in news:509E69FD.2000804 at petroprogram.com: 

> If you try to use buildroot-made target gcc to compile perl, that is,
> you use buildroot to cross-compile gcc to run natively inside
> uClibc (?) environment, then you might encounter problems.

yes, I am trying exactly that with uClibc. I copied the buildroot-created 
toolchain along with some needed cross-compiled libs (z, openssl, db, ...) 
to my target and could successfully compile perl:


fli4l 3.9.0-rev24280 # perl -V
Summary of my perl5 (revision 5 version 16 subversion 2) configuration:

  Platform:
    osname=linux, osvers=3.6.6-nonfree, archname=i686-linux
    uname='linux fli4l 3.6.6-nonfree #1 smp tue nov 6 16:59:31 cet 2012 
i686 gnulinux '
    config_args='-des -Dprefix=/usr -Duseshrplib -Dusedl -
Ddlsrc=dl_dlopen.xs -Duselargefiles -Accflags=-fno-stack-protector -
Dperllibs=-ldl -lm -Dlibs=-ldl -lm -Dpager=/usr/bin/less -d'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-fno-stack-protector -fno-strict-aliasing -pipe -
D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2',
    cppflags='-fno-stack-protector -fno-strict-aliasing -pipe'
    ccversion='', gccversion='4.6.3', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =''
    libpth=/lib /usr/lib
    libs=-ldl -lm
    perllibs=-ldl -lm
    libc=/lib/libc.so.0, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-
rpath,/usr/lib/perl5/5.16.2/i686-linux/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -O2'


Characteristics of this binary (from libperl):
  Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
                        PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_LARGE_FILES
                        USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE
                        USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
  Built under linux
  Compiled at Nov 10 2012 15:51:03
  @INC:
    /usr/lib/perl5/site_perl/5.16.2/i686-linux
    /usr/lib/perl5/site_perl/5.16.2
    /usr/lib/perl5/5.16.2/i686-linux
    /usr/lib/perl5/5.16.2


Keep up the fine work with buildroot!

Kind regards, Bernd

[Buildroot] Various problem using buildroot-2012.05

[Arnout Vandecappelle]

On 11/10/12 15:51, Stefan Fr?berg wrote:
>
> If you try to use buildroot-made target gcc to compile perl, that is, you use buildroot to cross-compile gcc to run
> natively inside
> uClibc (?) environment, then you might encounter problems.
>
> As Thomas has said in few times here for people telling about problems of native gcc-toolchain, buildroot is about
> cross-compiling stuff
> and buildroot produced native gcc-toolchain is really not supported and might be still broken
> (I don't know what the current status of it is now).

  The current status is: we're going to remove it.  Thomas has just posted some
patches to do that.

  The idea is: if you need a toolchain on the target, there is no reason not to
use a normal distro: debian, ubuntu, gentoo, ....


  As for perl, however, I think we really would like to be able to cross-compile
perl modules.  But that unfortunately still needs some work.  I messed about
with it for a bit, but I can't say I really understand how the perl build system
works.


  Regards,
  Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Various problem using buildroot-2012.05

[Stefan Fröberg]

12.11.2012 0:47, Arnout Vandecappelle kirjoitti:
> On 11/10/12 15:51, Stefan Fr?berg wrote:
>>
>> If you try to use buildroot-made target gcc to compile perl, that is,
>> you use buildroot to cross-compile gcc to run
>> natively inside
>> uClibc (?) environment, then you might encounter problems.
>>
>> As Thomas has said in few times here for people telling about
>> problems of native gcc-toolchain, buildroot is about
>> cross-compiling stuff
>> and buildroot produced native gcc-toolchain is really not supported
>> and might be still broken
>> (I don't know what the current status of it is now).
>
>  The current status is: we're going to remove it.  Thomas has just
> posted some
> patches to do that.
>

Awww...
Well, it's good that he mentioned it at this point, before I started
doing any real work with that native toolchain.


>  The idea is: if you need a toolchain on the target, there is no
> reason not to
> use a normal distro: debian, ubuntu, gentoo, ....
>
>
>  As for perl, however, I think we really would like to be able to
> cross-compile
> perl modules.  But that unfortunately still needs some work.  I messed
> about
> with it for a bit, but I can't say I really understand how the perl
> build system
> works.
>

Yeah.

Another "little" difficult case is Python.

Even tought Python uses autotools, it (and Perl) will always be the
worst cross-compile
friendly citizens in my book.
Way back, before buildroot, I tried many times to cross-compile it in
Mingw32 environment and it was an
absolute nightmare. With Perl I had even less luck.

Every time I find an interesting open source project that I would like
to try and cross-compile,
I will make an silent prayer to God's of programmers that the build
system that is revealed from
tarball will be a GNU autoconf script (or even cmake one for God's sake)
and not
some hodge-bodge, custom made, configuration nightmare.

Regards
Stefan

>
>  Regards,
>  Arnout
>

[Buildroot] Various problem using buildroot-2012.05

[Thomas Petazzoni]

Stefan,

On Mon, 12 Nov 2012 02:04:57 +0200, Stefan Fr?berg wrote:

> Another "little" difficult case is Python.
> 
> Even tought Python uses autotools, it (and Perl) will always be the
> worst cross-compile
> friendly citizens in my book.
> Way back, before buildroot, I tried many times to cross-compile it in
> Mingw32 environment and it was an
> absolute nightmare. With Perl I had even less luck.

So far, Python has been relatively manageable and what have a bunch of
Python modules that work.

> Every time I find an interesting open source project that I would like
> to try and cross-compile,
> I will make an silent prayer to God's of programmers that the build
> system that is revealed from
> tarball will be a GNU autoconf script (or even cmake one for God's
> sake) and not
> some hodge-bodge, custom made, configuration nightmare.

I agree that custom made build systems are a pain. However, from my
(possibly naive and idealist) perspective, the right solution to these
is to fix them rather than workarounding the problem using native
compilation on the target.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Various problem using buildroot-2012.05

[Ming-Ching Tiew]

I encountered various problems using buildroot-2012.05, all to do with using buildroot as a chroot build environment.

1. Seem "Copying development files to target did not copy libc.so.

   Seems this was reported sometime ago, a fix was provided but somehow it's not propagated to support/scripts/copy.sh.

   The fix is to add this line to copy.sh

 cp -af $(STAGING_DIR)/usr/lib/libc.so $(TARGET_DIR)/usr/lib

2. I wrote a test program in the chroot environment, 

#include <stdio.h>
#include <dlfcn.h>
#include <stdlib.h>

int main(int argc, char **argv) 
{
   void *lib_handle;
   double (*fn)(int *);
   int x;
   char *error;

   lib_handle = dlopen("libctest.so", RTLD_NOW);
   if (!lib_handle) 
   {
      fprintf(stderr, "1: RTLD_NOW: %s\n", dlerror());
      exit(1);
   }
   return 0;
}

    # cc -rdynamic  mytest.c -ldl
/usr/lib/gcc/i686-unknown-linux-uclibc/4.6.3/../../../libdl.a(libdl.os): In function `_dl_find_hash':
libdl.c:(.text+0x9fa): undefined reference to `_dl_allocate_static_tls'
libdl.c:(.text+0xa1a): undefined reference to `_dl_allocate_static_tls'
/usr/lib/gcc/i686-unknown-linux-uclibc/4.6.3/../../../libdl.a(libdl.os): In function `_dl_load_elf_shared_library':
libdl.c:(.text+0x1e51): undefined reference to `_dl_next_tls_modid'
/usr/lib/gcc/i686-unknown-linux-uclibc/4.6.3/../../../../i686-unknown-linux-uclibc/bin/ld: a.out: hidden symbol `_dl_allocate_static_tls' isn't defined
/usr/lib/gcc/i686-unknown-linux-uclibc/4.6.3/../../../../i686-unknown-linux-uclibc/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

Is there any other libraries which are missing also in the coying ?

 

[Buildroot] Various problem using buildroot-2012.05

[Ming-Ching Tiew]

--- On Mon, 6/18/12, Ming-Ching Tiew <mctiew@yahoo.com> wrote:

> 
> I encountered various problems using buildroot-2012.05, all
> to do with using buildroot as a chroot build environment.
> to do with using buildroot as a chroot build environment.
> 
> 1. Seem "Copying development files to target did not copy
> libc.so.
> 
> ???Seems this was reported sometime ago, a
> fix was provided but somehow it's not propagated to
> support/scripts/copy.sh.
> 
> ???The fix is to add this line to copy.sh
> 
>  cp -af $(STAGING_DIR)/usr/lib/libc.so
> $(TARGET_DIR)/usr/lib
> 
> 2. I wrote a test program in the chroot environment, 
> 
> #include <stdio.h>
> #include <dlfcn.h>
> #include <stdlib.h>
> 
> int main(int argc, char **argv) 
> {
> ???void *lib_handle;
> ???double (*fn)(int *);
> ???int x;
> ???char *error;
> 
> ???lib_handle = dlopen("libctest.so",
> RTLD_NOW);
> ???if (!lib_handle) 
> ???{
> ? ? ? fprintf(stderr, "1: RTLD_NOW: %s\n",
> dlerror());
> ? ? ? exit(1);
> ???}
> ???return 0;
> }
> 
> ? ? # cc -rdynamic? mytest.c -ldl
> /usr/lib/gcc/i686-unknown-linux-uclibc/4.6.3/../../../libdl.a(libdl.os):
> In function `_dl_find_hash':
> libdl.c:(.text+0x9fa): undefined reference to
> `_dl_allocate_static_tls'
> libdl.c:(.text+0xa1a): undefined reference to
> `_dl_allocate_static_tls'
> /usr/lib/gcc/i686-unknown-linux-uclibc/4.6.3/../../../libdl.a(libdl.os):
> In function `_dl_load_elf_shared_library':
> libdl.c:(.text+0x1e51): undefined reference to
> `_dl_next_tls_modid'
> /usr/lib/gcc/i686-unknown-linux-uclibc/4.6.3/../../../../i686-unknown-linux-uclibc/bin/ld:
> a.out: hidden symbol `_dl_allocate_static_tls' isn't
> defined
> /usr/lib/gcc/i686-unknown-linux-uclibc/4.6.3/../../../../i686-unknown-linux-uclibc/bin/ld:
> final link failed: Bad value
> collect2: ld returned 1 exit status
> 
> Is there any other libraries which are missing also in the
> coying ?
> 

Fixed the problem by creating a symbolic link /usr/lib/libdl.so to link it to /lib/libdl.so.0.

[Buildroot] Various problem using buildroot-2012.05

[Thomas Petazzoni]

Le Sun, 17 Jun 2012 20:35:15 -0700 (PDT),
Ming-Ching Tiew <mctiew@yahoo.com> a ?crit :

> I encountered various problems using buildroot-2012.05, all to do
> with using buildroot as a chroot build environment.

Why would you do this?

Buildroot is here to cross-compile your libraries and applications, it
really doesn't make much sense to use it to generate a chrooted
environment in which you compile your applications. At least, that's
not how Buildroot developers/users typically use Buildroot, so it's an
area (using a native compiler on the target, with development files)
that doesn't receive a lot of attention, hence the problems you are
facing.

To the community: there seem to be an increasing number of people who
misunderstand how to use Buildroot properly. Should we simply get rid
of the "toolchain on target" option? Should we write a FAQ question
about this? Generally speaking, I don't think Buildroot is the good
tool to build a full-featured system that includes a compiler and all
related development tools to build stuff on the target. What do others
think about this?

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com