[MacPorts] #29550: kdelibs4 @4.6.3: Undefined symbols _uncompress _compress

[MacPorts]

#29550: kdelibs4 @4.6.3: Undefined symbols _uncompress _compress
-------------------------------------+--------------------------------------
  Reporter:  macports@…              |       Owner:  snc@…           
      Type:  defect                  |      Status:  closed          
  Priority:  Normal                  |   Milestone:                  
 Component:  ports                   |     Version:  1.9.2           
Resolution:  invalid                 |    Keywords:                  
      Port:  openexr kdelibs4        |  
-------------------------------------+--------------------------------------

Comment(by michaelld@…):

 As to your other questions: It's sort of complicated, but I'll give it a
 go.

 libtool (GNU's, not Apple's), when told to link a library or executable,
 is looking at the requested libraries & figuring out whether or not they
 exist as dynamic and/or static, as well as whether or not dynamic and/or
 static have been requested for linking. by the user (or, port in this
 case).  When libtool cannot find all of the required dynamic ones, and the
 requested static ones all exist (as in your case), it tries to build a
 static library only.  When it can find both static and dynamic, it builds
 both if it has been told to do so (which is usually the case).  Now, at
 least with the OpenEXR and ilmbase ports, the build system it trying to
 build as both dynamic and static, but only static dependencies exist so
 that's what libtool builds.  I would guess that some prior dependent of
 KDELIBS4 took issue with /bin/f77 not responding as it expected, and
 decided to not build dynamic libraries -- because f77 is erroring out when
 checking for dynamic linking capabilities as determined by some
 'configure' script.  Hence why you ended up with static libraries; just a
 guess, of course.

 When linking libraries (whether static or dynamic) there are 2 basic ways
 of including external dependencies: the new library can be linked such
 that the dependency -must- be included after it, or it can be linked such
 that all of the dependency is included in it.  In the distant past, the
 latter approach was taken since most libraries were static, and having a
 single dependent library was much easier than having multiple
 dependencies.  In more recent years, the trend has moved towards the
 former and using dynamic libraries -- ones that can be loaded a runtime
 and then unloaded after they are no longer necessary.  This method uses
 less in-RAM memory (since a given library can be shared across multiple
 applications), and also allows for developers to recompile a given library
 & test it out, without having to recompile an executable that depends on
 it.  I think in the case of OpenEXR, which relies on 'libz' for compress
 and uncompress, it was being linked using the former method such that to
 create an executable one would need to specify "-lopenexr -lz" -- the
 'libz' was not implied by the "libopenexr".  For static libraries, there
 is no way to know this chain of dependencies without having some external
 file, such as that provided by PKGCONFIG, to define it -- or, just to know
 what the dependencies are beforehand.

 Now, that leads us back to why KDELIBS4 failed: Most configure scripts
 these days are written to use PKGCONFIG when available.  PKGCONFIG files
 provides info on how to include headers and link with install libraries
 for a given project via a specifically named file -- no matter if using
 static or dynamic linking.  The configure for OpenEXR and ilmbase are very
 clever, and check for PKGCONFIG first & if not available, then it does the
 checking manually.  KDELIBS4 uses CMake, which in general -does not- use
 PKGCONFIG, instead relying on its internal scripts for determining how to
 include headers and link with installed libraries.  Time and again in my
 dealings with CMake, I've found very poorly written scripts that barely
 function and are easy to break -- some are installed by CMake itself,
 while others are found in the local project.  I think what happens with
 KDELIBS4 is that the CMake script only checks to see if the openexr
 library is available, and not whether it has dependencies that need to be
 met.

 Combining the various parts: KDELIBS4's configure script finds the static
 OpenEXR library, but does not know that it is dependent on 'libz'.
 Because the OpenEXR static library was linked such that libz was also
 required, and CMake doesn't know about this dependency, during linking in
 KDELIBS4 only the OpenEXR static library is used & thus linking fails due
 to undefined symbols (those found in libz).

 Well, the above certainly sounds good; no idea how close I really am.
 And, as I said, it's a bit complex; I hope I did it justice :)

-- 
Ticket URL: <https://trac.macports.org/ticket/29550#comment:28>
MacPorts <http://www.macports.org/>
Ports system for Mac OS