All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 3 of 4 RFC] manual: add section about depending on toolchain options
Date: Wed, 18 Sep 2013 19:40:42 +0200	[thread overview]
Message-ID: <20130918194042.302e9afe@skate> (raw)
In-Reply-To: <CAAXf6LWmH2xtBe_P-P+1HJhndDM1BhHZcgJzu9o7JrfwjtwWVg@mail.gmail.com>

Dear Thomas De Schampheleire,

On Wed, 18 Sep 2013 19:30:11 +0200, Thomas De Schampheleire wrote:

> Currently there is one option PREFER_STATIC_LIB, with help text:
>           Where possible, build and use static libraries for the
> target.
>           This potentially increases your code size and should only be
>           used if you know what you do.
>           The default is to build dynamic libraries and use those on
>           the target filesystem.
> 
> However, my interpretation of the current usage of this symbol is that
> it is not PREFER_STATIC_LIB, but rather something like
> STATIC_LIB_ONLY. Because some packages are simply not available when
> this is set, instead of building the package with dynamic linking.
> 
> The current name PREFER_STATIC_LIB is also unfortunate in the case
> that dynamic linking is not available because the target does not
> support it, e.g. because of no MMU (thanks for mentioning this, I
> wasn't aware). A name STATIC_LIB_ONLY would also match better here.
> 
> Note that I'm not necessarily requesting we rename the symbol, but I
> find the current situation confusing.
> 
> Maybe we need an extra symbol, ARCH_NEEDS_STATIC_LIB or similar (or
> re-use a possible new !ARCH_HAS_MMU) in addition to a user choice
> PREFER_STATIC_LIB. When a package cannot be linked statically, we only
> check on ARCH_NEEDS_STATIC_LIB. If ARCH_NEEDS_STATIC_LIB is false, and
> PREFER_STATIC_LIB is true, then we build the package dynamically.

The situation definitely needs to be clarified. We have gradually
changed the semantic of BR2_PREFER_STATIC_LIB from "prefer static
libraries" (which doesn't make any sense: you were getting static
libraries for some packages, dynamic for some others) to "use only
static libraries".

Best regards,

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

  reply	other threads:[~2013-09-18 17:40 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-18  9:01 [Buildroot] [PATCH 0 of 4 RFC] Unification of comments on toolchain option dependencies Thomas De Schampheleire
2013-09-18  9:01 ` [Buildroot] [PATCH 1 of 4 RFC] trivial: manual: fix grammar of 'to express' Thomas De Schampheleire
2013-09-18 14:33   ` Peter Korsgaard
2013-09-18  9:01 ` [Buildroot] [PATCH 2 of 4 RFC] trivial: manual: multimedia is no longer a subdirectory Thomas De Schampheleire
2013-09-18 14:33   ` Peter Korsgaard
2013-09-18  9:01 ` [Buildroot] [PATCH 3 of 4 RFC] manual: add section about depending on toolchain options Thomas De Schampheleire
2013-09-18 11:15   ` Thomas De Schampheleire
2013-09-18 14:34     ` Peter Korsgaard
2013-09-18 16:34     ` Thomas Petazzoni
2013-09-18 17:30       ` Thomas De Schampheleire
2013-09-18 17:40         ` Thomas Petazzoni [this message]
2013-09-18 17:46           ` Gustavo Zacarias
2013-09-18 17:59             ` Thomas Petazzoni
2013-09-18 18:05               ` Gustavo Zacarias
2013-09-18 18:18                 ` Thomas Petazzoni
2013-09-18 21:57                   ` Arnout Vandecappelle
2013-09-19  4:10                     ` Thomas Petazzoni
2013-09-19 19:06                       ` Arnout Vandecappelle
2013-09-18 22:06   ` Arnout Vandecappelle
2013-09-19  7:23     ` Thomas De Schampheleire
2013-09-19 14:52       ` Thomas Petazzoni
2013-09-19 19:07       ` Arnout Vandecappelle
2013-09-18  9:01 ` [Buildroot] [PATCH 4 of 4 RFC] Config.in files: unify comments of toolchain option dependencies Thomas De Schampheleire
2013-09-19 10:57   ` Thomas De Schampheleire
2013-09-19 11:47     ` Samuel Martin
2013-09-19 14:54       ` Thomas Petazzoni

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=20130918194042.302e9afe@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.