On 11/14/11 9:07 AM, Bill Janssen wrote:
I see that there is already an experimental skpg for jpeg-6b.
Unfortunately, when I install it, it doesn't help with the Image
problem. It looks like it doesn't install the library, only the
command-line programs. In any case, PIL wouldn't know to use it,
since it figures out what it has to work with at compile time, not run
time.
You would also have to rebuild PIL by typing something like
./sage -f pil
-- William
Bill
On Nov 13, 5:23 pm, William Stein<wst...@gmail.com> wrote:
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 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
