Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Generating external toolchains with Buildroot
Date: Tue, 28 Aug 2012 14:12:02 +0200	[thread overview]
Message-ID: <20120828141202.60da849d@skate> (raw)
In-Reply-To: <503C7508.8030905@mind.be>

Le Tue, 28 Aug 2012 09:36:40 +0200,
Arnout Vandecappelle <arnout@mind.be> a ?crit :

> > Problem 1: everything is in usr/
> > ================================
> >
> [snip]
> >
> > Question: should we be changing our host directory policy and use
> > --prefix=$(HOST_DIR) instead of --prefix=$(HOST_DIR)/usr ? Or
> > should we keep things as it is and leave with this little drawback ?
> 
>   Yes!  I've always been annoyed with the redundant usr part,
> especially since two or three packages install in $(HOST_DIR)/bin...

Ah, really? Which ones?

>   It's a big change but can probably easily be automated with sed.

Well, most of the host packages are probably using the
host-autotools-package infrastructure, so those are easy to change:
only one place. Of course, all the host-generic-package would need
manual intervention.

Peter, what's your feeling about this?

> > For the toolchains that I've put online at
> > http://autobuild.buildroot.org/toolchains/tarballs/, I've solved
> > this problem by modifying Buildroot so that it builds mpfr, gmp and
> > mpc as static libraries, so that the gcc binaries do not depend to
> > any shared libraries besides the C library. And this seems to work
> > fine, though it is not a completely satisfying solution.
> 
>   I'm not sure if linking mpfr, gmp and mpc statically is so bad...

No, it's not so bad. It's just that from a "beauty" point of view, I
would have preferred to be able to link dynamically against them. Just
because we _should_ be able to do it :-)

> How much larger do the binaries become with static linking?  If it's
> not much larger, the startup of cc1 may actually become faster with
> static linking!
> 
>   Quick comparison: buildroot-built cc1 for gcc-4.5.3 is 11M;
> statically-linked cc1 from Sourcery's gcc-4.5.2 is 12M.

Yes, the impact is not that significant, you're right.

>   I think crosstool-NG links statically as well.  Yann?

Yes, crosstool-NG links statically.

> > Any ideas on this one? Should we add both -Wl,-rpath,$ORIGIN/../lib
> > and -Wl,-rpath,$ORIGIN/../../../../lib when building gcc to solve
> > this problem? Another solution?
> 
>   Not very nice.  Perhaps a specific rpath for linking cc1 and
> friends?

That means diving into the internal gcc build process. You, crazy
guy? :-)

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

  reply	other threads:[~2012-08-28 12:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-25  9:30 [Buildroot] Generating external toolchains with Buildroot Thomas Petazzoni
2012-08-28  7:36 ` Arnout Vandecappelle
2012-08-28 12:12   ` Thomas Petazzoni [this message]
2012-08-28 10:30 ` Kevin Chadwick

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=20120828141202.60da849d@skate \
    --to=thomas.petazzoni@free-electrons.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