From: Roman Zimmermann <mereandor@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] gentoo: static/dynamic linking libraries
Date: Mon, 30 Apr 2007 05:07:00 +0200 [thread overview]
Message-ID: <200704300507.10429.mereandor@gmail.com> (raw)
In-Reply-To: <20070429231147.488db599@snowflake>
[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]
Am Montag 30 April 2007 00:11 schrieb Ciaran McCreesh:
> On Sun, 29 Apr 2007 14:56:57 -0700
>
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > Anyone who wants to build a static binary wants the static libs. Given
> > the difficulty in universally enabling or disabling their builds
> > because of build-system differences, building them and tossing them
> > in the trash with INSTALL_MASK, as Marius suggested, seems like the
> > best way to go.
>
> The best way to go or the only viable short term solution?
That's the point! Universally disabling static builds can't be a longterm
solution. The only sane way to do this is on a per ebuild basis. Since only
the ebuild "knows" whats the right way to disable static libs or whether this
package supports it at all.
As of now most packages use or ignore --disable-static in a proper way, but
since GNU autotools are not that popular anymore the "ignore" part of the
tree is inclined to grow.
This method has the advantage that it either fails at compile time or works
fine. Something gives me the feeling that INSTALL_MASK will break things
after installation and silently, which is a bad thing. So no solution here.
And as it was pointed out before. Static builds are not needed most of the
time. There is only 2 packages that actually need the static libraries. The
rest fails due to upstream bugs in the configure/makefile
(recognizing --disable-static but only applying it partially).
So --disable-static seems to me like the only
half-sane-partial-short-time-solution.
cheers
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-04-30 3:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-29 8:32 [gentoo-dev] gentoo: static/dynamic linking libraries Roman Zimmermann
2007-04-29 8:54 ` Jakub Moc
2007-04-29 10:36 ` Ciaran McCreesh
2007-04-29 16:43 ` Roman Zimmermann
2007-04-29 17:50 ` Marius Mauch
2007-04-29 17:56 ` Ciaran McCreesh
2007-04-29 18:21 ` Roman Zimmermann
2007-04-29 18:46 ` paul kölle
2007-04-29 19:04 ` Roman Zimmermann
2007-04-29 19:31 ` Marius Mauch
2007-04-29 19:36 ` Ciaran McCreesh
2007-04-29 20:05 ` Olivier Crête
2007-04-29 21:50 ` Rémi Cardona
2007-04-29 21:56 ` Donnie Berkholz
2007-04-29 22:11 ` Ciaran McCreesh
2007-04-30 3:07 ` Roman Zimmermann [this message]
2007-04-30 3:35 ` Marius Mauch
2007-04-30 7:28 ` Roman Zimmermann
2007-04-30 8:49 ` [gentoo-dev] " Duncan
2007-04-30 19:00 ` [gentoo-dev] " Kevin F. Quinn
2007-05-01 7:28 ` Roman Zimmermann
2007-05-01 2:49 ` Peter Gordon
2007-05-01 5:16 ` Donnie Berkholz
2007-05-01 9:16 ` Radoslaw Stachowiak
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=200704300507.10429.mereandor@gmail.com \
--to=mereandor@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
/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