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] [PATCH] Static build changes
Date: Mon, 9 Jan 2012 09:04:04 +0100	[thread overview]
Message-ID: <20120109090404.74b2733b@skate> (raw)
In-Reply-To: <F9C551623D2CBB4C9488801D14F864C60E4498@ex-mb1.corp.adtran.com>

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.

Regards,

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

  parent reply	other threads:[~2012-01-09  8:04 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 [this message]
2012-01-09 17:17   ` Michael S. Zick

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=20120109090404.74b2733b@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