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.

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

Reply via email to