[sage-support] Re: Sage 4.7 on OS X Leopard
Bill, your expertise would clearly be really helpful on http://trac.sagemath.org/sage_trac/ticket/7344 in that case. This is basically the problem you are having, I think, except not in the binary-building side. There is supposed to be a waiting period for optional spkgs to become standard ones, of course, re: William's comment... - kcrisman -- 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
[sage-support] Re: Sage 4.7 on OS X Leopard
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. 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
Re: [sage-support] Re: Sage 4.7 on OS X Leopard
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 Steinwst...@gmail.com wrote: On Sun, Nov 13, 2011 at 1:43 PM, Bill Janssenbill.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 Steinwst...@gmail.com wrote: On Sun, Nov 13, 2011 at 1:23 PM, Bill Janssenbill.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 Steinwst...@gmail.com wrote: On Sun, Nov 13, 2011 at 12:47 PM, Bill Janssenbill.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 Steinwst...@gmail.com wrote: On Sun, Nov 13, 2011 at 12:10 PM, Bill Janssenbill.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. Walkerjus...@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
[sage-support] Re: Sage 4.7 on OS X Leopard
You'll see that I've already made a few comments on the issue. I think what I should do is put together an experimental pil-1.1.7.p0.spkg which implements my approach to the issue. That way you all can take a look at it and see what you think. Because of the DYLD_LIBRARY_PATH issue, the options that actually work on OS X, as well as other platforms, are somewhat limited. There's probably room to expand the pil test suite, too. Where would I find that code? On Nov 14, 8:22 am, kcrisman kcris...@gmail.com wrote: Bill, your expertise would clearly be really helpful onhttp://trac.sagemath.org/sage_trac/ticket/7344in that case. This is basically the problem you are having, I think, except not in the binary-building side. There is supposed to be a waiting period for optional spkgs to become standard ones, of course, re: William's comment... - kcrisman -- 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
[sage-support] Re: Sage 4.7 on OS X Leopard
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. Bill On Nov 12, 6:52 pm, kcrisman kcris...@gmail.com wrote: On Nov 12, 6:43 pm, Justin C. Walker jus...@mac.com wrote: On Nov 11, 2011, at 13:27 , Bill Janssen wrote: I've downloaded and installed sage on my OS X 10.5 (Leopard) Mac Pro. I'm trying to do some image processing, but things seem a bit bollixed up. It seems to me that if you're going to depend on a library that's installed in some non-standard place (I have no idea what would create /opt/local/lib) you should instead package it with and in the Sage tree. It sounds like you installed a binary release, rather than built Sage from source. True? If so, it appears that whoever built the binary did so without modifying his PATH to exclude the MacPorts stuff. Aha! See the title of the thread - Sage 4.7! Not 4.7.1 or 4.7.2. So you got your binary from whoever provided the 4.7 Intel binaries (e.g., athttp://www.cecm.sfu.ca/sage/osx/intel/index.html), which must have done that. Apparently we don't have any more recent 10.5 or 10.4 Intel binaries. So here is the way you can fix the binary, at least in principle. 1. Download the Sage source for 4.7.2 2. Build Sage from source (you'll probably have to move /sw, maybe not /opt) 3. Run sage -bdist 4.7.2-OSX-32bit-10.5 or something like that 3.5 (optional) Run export SAGE_APP_BUNDLE=yes and then repeat 4. Let the webmaster for sagemath.org know you have a binary or two for him to upload 5. Congratulate yourself on becoming an official contributor to Sage! If I said something wrong, I'm sure someone will correct this momentarily. But if you are persistent enough to do what you just did to solve your problem, this will be a snap. - kcrisman -- 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
Re: [sage-support] Re: Sage 4.7 on OS X Leopard
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 at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] Re: Sage 4.7 on OS X Leopard
On Sun, Nov 13, 2011 at 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. +1 to everything you're saying -- it seems completely right. And I just drank an espresso I made myself :-) 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 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
[sage-support] Re: Sage 4.7 on OS X Leopard
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. 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 at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] Re: Sage 4.7 on OS X Leopard
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 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
[sage-support] Re: Sage 4.7 on OS X Leopard
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. 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 at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
Re: [sage-support] Re: Sage 4.7 on OS X Leopard
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 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
[sage-support] Re: Sage 4.7 on OS X Leopard
My suggestion doesn't require binary build machines to have libjpeg installed. In fact, you don't want it installed. 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
Re: [sage-support] Re: Sage 4.7 on OS X Leopard
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
[sage-support] Re: Sage 4.7 on OS X Leopard
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
[sage-support] Re: Sage 4.7 on OS X Leopard
On Nov 13, 1:23 pm, Bill Janssen bill.jans...@gmail.com wrote: 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. Or, of course, unless the use of DYLD_LIBRARY_PATH is removed. It's usually a good idea to find a way to do that, in my experience. -- 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
Re: [sage-support] Re: Sage 4.7 on OS X Leopard
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
[sage-support] Re: Sage 4.7 on OS X Leopard
On Nov 11, 2:27 pm, Bill Janssen bill.jans...@gmail.com wrote: It seems to me that if you're going to depend on a library that's installed in some non-standard place (I have no idea what would create /opt/local/lib) you should instead package it with and in the Sage tree. FWIW, /opt is created by MacPorts, one of the two main open-source package managers for OS X (Fink, the other one, uses /sw.) It's probably a reasonable bet that most Sage users have one or the other of these installed, but I agree that it's a bad idea to depend on it. -- 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
Re: [sage-support] Re: Sage 4.7 on OS X Leopard
On Sat, Nov 12, 2011 at 10:39 AM, Daniel Dvorkin daniel.dvor...@gmail.com wrote: On Nov 11, 2:27 pm, Bill Janssen bill.jans...@gmail.com wrote: It seems to me that if you're going to depend on a library that's installed in some non-standard place (I have no idea what would create /opt/local/lib) you should instead package it with and in the Sage tree. FWIW, /opt is created by MacPorts, one of the two main open-source package managers for OS X (Fink, the other one, uses /sw.) It's probably a reasonable bet that most Sage users have one or the other of these installed, but I agree that it's a bad idea to depend on it. I remember that for a while at least (evidently not now?) Sage would refuse to build if either MacPorts or Fink were installed. It would appear perhaps that whoever built that binary had MacPorts installed? Incidentally, I currently don't have either installed, and I use OS X a *lot*. -- william -- 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
[sage-support] Re: Sage 4.7 on OS X Leopard
Ditto. I've got at least a dozen Macs (I run a number of Mac build slaves for the Python buildbot), and I never use MacPorts on them. Seems to me that a copy of libjpeg.8.dylib should go into SAGEROOT/ local/lib, and the SAGE build of PIL should reference it there. That's what I do with UpLib. Bill On Nov 12, 10:53 am, William Stein wst...@gmail.com wrote: On Sat, Nov 12, 2011 at 10:39 AM, Daniel Dvorkin daniel.dvor...@gmail.com wrote: On Nov 11, 2:27 pm, Bill Janssen bill.jans...@gmail.com wrote: It seems to me that if you're going to depend on a library that's installed in some non-standard place (I have no idea what would create /opt/local/lib) you should instead package it with and in the Sage tree. FWIW, /opt is created by MacPorts, one of the two main open-source package managers for OS X (Fink, the other one, uses /sw.) It's probably a reasonable bet that most Sage users have one or the other of these installed, but I agree that it's a bad idea to depend on it. I remember that for a while at least (evidently not now?) Sage would refuse to build if either MacPorts or Fink were installed. It would appear perhaps that whoever built that binary had MacPorts installed? Incidentally, I currently don't have either installed, and I use OS X a *lot*. -- william -- 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
[sage-support] Re: Sage 4.7 on OS X Leopard
That 7344 is quite a complicated ticket. I fixed my immediate problem by creating /opt/local/, downloading jpegsrc.v8c.tar, configuring it, building it, and installing it where Sage expects to find it. Thousands wouldn't have :-). Bill On Nov 11, 7:31 pm, kcrisman kcris...@gmail.com wrote: On Nov 11, 4:27 pm, Bill Janssen bill.jans...@gmail.com wrote: I've downloaded and installed sage on my OS X 10.5 (Leopard) Mac Pro. I'm trying to do some image processing, but things seem a bit bollixed up. It seems to me that if you're going to depend on a library that's Yeah, this is a problem we run into occasionally. installed in some non-standard place (I have no idea what would create /opt/local/lib) you should instead package it with and in the Sage tree. Seehttp://trac.sagemath.org/sage_trac/ticket/7344http://trac.sagemath.org/sage_trac/ticket/7345 for your suggestion. There probably is a way to get this to recognize your version of this, or something, without those tickets, but my expertise is lacking there; however, the tickets might have some ideas. Good luck! - kcrisman -- 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
[sage-support] Re: Sage 4.7 on OS X Leopard
Oh, sure, I could build from source. But I'd rather see the binary distribution fixed. On Nov 12, 3:43 pm, Justin C. Walker jus...@mac.com wrote: On Nov 11, 2011, at 13:27 , Bill Janssen wrote: I've downloaded and installed sage on my OS X 10.5 (Leopard) Mac Pro. I'm trying to do some image processing, but things seem a bit bollixed up. It seems to me that if you're going to depend on a library that's installed in some non-standard place (I have no idea what would create /opt/local/lib) you should instead package it with and in the Sage tree. It sounds like you installed a binary release, rather than built Sage from source. True? If so, it appears that whoever built the binary did so without modifying his PATH to exclude the MacPorts stuff. You may have better luck building from source. Justin -- Justin C. Walker Curmudgeon-at-large Director Institute for the Absorption of Federal Funds 186,000 Miles per Second Not just a good idea: it's the law! -- 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
[sage-support] Re: Sage 4.7 on OS X Leopard
On Nov 12, 6:43 pm, Justin C. Walker jus...@mac.com wrote: On Nov 11, 2011, at 13:27 , Bill Janssen wrote: I've downloaded and installed sage on my OS X 10.5 (Leopard) Mac Pro. I'm trying to do some image processing, but things seem a bit bollixed up. It seems to me that if you're going to depend on a library that's installed in some non-standard place (I have no idea what would create /opt/local/lib) you should instead package it with and in the Sage tree. It sounds like you installed a binary release, rather than built Sage from source. True? If so, it appears that whoever built the binary did so without modifying his PATH to exclude the MacPorts stuff. Aha! See the title of the thread - Sage 4.7! Not 4.7.1 or 4.7.2. So you got your binary from whoever provided the 4.7 Intel binaries (e.g., at http://www.cecm.sfu.ca/sage/osx/intel/index.html), which must have done that. Apparently we don't have any more recent 10.5 or 10.4 Intel binaries. So here is the way you can fix the binary, at least in principle. 1. Download the Sage source for 4.7.2 2. Build Sage from source (you'll probably have to move /sw, maybe not /opt) 3. Run sage -bdist 4.7.2-OSX-32bit-10.5 or something like that 3.5 (optional) Run export SAGE_APP_BUNDLE=yes and then repeat 4. Let the webmaster for sagemath.org know you have a binary or two for him to upload 5. Congratulate yourself on becoming an official contributor to Sage! If I said something wrong, I'm sure someone will correct this momentarily. But if you are persistent enough to do what you just did to solve your problem, this will be a snap. - kcrisman -- 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
[sage-support] Re: Sage 4.7 on OS X Leopard
On Nov 11, 4:27 pm, Bill Janssen bill.jans...@gmail.com wrote: I've downloaded and installed sage on my OS X 10.5 (Leopard) Mac Pro. I'm trying to do some image processing, but things seem a bit bollixed up. It seems to me that if you're going to depend on a library that's Yeah, this is a problem we run into occasionally. installed in some non-standard place (I have no idea what would create /opt/local/lib) you should instead package it with and in the Sage tree. See http://trac.sagemath.org/sage_trac/ticket/7344 http://trac.sagemath.org/sage_trac/ticket/7345 for your suggestion. There probably is a way to get this to recognize your version of this, or something, without those tickets, but my expertise is lacking there; however, the tickets might have some ideas. Good luck! - kcrisman -- 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
