Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Nielsen <a.nielsen@shikadi.net>
To: buildroot@busybox.net
Subject: [Buildroot] initramfs doesn't get linked into kernel
Date: Sun, 05 May 2013 11:47:21 +1000	[thread overview]
Message-ID: <km4dn6$7ds$1@ger.gmane.org> (raw)
In-Reply-To: <20130504193618.729e01cb@skate>

>>    - In order to enable FLAT binaries, you need to disable MMU support in
>> uClibc.  Deselecting the buildroot option BR2_USE_MMU does not change the
>> uClibc option.  I am guessing this should happen automatically, but not quite
>> sure how to achieve it.
>
> Most likely should be done in toolchain/uClibc/uclibc.mk.

Ah yes, got this working, thanks.  As a side note, in buildroot itself, when 
BR2_HAS_MMU is *deselected* it should force BR2_ELF2FLT on.  I can't see how 
to do this (set BR2_ELF2FLT to be the inverse of BR2_HAS_MMU) unless I add a 
dummy option like this:

   config BR2_FORCE_ELF2FLT
     bool
     default y if !BR2_USE_MMU
     select BR2_ELF2FLT

Is this correct?  It's the only way I can come up with to select another 
option in response to an option being deselected.

>>    - Disabling MMU support in uClibc stops the thread components from
>> compiling.  Apparently this is a bug in uClibc? (something about fork() being
>> called vfork() instead)
>
> If uClibc doesn't build for a given configuration, it's definitely
> something that can be reported to the uClibc developers.

Thanks, I have submitted a bug for this with sample configuration files.

>>    - Disabling threads entirely in both uClibc and buildroot gets past that
>> previous problem, but gcc-final then does not compile as some components
>> (libitm and libatomic) need thread support.  I am not sure how to tell
>> buildroot to ask GCC to skip compiling libitm and libatomic when thread
>> support has been disabled.
>
> Hum, this is strange, because we do regularly test no-thread
> toolchains, but not for all gcc versions. Which gcc versions have you
> tried?

This is with GCC 4.8.0.  I was able to get around the problem by adding this 
to toolchain/gcc/gcc-uclibc-4.x.mk:

# Disable threading when thread implementation is 'none'
ifeq ($(BR2_PTHREADS_NONE),y)
EXTRA_GCC_CONFIG_OPTIONS += \
         --enable-threads=single \
         --disable-libitm \
         --disable-libatomic \
         --disable-libmudflap
endif

I'm not sure if this is the correct solution though given your comment about 
it being regularly tested.  If it is I'm happy to submit patches for this 
stuff if that's easier.

However it may be because disabling thread support in buildroot does not 
disable thread support in uClibc.  The two options must be set manually.  It 
could also be because I am compiling everything without MMU support, if that's 
not widely tested.

Thanks again,
Adam.

  reply	other threads:[~2013-05-05  1:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-26 23:37 [Buildroot] initramfs doesn't get linked into kernel Adam Nielsen
2013-04-27  1:17 ` Thomas Petazzoni
2013-04-27  9:53   ` Adam Nielsen
2013-04-27 17:34     ` Thomas Petazzoni
2013-04-27 22:50       ` Adam Nielsen
2013-05-04  0:29         ` Adam Nielsen
2013-05-04  8:25           ` Thomas Petazzoni
2013-05-04 11:35             ` Adam Nielsen
2013-05-04 17:36               ` Thomas Petazzoni
2013-05-05  1:47                 ` Adam Nielsen [this message]
2013-05-05  2:11                   ` Adam Nielsen

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='km4dn6$7ds$1@ger.gmane.org' \
    --to=a.nielsen@shikadi.net \
    --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