Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] Static build changes
Date: Wed, 11 Jan 2012 08:01:36 +0100	[thread overview]
Message-ID: <201201110801.36481.arnout@mind.be> (raw)
In-Reply-To: <F9C551623D2CBB4C9488801D14F864C60EF684@ex-mb1.corp.adtran.com>

On Monday 09 January 2012 21:45:16 ANDY KENNEDY wrote:
> > > Makefile
> > > package/ethtool/ethtool.mk
> > > package/htop/htop.mk
> > > package/i2c-tools/i2c-tools.mk
> > > package/kexec/kexec.mk
> > > package/libgcrypt/libgcrypt.mk
> > > package/libgpg-error/libgpg-error.mk
> > > package/makedevs/makedevs.mk
> > > package/mtd/mtd.mk
> > > package/ncurses/ncurses.mk
> > > package/portmap/portmap.mk
> > > package/proftpd/proftpd.mk
> > > toolchain/uClibc/uclibc.mk
> > 
> >  This part of the log message is redundant.  It shows up in the git
> > shortlog.
> > However, it is useful to include a remark that this doesn't fix the
> > issue
> > for all packages.
> 
> I do not have the time to figure out how to (nor am I sure that on this
> network I can) use git to do the patches.  Were I able to get git going,
> the first e-mail would have been that really nice blurb about the files
> affected.  This was my intent by the above.

 The thing is, everything that you put in the e-mail will end up in the
git commit as well.  To add comments in the mail that should not be in
the commit message, add something like
---
additional comment
---
between the commit message (first part) and the first diff.

> > > @@ -7,4 +7,8 @@
> > >  ETHTOOL_VERSION = 3.0
> > >  ETHTOOL_SITE = $(BR2_KERNEL_MIRROR)/software/network/ethtool/
> > >
> > > +ifeq ($(BR2_PREFER_STATIC_LIB),y)
> > > +ETHTOOL_CONF_ENV += LDFLAGS+=-static
> > > +endif
> > 
> >  Wouldn't it be more convenient if this was added globally to
> > TARGET_LDFLAGS in Makefile.in?  The -static is anyway just a hint,
> > it doesn't force the linker to link statically.
> 
> To quote Bill Cosby:  "I hadn't thought of that."

 That's why we have reviews :-)

> > > +
> > >  $(eval $(call AUTOTARGETS))
> > > diff -Naur a/package/htop/htop.mk b/package/htop/htop.mk
> > > --- a/package/htop/htop.mk      2011-12-14 15:54:04.000000000 -
> > 0600
> > > +++ b/package/htop/htop.mk      2011-12-20 09:44:06.000000000 -
> > 0600
> > > @@ -11,4 +11,9 @@
> > >  HTOP_AUTORECONF = YES
> > >  HTOP_CONF_OPT += --disable-unicode
> > >
> > > +ifeq ($(BR2_PREFER_STATIC_LIB),y)
> > > +HTOP_CONF_ENV += LDFLAGS+="--static -lpthread"
> > > +HTOP_CONF_OPT += "'--enable-static' --disable-shared"
> >  Is this needed?  The $(PKG)_CONFIGURE_CMDS of
> > Makefile.autotools.in
> > already includes $(SHARED_STATIC_LIBS_OPTS).
> 
> Okay, I'm cool with that too.  Looking at the various configure scripts,
> I seem to recall an issue with giving a parameter that wasn't available
> in the configure script.  Like it errored out.  I cannot recall, though.
> I did this patch up over a month ago and sent it out before xmas. (I've
> slept since then.)  The bottom line, there appears to be a lack of a
> standard for dealing with the configure options (or at least not all
> packages use the standard).

 GNU autoconf will give a warning about unsupported options.  One of the
global options is actually unsupported for most platforms:
--disable-gtk-doc.

 If some package has a custom configure script that errors out, it
should override $(PKG)_CONFIGURE_CMDS.

[snip]
> > > diff -Naur a/toolchain/uClibc/uclibc.mk
> > b/toolchain/uClibc/uclibc.mk
> > > --- a/toolchain/uClibc/uclibc.mk        2011-12-14
> > 15:54:04.000000000 -0600
> > > +++ b/toolchain/uClibc/uclibc.mk        2011-12-20
> > 09:53:49.000000000 -0600
> > > @@ -480,6 +480,7 @@
> > >                 install_runtime
> > >         touch -c $@
> > >
> > > +ifneq ($(BR2_PREFER_STATIC_LIB),y)
> > >  $(TARGET_DIR)/usr/bin/ldd: $(cross_compiler)
> > >         $(MAKE1) -C $(UCLIBC_DIR) CC=$(TARGET_CROSS)gcc \
> > >                 CPP=$(TARGET_CROSS)cpp LD=$(TARGET_CROSS)ld \
> > > @@ -487,7 +488,6 @@
> > >                 PREFIX=$(TARGET_DIR) utils install_utils
> > >         touch -c $@
> > >
> > > -ifneq ($(BR2_PREFER_STATIC_LIB),y)
> > >  UCLIBC_TARGETS=$(TARGET_DIR)/lib/libc.so.0
> > >  endif
> > 
> >  I'm not sure if I agree with this change.  Prefer static does not
> > mean
> > force static, so the dynamic linker stuff should still be present.
> 
> So, the original design I had done was to add top-level config option
> under PREFER_STATIC as BUILD_ONLY_STATIC.  I guessed that this would not
> be well received by the hive.  Perhaps that would have been a better
> thing to do.  PREFER_STATIC seems to be misleading (based upon my
> expectations) given that if you _PREFER_ to use static libraries, then
> shouldn't the system ONLY USE static libraries and never install the
> shared objects?  I mean, if I ask my contractor to use screws to build
> something, and he uses nails, that isn't what I asked for.  But again,
> perhaps I have the wrong expectations for PREFER_STATIC.

 I guess this is because some packages don't know how to build static
libraries, or how to link with them.  Such packages would have to depend
on !BUILD_ONLY_STATIC.  But I think that it is a lot of work to maintain
that option, with little benefit.


 Regards,
 Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

  reply	other threads:[~2012-01-11  7:01 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 [this message]
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

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=201201110801.36481.arnout@mind.be \
    --to=arnout@mind.be \
    --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