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
next prev parent 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 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.