The libpng12 spkg should also create symbolic links from `libpng.*` for its libraries

[nexttime]

Doing so avoids trouble if pkg-config isn't available, and packages look for just libpng.

The header png.h is already installed in $SAGE_LOCAL/include/, and a symbolic link from $SAGE_LOCAL/lib/pkgconfig/libpng.pc to the actual libpng12.pc is also created.

---

Actually the links (and a compatibility libpng shared library) are created by upstream, but spkg-install deleted these.

---

Use spkg at:
http://boxen.math.washington.edu/home/jpflori/libpng-1.2.35.p5.spkg

---

Original changes:

libpng-1.2.35.p4 (Leif Leonhardy, August 17th 2011)

• The libpng12 spkg should also create symbolic links from libpng.* for its libraries #11696: Do not delete symbolic links from libpng.* (and the shared
  library named libpng.so.*) in $SAGE_LOCAL/lib; see the comment in
  spkg-install for why (cf. also Race condition in matplotlib mkdir() #11686).
• Add -L$SAGE_LOCAL/lib to LDFLAGS, since otherwise Sage's zlib won't
  be used.
• Fix order of additions to flags, and don't drop user's settings. (Some
  might still intentionally get overridden though.)
• Use $MAKE, but also install serially since this shouldn't take much
  time and is certainly safer.
• Quote also $UNAME.

Further changes:

• Let libpng build a correct import on Cygwin using the SYMBOL_PREFIX trick, seehttp://old.nabble.com/Fwd%3A---libpng-Bugs-2981656---Import-library-definitions-missing-in-Windows-td28130513.html.
• Further cleanups.

CC: @jdemeyer @jhpalmieri @kcrisman @dimpase

Component: packages: standard

Keywords: PNG libpng spkg

Author: Leif Leonhardy, Jean-Pierre Flori

Reviewer: Dmitrii Pasechnik

Merged: sage-5.8.beta1

Issue created by migration from https://trac.sagemath.org/ticket/11696

[nexttime]

comment:1

New spkg is up.

Needs review and testing, the latter especially on Darwin.

(Though I see no reason for doing so, we could still delete some of the links / the compatibility shared library on Darwin only.)

[nexttime]

Description changed:

--- 
+++ 
@@ -1,4 +1,27 @@
 Doing so avoids trouble if `pkg-config` isn't available, and packages look for just `libpng`.
 
 The header `png.h` is already installed in `$SAGE_LOCAL/include/`, and a symbolic link from `$SAGE_LOCAL/lib/pkgconfig/libpng.pc` to the actual `libpng12.pc` is also created.
- 
+
+---
+
+Actually the links (and a compatibility `libpng` shared library) **are** created by upstream, but `spkg-install` deleted these.
+
+---
+
+**New spkg: http://spkg-upload.googlecode.com/files/libpng-1.2.35.p4.spkg**
+
+**md5sum:** `3789f82616a101eb1b00f339509f9616  libpng-1.2.35.p4.spkg`
+
+
+### libpng-1.2.35.p4 (Leif Leonhardy, August 17th 2011)
+* #11696: Do *not* delete symbolic links from `libpng.*` (and the shared
+  library named `libpng.so.*`) in `$SAGE_LOCAL/lib`; see the comment in
+  `spkg-install` for why (cf. also #11686).
+* Add `-L$SAGE_LOCAL/lib` to `LDFLAGS`, since otherwise Sage's zlib won't
+  be used.
+* Fix order of additions to flags, and don't drop user's settings. (Some
+  might still intentionally get overridden though.)
+* Use `$MAKE`, but also install serially since this shouldn't take much
+  time and is certainly safer.
+* Quote also `$UNAME`.
+

[nexttime]

Author: Leif Leonhardy

[nexttime]

comment:2

P.S.:

This is just another instance of where it IMHO doesn't make sense to build a Sage version if the system already provides some sufficient one, since doing so only causes trouble.

The best way would be to make such rather basic, unmodified packages just prerequisites; perhaps also supplying some easy way to build/install them on older systems (i.e., a tarball with some additional install script using reasonable settings). Shipping "standard" spkgs like e.g. also iconv, Fortran or Cephes just blows up the Sage tarball and increases the build time due to useless dependencies.

If we keep building such broadly available packages regardless of whether they're already installed system-wide (like also readline, PPL, GMP/MPIR, MPFR etc.), we should make sure they only get used by Sage components, by "moving them out of LD_LIBRARY_PATH" and using (a relative!) RPATH / RUNPATH in the parts of Sage that use these libraries.

[jhpalmieri]

comment:3

Notes (from #11686):

• test on OS X (recent)
• test on older versions of OS X
• test on skynet machine iras

For testing on iras, apply the spkg here, and then try building this matplotlib spkg. (The standard matplotlib spkg patches the file setupext.py to accommodate the lack of pkg-config on some systems, especially OS X. This modified spkg eliminates that patch.)

[jhpalmieri]

comment:4

On both an OS X box (OS version 10.6.8) and on iras: before installing the libpng spkg here, both systems failed to build the modified matplotlib spkg referred to in the previous comment. After installing the new libpng, both successfully built it. All doctests passed for the "plot" directory, and this worked:

sage: P = plot(sin(x))
sage: P.save('x.png')

After exiting Sage:

$ file x.png 
x.png: PNG image data, 484 x 316, 8-bit/color RGBA, non-interlaced

From the code, it looks like P.save('x.png') should call matplotlib, and so if libpng is broken or if matplotlib can't find it, I think this should fail. So things look good so far. Any other suggestions for testing this?

The package still needs testing on other systems, and we should run full doctests as well, not just for the 'plot' directory.

[nexttime]

comment:5

Replying to @jhpalmieri:

Any other suggestions for testing this?

The package still needs testing on other systems, and we should run full doctests as well, not just for the 'plot' directory.

Perhaps also on some MacOS X 10.4 box, and also in general by building Sage from scratch with the new libpng spkg.

The only issues I can imagine to arise happen if you try to start some program dynamically linked to an incompatible (presumably very old) system libpng library from within the Sage environment.

I don't know if there are any use cases of the latter we would have to take care of.

Another problem we would notice when building Sage from scratch could be some "tight" components (shared libraries / extension modules), not using pkg-config in their build, actually linking to the shared libpng.so.3* library, such that we might end up with a Sage binary pulling in both libraries, which could then again lead to name clashes, e.g. on Darwin.

The latter should IMHO never happen (at least not with properly written packages) since $SAGE_ROOT/local/lib/libpng.so is a symbolic link to $SAGE_ROOT/local/lib/libpng12.so, not $SAGE_ROOT/local/lib/libpng.so.3.35.0.

[jhpalmieri]

comment:6

A full build works successfully on sage.math and another unix box on skynet (taurus). I'm still waiting on the skynet machines fulvia (OpenSolaris), mark (Solaris), and iras ("ia64-Linux-suse").

Meanwhile, this fails on OS X 10.6.8. That is, while the spkg builds, it causes R to fail to install. I've put the full install log on-line, but here is the tail end of the log:

building package 'graphics'
mkdir ../../../library/graphics
make[4]: warning: -jN forced in submake: disabling jobserver mode.
mkdir ../../../library/graphics/R
mkdir ../../../library/graphics/po
make[4]: warning: -jN forced in submake: disabling jobserver mode.
Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared library '/Applications/sage_builds/sage-4.7.1.rc2/spkg/build/r-2.10.1.p4/src/library/grDevices/libs/grDevices.so':
  dlopen(/Applications/sage_builds/sage-4.7.1.rc2/spkg/build/r-2.10.1.p4/src/library/grDevices/libs/grDevices.so, 6): Symbol not found: __cg_png_create_info_struct
  Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
  Expected in: /Applications/sage_builds/sage-4.7.1.rc2/local/lib//libPng.dylib
 in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
Calls: <Anonymous> ... namespaceImport -> loadNamespace -> library.dynam -> dyn.load
Execution halted
make[4]: *** [mklazy] Error 1
make[3]: *** [all] Error 2
make[2]: *** [R] Error 1
make[1]: *** [R] Error 1
make: *** [R] Error 1
Error building R.

On one OS X box, the following line from the R install log switched from "no" to "yes" after installing the new libpng spkg:

checking for png_create_write_struct in -lpng... yes

On another box, it said "yes" for the old spkg as well. For both machines, I get the same failure.