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
next prev parent 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