From: Sasha Sirotkin <buildroot@browserseal.com>
To: buildroot@busybox.net
Subject: [Buildroot] init segfaults when compiled with glibc
Date: Tue, 30 Mar 2010 23:03:55 +0300 [thread overview]
Message-ID: <4BB2592B.4080502@browserseal.com> (raw)
On Tue, Mar 30, 2010 at 7:58 PM, Yann E. MORIN
<yann.morin.1998@anciens.enib.fr> wrote:
Sasha, All,
On Tuesday 30 March 2010 16:26:14 Sasha Sirotkin wrote:
> On Tue, Mar 30, 2010 at 4:20 PM, Yann E. MORIN
> <yann.morin.1998 at anciens.enib.fr
<mailto:yann.morin.1998@anciens.enib.fr>> wrote:
> On Tuesday 30 March 2010 142701 Sasha Sirotkin wrote:
> > I compiled an external toolchain with glibc support using
> crosstools-ng
> > as recommended. I managed to compile buildroot without any
issues.
> > However, when I try to use the resulting image /sbin/init
segfaults.
Standard init, or busybox' ?
> > With uclibc there are no such issues. I'm using the latest
> versions of
> > everything on ARM with EABI.
In crosstool-NG, there's a sample that is quite up-to-date and that
builds
an arm-unknown-linux-gnueabi:
# ct-ng show-arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabi [l ]
OS : linux-2.6.31.12
Companion libs : gmp-4.3.1 mpfr-2.4.2 libelf-0.8.12
binutils : binutils-2.19.1
C compiler : gcc-4.3.2 (C,C++,Fortran,Java)
C library : glibc-2.9
Tools : sstrip dmalloc-5.5.2 duma-2_5_15 gdb-6.8
ltrace-0.5.3 strace-4.5.19
> By default, gcc will emit armv5t instructions. What's your
target CPU?
> init segfaulting can be a symptom of using a bad instruction
set, so if
> your CPU is armv4, and you did not tell gcc to default to
armv4, then
> you will hit this segfault issue.
> As I already mentioned, it works fine with uClibc, so it is
definitely
> not a CPU instructions issue. At any rate, my CPU is AT91, i.e.
armvte
> instruction set.
Ahem. Right, sorry.
I'll read you back on crossgcc... :-)
It happens with both busybox and standard init.
Compilation of crossgcc with EABI work OK, but than I got this
segmentation fault issue...
It looks like glibc does not work at all with buildroot right now.
Should I open a bug ticket or something?
next reply other threads:[~2010-03-30 20:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-30 20:03 Sasha Sirotkin [this message]
2010-03-30 20:34 ` [Buildroot] init segfaults when compiled with glibc Thomas Petazzoni
-- strict thread matches above, loose matches on Subject: below --
2010-03-31 10:47 Sasha Sirotkin
2010-03-31 18:52 ` Thomas Petazzoni
2010-03-31 20:05 ` Alexander Sirotkin
2010-03-30 14:26 Sasha Sirotkin
2010-03-30 16:58 ` Yann E. MORIN
2010-03-30 22:20 ` Eric BENARD
2010-03-31 14:18 ` Alexander Sirotkin
2010-03-31 14:37 ` Javier Viguera
2010-03-31 15:48 ` Alexander Sirotkin
2010-03-31 18:11 ` Peter Korsgaard
2010-03-31 18:28 ` Sasha Sirotkin
2010-03-31 18:58 ` H Hartley Sweeten
2010-03-31 19:02 ` Sasha Sirotkin
2010-03-31 19:16 ` Thomas Petazzoni
2010-03-31 20:21 ` Alexander Sirotkin
2010-04-01 7:48 ` Alexander Sirotkin
2010-03-30 12:27 Sasha Sirotkin
2010-03-30 13:20 ` Yann E. MORIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BB2592B.4080502@browserseal.com \
--to=buildroot@browserseal.com \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.