Bug 172639 - libidn: remove libidn.la
Summary: libidn: remove libidn.la
Alias: None
Product: Fedora
Classification: Fedora
Component: libidn
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-11-07 20:58 UTC by Kjartan Maraas
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: 0.6.2-4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-06-01 10:20:20 UTC

Attachments (Terms of Use)

Description Kjartan Maraas 2005-11-07 20:58:07 UTC
Description of problem:

.la files aren't strictly needed on Linux and causes a lot of problems when
compiling since they hardcode absolute paths to dependent libraries.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Joe Orton 2005-11-08 09:24:36 UTC
See also other NOTABUGs.

Comment 2 Warren Togami 2005-11-08 18:45:52 UTC
Hi Joe, Bug #145879 seems to be the only other NOTABUG for libidn.  It is
unclear to me from this why keeping the .la file is desired.  Is there some
other report that you meant?

Comment 3 Joe Orton 2005-11-08 22:10:31 UTC
There reference was to the other identical bugs Kjartan was filing against my
packages.   This is not a bug.  Removing the .la file will break KDE, which
ltdlopen()s this library.  The libidn.la file should continue to be packaged. 
Really. :)

Comment 4 Rex Dieter 2006-05-11 12:58:52 UTC
Joe, including .la files generally goes against the now-to-be-used Packaging
Guidelines (http://fedoraproject.org/wiki/Packaging/Guidelines, "14. Exclusion
of static libraries".  Reopening.

And no, it won't break KDE (kde-redhat has been omitting libidn.la for *ages*).
 At most KDE would need to be rebuilt after libidn omitted the .la file.  See
also bug #170602 for another easy way for KDE to avoid breakage *without* having
to rebuilt.

Even if you're hesitant to make this change for *current* FC releases (it would
introduce binary incompatibility from existing/previous libidn pkg releases),
please seriously consider this for devel/fc6.

Comment 5 Joe Orton 2006-05-11 13:02:33 UTC
It is not the fact that any KDE .la file references libidn.la which makes this
problematic.  My understanding is that KDE uses ltdlopen() to load libidn at
runtime, which requires the presence of the .la file - at runtime - to work
correctly.  Please convince me that is not the case.

Comment 6 Rex Dieter 2006-05-11 13:09:05 UTC
AFAIK, kdelibs simply links against libusb, no ltdlopen() involved.  Regardless,
even *if* ltdlopen is used, it will look for libusb.la first, and if not found,
try to load libusb.so, but, oops, that's in libusb-devel (right?).  Lemme go
check my facts.

Comment 7 Rex Dieter 2006-05-11 13:11:21 UTC
On second thought, I'm 99% sure you're wrong.  If you were right, any KDE user
without libidn-devel installed (ie, where libidn.la is), would have a broken
system (ie, not being able to ltdlopen() libidn.la), right?

Comment 8 Rex Dieter 2006-05-11 13:13:04 UTC
Oops, nevermind, you include libidn.la in the core pkg... because of the runtime

Comment 9 Joe Orton 2006-05-11 13:14:57 UTC
Yes, that is my understanding.  Education welcome.

* Tue Jun 22 2004 Than Ngo <than@redhat.com> 0.4.9-2
- add prereq: /sbin/ldconfig
- move la file in main package

Comment 10 Rex Dieter 2006-05-11 13:18:59 UTC
Can't find any references to loading libidn at runtime in kdelibs, only standard
linking.  Than, comment?

If you're still concerned about the runtime loading, you could still omit
libidn.la and include libidn.so in the main pkg to accomplish the same thing.

Comment 11 Rex Dieter 2006-05-30 13:44:32 UTC
Joe, due to Than's silence, my opinion is "just do it", and see if anything
breaks, and I don't think anything will.

Comment 12 Ngo Than 2006-05-30 15:51:31 UTC
Joe, you can remove *.la from libidn for FC6. Thanks

Comment 13 Joe Orton 2006-06-01 10:20:20 UTC
OK, thanks guys.

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