All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Gregor Jasny <gjasny@googlemail.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>, linux-media@vger.kernel.org
Subject: Re: [v4l-utils PATCH 2/2] Add --with-static-binaries option to link binaries statically
Date: Mon, 26 Sep 2016 15:02:53 -0300	[thread overview]
Message-ID: <20160926150253.558e0693@vento.lan> (raw)
In-Reply-To: <efd3b769-3079-c164-e948-d9ce8b1d6e10@googlemail.com>

Em Mon, 26 Sep 2016 19:41:39 +0200
Gregor Jasny <gjasny@googlemail.com> escreveu:

> On 19/09/2016 16:21, Mauro Carvalho Chehab wrote:
> > Em Mon, 19 Sep 2016 16:22:30 +0300
> > Sakari Ailus <sakari.ailus@linux.intel.com> escreveu:
> >   
> >> Add a new variable STATIC_LDFLAGS to add the linker flags required for
> >> static linking for each binary built.
> >>
> >> Static and dynamic libraries are built by default but the binaries are
> >> otherwise linked dynamically. --with-static-binaries requires that static
> >> libraries are built.
> >>  
> > Instead of adding STATIC_LDFLAGS to all LDFLAGS, wouldn't be better to
> > add the flags to LDFLAGS on configure.ac?  
> 
> I don't really like adding all those build variants into the configure
> script itself. It is already way too complex and adding another
> dimension does not make it better.
> 
> Why is passing --disable-shared --enable-static LDLAGS="--static
> -static" to configure not sufficient?

That sounds better than adding an extra STATIC_LDFLAGS option, but,
IMHO, this sounds confusing, and it is not documented.

The advantage of having an option is that the expected behavior
can be documented in a way that the user will know what each option
would be doing by calling ./configure --help. Yet, IMHO, the above
parameters don't make clear about what type of output for executable
files (static, dynamic, "partially" dynamic).

We could (should?) also print, at the ./configure "summary" what
kind of libraries will be generated and what kind of executables.

Thanks,
Mauro

  reply	other threads:[~2016-09-26 18:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-19 10:50 [v4l-utils PATCH 1/1] Fix static linking of v4l2-compliance and v4l2-ctl Sakari Ailus
2016-09-19 11:22 ` Mauro Carvalho Chehab
2016-09-19 13:21   ` Sakari Ailus
2016-09-19 14:19     ` Mauro Carvalho Chehab
2016-09-26 15:46       ` Sakari Ailus
2016-09-26 16:59         ` Mauro Carvalho Chehab
2016-09-26 21:40           ` Sakari Ailus
2016-09-27 16:04             ` Mauro Carvalho Chehab
2016-09-27 17:35               ` Mauro Carvalho Chehab
2016-09-19 13:22 ` [v4l-utils PATCH 2/2] Add --with-static-binaries option to link binaries statically Sakari Ailus
2016-09-19 14:21   ` Mauro Carvalho Chehab
2016-09-19 14:34     ` Sakari Ailus
2016-09-26 17:41     ` Gregor Jasny
2016-09-26 18:02       ` Mauro Carvalho Chehab [this message]
2018-02-22  9:02         ` Sakari Ailus

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=20160926150253.558e0693@vento.lan \
    --to=mchehab@s-opensource.com \
    --cc=gjasny@googlemail.com \
    --cc=linux-media@vger.kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    /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.