On Jul 9, 8:18 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > On Wed, Jul 9, 2008 at 8:11 PM, David Philp <[EMAIL PROTECTED]> wrote:
Hi, > > This is a 'for the record' email describing how to use boost.python > > with sage on Mac OS X. Thanks to the gentlefolk who walked me through > > it (especially Carl Witty). > > > I am assuming a working boost.python extension called 'my_ext.so'. > > "Working" means that you should be able to start up python at the > > command line, run "import my_ext" and call your functions / > > instantiate classes etc. > > > Attempting to do the same with sage fails. Start sage, run "import > > my_ext" and it will fail with a message like > > ImportError: dlopen(./my_ext.so, 2): Symbol not found: > > _PyUnicodeUCS2_AsWideChar > > > The problem is that the version of python distributed inside sage uses > > UCS4 (for consistency with linux) rather than UCS2 (which is used by > > Apple's system python). Because libboost_python is compiled against > > Apple's Python, it assumes UCS2. There are two possible fixes: (1) > > recompile boost against sage's python, and it will use UCS4. (2) > > Recompile sage to use UCS2. > > > The second option is better for me, because I want my python > > extensions binary compatible with both system python and sage python. > > (The alternative is to have system & sage versions of boost, and > > system & sage versions of every extension.) Changing sage's default > > unicode setting might have consequences that I don't understand, but I > > haven't been bitten yet. > > It should be fine. We used UCS2 until maybe 8 months ago. We switched > as mentioned above only for Linux compatibility. > > > You will need to do this for each successive > > version of sage, which could be tedious. > > I would be ok with making an environment variable, e.g., SAGE_UCS2 > that if set causes SAGE to build using UCS2. I don't like this at all since it will introduce more complexity and the possibility for subtle bugs. > Alternatively, we could make Sage on OS X use UCS2 but Sage on > Linux use UCS4. I like this even less since Apple's python is universal and when you build extensions with it those extensions are universal (or the compiler at least attempts to build them). Since gmp is fundamentally broken as a universal library due to design issues subtle bugs crop up. I can quote one email from gmp-devel if you want me to. In addition Apple's linker happily links together x86 code and ppc libraries as I learned the other day and it took a long, long time to figure out why an extension build that way failed to import at run time. It is just not worth the trouble. We will switch to Python 2.6 at some point and Apple might now follow. What to do then? Maybe their next universal binary will be four arches instead of two now? As is the 64 bit Sage port on OSX is fundamentally incompatible with any python Apple ships. This is more general: If you want to use Sage with the system's python you are on your own IMHO. The complexity to debug problems is insane since you never know how python was compiled and when the user did use the system python and when Sage's. Switching back and forth will happen and make it even more murky. I don't mind that people do use the system python or use custom build options if they know what they are doing, but people have and will shoot themselves in the foot and I have little time to help them since I have plenty of bugs to fix in "vanilla" Sage. It is the old open source mantra: If you break Sage by doing something stupid you get to keep the pieces :) - and we should not encourage people to do something stupid. Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
