Bug 193134 - RPM is pulling deps from non-shared libs' .la files
RPM is pulling deps from non-shared libs' .la files
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2006-05-25 12:04 EDT by Robert Scheck
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-29 09:13:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2006-05-25 12:04:37 EDT
Description of problem:
Latest RPM is pulling deps from non-shared libs' .la files for example at 
ImageMagick's loadable modules in %{_libdir}/ImageMagick-*/modules*/*/*.la.

Removing the .la files breaks convert (as per bug #185237 comment #2), but 
keeping the files causes RPM >= 4.4.5 to stop installing the package with a 
failed libtool dependency.

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

How reproducible and Steps to Reproduce:
Everytime, just use the spec file http://cvs.fedora.redhat.com/viewcvs/
*checkout*/devel/ImageMagick/ImageMagick.spec?rev=1.55 and try to rebuild and 
install ImageMagick. Re-try using http://cvs.fedora.redhat.com/viewcvs/
*checkout*/devel/ImageMagick/ImageMagick.spec?rev=1.56 - it will work, but 
convert will be broken.

Actual results:
Without a ugly workaround (as per bug #185237 comment #3) the rpm package of 
ImageMagick isn't really usable with latest RPM version.

Expected results:
Dunno exactly, some kind of fix even ;-)

Additional info:
The product FC is maybe the wrong one, but I still hope, that Fedora Core gets 
closer to upstream before FC6 is released and as long as there is no product in 
Bugzilla for rpm, this looks the right place for me for this bug report.
Comment 1 Robert Scheck 2006-05-26 06:55:04 EDT
When building ImageMagick- as it is and trying to 
install using latest RPM:

> libtool(/usr/lib/libMagick.la) is needed by ImageMagick-

That's fine, because no %{_libdir}/*.la is shipped in Fedora Core. Adding all
*.la to ImageMagick-devel- causes this at installing
(to be correct, I'm trying to install main package + -devel package):

> libtool(/usr/lib/libMagick.la) is needed by ImageMagick-
> libtool(/usr/lib/libMagick.la) is needed by ImageMagick-devel-
> libtool(/usr/lib/libWand.la) is needed by ImageMagick-devel-

Aha? But:

# rpm -qpl ImageMagick-devel- | grep "\\.la"

Ta ta...why the hell is RPM nagging about a *provided* dependency? When all
*.la files are available, RPM shouldn't complain about them, shouldn't it?
Comment 2 Jeff Johnson 2006-05-26 08:02:42 EDT
The "contain"ed path /usr/lib/libMagick.la != the "provide"ed dependency libtool(/usr/lib/libMagick.la).

The two are different.

Sort out the problem by doing
    echo /usr/lib/libMagick.la | /usr/lib/rpm/libtooldeps.sh --provides /
    echo /usr/lib/libMagick.la | /usr/lib/rpm/libtooldeps.sh --requires /

Note the final "/" arg, the 2nd argument is normally %{buildroot}.
Comment 3 Jeff Johnson 2006-05-29 09:13:30 EDT
The libtool dependency in libMagick is actually necessary (as currently implemented, see #185237 
comment 2).

The general answer for libtool dependencies is unclear while FC is still involved in radically eliminating 
every instance of *.la files. Whatever solution "works" for FC is unlikely to be useful for other distros that 
are not eliminating *.la files.

Deferred until hell freezes ...
Comment 4 Rex Dieter 2006-05-30 09:45:56 EDT
Jeff, I think you are confusing .la files for loadable modules/plugins and .la
files associated with shared libraries.  rpm should *only* be concerned with the
latter.  Now, I won't argue that it may be difficult to determine the difference
simply by looking at a .la file, but I don't think it would be unreasonable (as
a first pass) to limit rpm's automatic creation/extraction of libtool
dependancies to the pattern:

In ImageMagick's case, the dependancies are are *not* necessary, only that the
.la files be present.  (ImageMagick's packager omitted the plugin .la files).

If this isn't fixed, many packages, particularly kde ones, are going to end up
pulling in many, many bogus/extraneous dependancies on -devel pkgs (See related
kde bug #170602)
Comment 5 Jeff Johnson 2006-05-30 10:07:26 EDT
I am not confused, you are.

Have you tried rpm-4.4.7?

Have you looked at /usr/lib/rpm/libtooldeps.sh?

Have you thought about whether you want to turn the libtool dependencies on or off?

Or do you prefer to carp at me instead about how much will break if *.la dependencies are used ...

Patches cheerfully accepted from doeers, not talkers ...
Comment 6 Rex Dieter 2006-05-30 10:26:27 EDT
No, I haven't looked at rpm-4.4.7.  Don't have any rawhide boxes (and as far as
I can tell, rawhide is still at rpm-4.4.2?)

I was simply refuting bits from your comment #3:

* "The libtool dependency in libMagick is actually necessary".  In this
(ImageMagick's) case, an rpm-generated libtool dependancy was *not* necessary.

* "The general answer for libtool dependencies is unclear".  To me, the general
answer *is* clear.  libtool dependancies for shared libs: good.  libtool
dependancies for everything else: bad.  For the former case of of shared libs,
the future need for rpm-generated libtool dependancies will (hopefully) be
minimized, since as you pointed out, FC is working to remove these
viral-infecting shared-lib type of .la files.

Now, I'm off to find rpm-4.4.7 to see exactly what libtooldeps.sh *does* and
*does not* do.
Comment 7 Jeff Johnson 2006-05-30 10:43:09 EDT
"actually necessary" -- if the loadable module mentioned in the *.la file is not actually present, then the 
load will fail. This can be tracked with a dependency, and that failure can be detected.

FWIW, rpm-4.4.7 can do the verification at install-time, not just at build time, if necessary.

"viral-infecting shared-lib" -- lose the attitude dude. *.la files (and libtool) implements functionality 
that pkgconfig doesn't even begin to implement.

E.g. rpm is built with certain libraries internal or external, and libtool makes that choice maintainable, 
otherwise a gory mass of Makefile rules would be needed to merge an internal (and uninstalled)  library.

Whether FC will succeed in killing off *.la files universally is still open to question. Good luck!

Ironically, *.la dependencies were a feature request from a FC developer, see #1559221.
Comment 8 Rex Dieter 2006-05-30 12:43:29 EDT
Just took a look at libtooldeps.sh from rpm-4.4.7, and it is as a had only
previously assumed.  It creates Provides/Requires for all *.la files.  I would
argue (still) that it should limit itself to only /usr/lib/lib*.la files.  Patch
against rpm-4.4.7 forthcoming...

> "viral-infecting shared-lib" -- lose the attitude dude

Ha.  Good one, coming from you, that just made my day.  (: (no offense, you're
my hero).

Don't get me wrong, I'm not denigrading .la files in any way.  They're great and
have invaluable usefulness in building and maintaining software.  And, I hope,
that no-one is advocating the universal killing-off of .la files.  I'm only
speaking in the context of rpm packaging and including .la files assocated with
shared libraries.

> Ironically, *.la dependencies were a feature request from a FC developer
> see bug #159221 – RFE: track libtool .la dependencies

Yep, Nalin was talking about shared-lib .la files too (at least the examples he
gave did).

In the context of software *packaging*, shared-lib .la files, in general, just
plain suck.  When/if using systems with good shared libraries (and avoiding the
static lib/linking cases), .la files are generally unnessessary and lead to
needless dependancies (e.g, are virual):  

Here's a crazy-but-not-too-far-from-reality example:
Build shared-lib pkg 'b' which links against 'a'.  b's .la files now include
references to 'liba.la' (so now depends on it).  Build shared-lib pkg 'c' which
links against 'b', whose own libc.la file includes references(+dependancy) on
libb.la.  Rinse, lather, repeat.  You'll end up with a pkg z, and a libz.la,
which, when all is said and done, 
* will have a direct dependancy upon y's liby.la
* and because of liby.la file references/dependances, will have (indirect)
dependancies upon liba.la, libb.la, ..., libx.la
When, generally, *none* of these are really required nor desired.

The fix for this is easy too.  At each stage, simply omit %%_libdir/lib*.la from
packaging.  You end up with a nice, clean libz, which may or may not depend on
liby, and which almost certainly doesn't depend on liba, ..., libx.

This is, as I understand it, the basis for the campaign to remove shared-lib .la
files from Fedora Core.
Comment 9 Jeff Johnson 2006-05-30 13:12:44 EDT
Adding a case to limit extraction to /lib* and /usr/lib* is trivially achieved if/when anybody actually 
starts using or needing *.la dependencies. The adoption time for new functionality in rpm is now over 2 
years, so I vae at least another year to fix the libtool extraction.

Sure, in the linkage case libA -> libB -> libC there is the possibility of redundant dependencies.

Does -lB imply -lC implicitly or explicitly? The explicit (in my words) case is when libA is linked with "-
lB -lC", which can lead to a redundant dependency of A -> C.

That is true for any means of linking libraries, either ELF DT_NEEDED within shared libraries, or through 
*.la dependent library specs. The problem is general, not specific to libtool *.la.

However, for various hysterical reasons, the intent in RHL package way back when was to consciously 
and explictly link libA with "-lB -lC", the idea (iirc) being to localize dependency information and work 
around some arcane ELF bustage that has long since been repaired. Whether that was necessary or wise 
is a whole different question.

I'll have to check to see whether libtool permits dropping intervening libraries. One can certainly
used sed on libA.la to remove "... -lC" when building/packaging if necessary,.

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