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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox