On Sun, Nov 13, 2011 at 1:43 PM, Bill Janssen <bill.jans...@gmail.com> wrote: > Ah, I see. Yes, libjpeg is built from source on the build machines, > but only temporarily. It could be "installed" in /tmp, for instance, > and removed as part of the build process, after PIL is built, for > instance. I just used SAGE_LOCAL without thinking too hard about it. > > I'm not familiar yet with the spkg infrastructure, so perhaps it's > impossible to fit a step like this into the Sage build process.
If having jpeg support is actually really important, the "step" to put into the build process would be to include libjpeg as a new standard spkg with Sage. -- William > > On Nov 13, 1:31 pm, William Stein <wst...@gmail.com> wrote: >> On Sun, Nov 13, 2011 at 1:23 PM, Bill Janssen <bill.jans...@gmail.com> wrote: >> > My suggestion doesn't require binary build machines to have libjpeg >> > installed. In fact, you don't want it installed. >> >> Your suggestion for Sage binaries is: >> >> "1. Build libpng and libjpeg, static-only, and install to SAGE_LOCAL/ >> lib/. ... >> " >> >> This of course requires a build machine to have libjpeg built on it, >> say as part of the Sage build process. So that Sage works in a >> consistent manner across platforms, releases, and people building >> binaries, this should only happen if libjpeg is added to Sage itself >> as an spkg. I'm not necessarily opposed to that happening, since jpeg >> is a common format. >> >> -- William >> >> >> >> >> >> >> >> >> >> > And there seems to >> > be no technical reason to not statically link PIL against libjpeg.a. >> >> > But there *is* a reason to not *dynamically* link against >> > libjpeg.dylib, libpng.dylib, or libtiff.dylib. OS X includes versions >> > of these libraries in /System/Library/Frameworks/ >> > ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ >> > Versions/A/Resources/. They have different names, but the names >> > differ only in case, which isn't significant to the dynamic linker on >> > OS X. And Sage sets DYLD_LIBRARY_PATH. This means that any system >> > program (like Preview.app, which Imaging-1.1.7 uses for im.show()), >> > will fail if started from inside Sage, as the newer Sage-supplied >> > dylibs will be different from the (usually obsolete) versions the >> > system libraries are dynamically linked against. Unless the image >> > processing libraries are statically linked where needed in Sage, in >> > which case it works fine. >> >> > On Nov 13, 12:58 pm, William Stein <wst...@gmail.com> wrote: >> >> On Sun, Nov 13, 2011 at 12:47 PM, Bill Janssen <bill.jans...@gmail.com> >> >> wrote: >> >> > What's the objection to linking PIL statically against libjpeg? It >> >> > would remove a lot of uncertainty in the build. PIL seems to be the >> >> > only place libjpeg is used. >> >> >> We should not require binary build machines to have libjpeg installed. >> >> >> If we include libjpeg, then there is no reason to statically link. >> >> >> -- William >> >> >> > On Nov 13, 12:44 pm, William Stein <wst...@gmail.com> wrote: >> >> >> On Sun, Nov 13, 2011 at 12:10 PM, Bill Janssen >> >> >> <bill.jans...@gmail.com> wrote: >> >> >> > Yes, I think that's right, Justin. >> >> >> >> > I just tried this: >> >> >> >> > 1. Build libpng and libjpeg, static-only, and install to SAGE_LOCAL/ >> >> >> > lib/. >> >> >> > 2. Build Imaging-1.1.7 (after setting CPPFLAGS and LDFLAGS to point >> >> >> > to SAGE_LOCAL), and install to SAGE_LOCAL/lib. >> >> >> > 3. Remove my /opt/local/lib/ directory. >> >> >> >> > Now Image.open() and .show() work fine. >> >> >> >> > I think this should become part of the Sage build process, if it >> >> >> > isn't >> >> >> > already. >> >> >> >> No way. Either we include libjpeg properly with Sage (and link it >> >> >> dynamically), or we make sure that our build machines don't have stuff >> >> >> in /opt that produces bad binaries. >> >> >> >> I think including libjpeg at some point is reasonable, assuming that >> >> >> it is legal these days. (Is it?) >> >> >> >> -- William >> >> >> >> > That way you won't wind up with "improper builds". You can >> >> >> > delete the PNG and JPEG libraries after building PIL, as they're now >> >> >> > statically linked into the PIL libraries. >> >> >> >> > So, why not build libpng and libjpeg dynamically? Because Sage also >> >> >> > sets DYLD_LIBRARY_PATH (usually a bad indicator on Macs), and the >> >> >> > dynamic version would override the versions various system frameworks >> >> >> > (like ImageIO) are supposed to link against. Might it make more >> >> >> > sense >> >> >> > to use DYLD_FALLBACK_LIBRARY_PATH for this purpose? >> >> >> >> > Bill >> >> >> >> > On Nov 13, 11:50 am, "Justin C. Walker" <jus...@mac.com> wrote: >> >> >> >> On Nov 13, 2011, at 09:59 , Bill Janssen wrote: >> >> >> >> >> > You're implying that 4.7.1 or 4.7.2 fix this issue in some way? I >> >> >> >> > don't see anything in the release notes which would cause me to >> >> >> >> > suspect that. >> >> >> >> >> Unless I'm still too caffeine-deprived, I think the issue is that >> >> >> >> you are one of the first to try the Mac OS X 10.5 binary release of >> >> >> >> 4.7, at least with something involving this particular library. >> >> >> >> >> There is no (i.e., doesn't seem to be an) issue for those who are >> >> >> >> using either a different binary or have built from source (at >> >> >> >> least, your primordial example works for me) (once I change my name >> >> >> >> to "wjanssen" :-}). >> >> >> >> >> This doesn't seem to be a problem in Sage that needs to be fixed. >> >> >> >> It seems to be a problem with one (or perhaps more than one) binary >> >> >> >> that has been built improperly. >> >> >> >> >> If someone else doesn't verify this first, I'll try to get to it >> >> >> >> tomorrow. >> >> >> >> >> Justin >> >> >> >> >> -- >> >> >> >> Justin C. Walker, Curmudgeon at Large >> >> >> >> Director >> >> >> >> Institute for the Enhancement of the Director's income >> >> >> >> ----------- >> >> >> >> -- >> >> >> >> They said it couldn't be done, but sometimes, >> >> >> >> it doesn't work out that way. >> >> >> >> - Casey Stengel >> >> >> >> -- >> >> >> >> > -- >> >> >> > To post to this group, send email to sage-support@googlegroups.com >> >> >> > To unsubscribe from this group, send email to >> >> >> > sage-support+unsubscr...@googlegroups.com >> >> >> > For more options, visit this group >> >> >> > athttp://groups.google.com/group/sage-support >> >> >> > URL:http://www.sagemath.org >> >> >> >> -- >> >> >> William Stein >> >> >> Professor of Mathematics >> >> >> University of Washingtonhttp://wstein.org >> >> >> > -- >> >> > To post to this group, send email to sage-support@googlegroups.com >> >> > To unsubscribe from this group, send email to >> >> > sage-support+unsubscr...@googlegroups.com >> >> > For more options, visit this group >> >> > athttp://groups.google.com/group/sage-support >> >> > URL:http://www.sagemath.org >> >> >> -- >> >> William Stein >> >> Professor of Mathematics >> >> University of Washingtonhttp://wstein.org >> >> > -- >> > To post to this group, send email to sage-support@googlegroups.com >> > To unsubscribe from this group, send email to >> > sage-support+unsubscr...@googlegroups.com >> > For more options, visit this group >> > athttp://groups.google.com/group/sage-support >> > URL:http://www.sagemath.org >> >> -- >> William Stein >> Professor of Mathematics >> University of Washingtonhttp://wstein.org > > -- > To post to this group, send email to sage-support@googlegroups.com > To unsubscribe from this group, send email to > sage-support+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-support > URL: http://www.sagemath.org > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
