#197 v1.2.50: Import library definitions missing in Windows

open-accepted
makefiles (58)
5
2013-02-04
2012-11-27
No

The .dll.a library definitions file generated by the 1.2.50 build system on MinGW is empty, and therefore nothing can dynamically link against it. I was able to get it to have all the symbols by removing the '_' prefix from the libpng.vers file. This is how I did that:

$ svn diff Makefile.am
Index: Makefile.am
===================================================================
--- Makefile.am (Revision 16616)
+++ Makefile.am (Arbeitskopie)
@@ -117,7 +117,7 @@
echo PNG@PNGLIB_MAJOR@@PNGLIB_MINOR@_0 '{global:' > $@.new
$(SED) s/$$/\;/ libpng.sym >> $@.new
echo 'local: *; };' >> $@.new
- mv $@.new $@
+ $(SED) s/^_// $@.new > $@

test: check

It would be nice to also have 1.2.x build properly on MinGW since lots of things still depend on this version. This seems to be related to this bug, which was fixed in 1.5.0.
https://sourceforge.net/tracker/index.php?func=detail&aid=2981656&group_id=5624&atid=105624

Discussion

  • Forwarded to the png-mng-implement list for evaluation and response. Note that we don't plan any further libpng-1.2.x releases except for security support.

     
    • milestone: 101689 --> libpng-devel
    • labels: 102838 --> makefiles
    • status: open --> open-accepted
     
    • assigned_to: nobody --> glennrp
     
    • Milestone: libpng-devel --> libpng_build_scripts
     
  • Here is the response from the png-mng-implement list:

    "The fix is to prevent the use
    of a version script for GCC on Windows and use the relevant function
    attributes. The problem is that getting the function attributes
    correct is only possible on 1.5+ because in earlier versions it was
    not possible to known in png.h whether the compilation was for a
    libpng user or for a libpng build.

    "A general, portable, solution for GCC is still not within reasonable
    effort because, so far as I can tell, GCC requires every function that
    is not exported from a DLL to be so marked - an approach that is
    effectively impossible. However the GCC version script stuff seems to
    have been fixed, so that a version script always uses the C tokens,
    not the form they end up with in the DLL; it may be that the
    SYMBOL_PREFIX stuff is actually irrelevant with any recent GCC
    version, although we have no obvious way of proving that."

    So the bottom line seems to be that applications should migrate
    to libpng-1.5. We can't take the proposed patch because it isn't
    generally applicable.

    Glenn