From: Michael S. Zick <minimod@morethan.org>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] Static build changes
Date: Mon, 9 Jan 2012 11:17:05 -0600 [thread overview]
Message-ID: <201201091117.07744.minimod@morethan.org> (raw)
In-Reply-To: <20120109090404.74b2733b@skate>
On Mon January 9 2012, Thomas Petazzoni wrote:
> Hello,
>
> Le Tue, 20 Dec 2011 16:11:54 +0000,
> ANDY KENNEDY <ANDY.KENNEDY@adtran.com> a ?crit :
>
> > In the system I am building, we want to use all static applications in
> > place of using eglibc for the target. I prefer to use uClibC for
> > busybox, and the applications you see above. To prevent from having
> > dynamically linked applications, without having installed libraries, I
> > have modified these to either not install the application (in the case
> > of uClibC installing ldconfig, libgcrypt installing iconv, etc), or
> > build the target binary static. In the case of a couple of libraries,
> > the install was modified to prevent the libraries from being installed
> > to the target when all that is needed is for another application being
> > installed.
>
> Many of the modifications to the various packages look very similar.
> Isn't it possible to factorize those needed flags and options at the
> package infrastructure level somehow?
>
> The modifications that I see are:
>
> * Adding -static to the LDFLAGS
>
> * Adding --enable-static --disable-shared in the configuration options
> for autotools packages, which I think is useless because it's
> already done at the end of package/Makefile.in
>
> * Using _INSTALL_TARGET=NO for libraries. This shouldn't be needed: if
> the shared variant is not built, the static variant will be
> installed on the target, then removed by target-finalize
>
> For sure, there will probably be things that remain at the individual
> package level, but I'd like to see some reflection on what needs to be
> factorized at the package infrastructure level, especially for
> autotools packages that have a relatively well standardized behaviour.
>
Probably need to include provisions for -static-libgcc and -static-libstdc++
also to control the selection of how the compiler generated stuff is loaded.
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
Mike
> Regards,
>
> Thomas
prev parent reply other threads:[~2012-01-09 17:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-20 16:11 [Buildroot] [PATCH] Static build changes ANDY KENNEDY
2012-01-09 7:12 ` Arnout Vandecappelle
2012-01-09 20:45 ` ANDY KENNEDY
2012-01-11 7:01 ` Arnout Vandecappelle
2012-01-11 16:23 ` ANDY KENNEDY
2012-01-12 11:08 ` Arnout Vandecappelle
2012-01-09 8:04 ` Thomas Petazzoni
2012-01-09 17:17 ` Michael S. Zick [this message]
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=201201091117.07744.minimod@morethan.org \
--to=minimod@morethan.org \
--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