Bug 397051 - Why built with --disable-static
Summary: Why built with --disable-static
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: GeoIP
Version: 8
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Michael Fleming
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-11-23 16:32 UTC by Reindl Harald
Modified: 2007-12-05 11:47 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-12-05 11:47:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Reindl Harald 2007-11-23 16:32:16 UTC
Hi

You can not compile "Webalizer Xtended" if GeoIP 
is built with "--disable-static "

See my feature request here for replace webalizer:
https://bugzilla.redhat.com/show_bug.cgi?id=387771

So i see two solutions, the better one: replace the old webalizer or build GeoIP
without --disable-static, Rebuild the Source-RPM and place it in a own repo is
not a really good solution for future updates

Comment 1 Michael Fleming 2007-12-05 11:47:31 UTC
I would consider an inability to build against a dynamic library a bug in the
upstream software - have you asked the Webalizer Xtended author why this is?

(as an old Webalizer user I'm kind of happy someone still cares about it!)

The Fedora packaging guidelines prohibit this in most cases (see
http://fedoraproject.org/wiki/Packaging/Guidelines#head-2302ec1e1f44202c9cc4bcce24cb711266557ad7)
and I happen to agree with them on these points.

Ulrich Drepper (RH and glibc hacker) outlines it better here:
http://people.redhat.com/drepper/no_static_linking.html. Point 1 is of great
interest to both of us as packagers, point 2 is also especially important if
you're a sysadmin/security person (like me ;-))

In short, I'm not willing at this point to ship a static libGeoIP.a. I - and I
will wager other potential users of your proposed package - would really like to
see this fixed *correctly* upstream rather than inelegant hacks in our
respective packages. 

While simple to do for me (just a few lines in the spec) I'd be encouraging bad
practice as well as lumping all manner of suffering on anyone using it (yes,
you'd have to recompile your package on every single bugfix/security release vs.
only recompiling if the SONAME changes in cases of a dynamic library)

Sorry for the bad news.



Note You need to log in before you can comment on or make changes to this bug.