On 2009-01-30 17:08, Floris Bruynooghe wrote:

Hi Dave

On Mon, Jan 26, 2009 at 06:48:06PM -0600, Dave Peterson wrote:

...

I am trying to build a number of projects that use Python extensions on Solaris 10 and I've discovered that nothing with extensions will link unless I explicitly pass in a '-L/path/to/python/lib/dir' because libpython2.5.so is not otherwise found when the '-lpython2.5' argument is specified during linking. [...] If that all seems correct, then it appears the issue is the finalize_options() source in lib/distutils/commands/build_ext.py. There are a number of "if" blocks that explicitly append the value of distutils.sysconfig.get_config_vars('LIBDIR') to the list of library_dirs used to link built extensions with. However, there doesn't seem to be one of these for Solaris / sunos.

Could you point to one of the projects you're having trouble with? I haven't had any such problems with Python 2.5 on Solaris 10, distutils always finds the right things when I'm building extension modules.

It's not specific to any one project. Mostly, it seems to be tied to using a custom --prefix where $prefix/lib is not on the default library search path. Are you using such a custom --prefix? -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

On Fri, Jan 30, 2009 at 05:45:26PM -0600, Dave Peterson wrote:

Floris Bruynooghe wrote:

...

On Mon, Jan 26, 2009 at 06:48:06PM -0600, Dave Peterson wrote:

...

I am trying to build a number of projects that use Python extensions on Solaris 10 and I've discovered that nothing with extensions will link unless I explicitly pass in a '-L/path/to/python/lib/dir' because libpython2.5.so is not otherwise found when the '-lpython2.5' argument is specified during linking.

[...]

...

If that all seems correct, then it appears the issue is the finalize_options() source in lib/distutils/commands/build_ext.py. There are a number of "if" blocks that explicitly append the value of distutils.sysconfig.get_config_vars('LIBDIR') to the list of library_dirs used to link built extensions with. However, there doesn't seem to be one of these for Solaris / sunos.

Could you point to one of the projects you're having trouble with? I haven't had any such problems with Python 2.5 on Solaris 10, distutils always finds the right things when I'm building extension modules.

Pretty much everything I've tried that uses an extension has this problem. Cython, Numpy, Traits, etc. As Robert Kern pointed out, I'm using a custom built Python (Python 2.5.4) built and installed into a custom location via '--prefix'. What Python are you using?

Ah, I get it now. I did cut out the important part: you build with --enable-shared. I'm also using a custom build Python with --prefix but don't use --enable-shared so don't get this problem.

I'm leaning more and more toward this is actually a bug with the distutils source on Solaris.

Yes, I agree now that it is a bug in distutils and I agree with your fix. The if statement should check both that it is SunOS and that it is using a shared python, just like the linux one. If fact the linux one could just be modified: if (sys.paltform.startswith('linux') \ or sys.platform.startswith('gnu') \ or sys.platform.startswith('sunos')) \ and sysconfig.get_config_var('Py_ENABLE_SHARED'): ... I'll leave the honours of reporting the bug to you if you agree with this. Lastly out of curiosity: why --enable-shared? Do you embed python? Or are there other reasons to use it? Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

Tarek Ziade wrote:

2009/1/31 Floris Bruynooghe :

...

...

I'm leaning more and more toward this is actually a bug with the distutils source on Solaris.

Yes, I agree now that it is a bug in distutils and I agree with your fix. The if statement should check both that it is SunOS and that it is using a shared python, just like the linux one. If fact the linux one could just be modified:

if (sys.paltform.startswith('linux') \ or sys.platform.startswith('gnu') \ or sys.platform.startswith('sunos')) \ and sysconfig.get_config_var('Py_ENABLE_SHARED'): ...

I'll leave the honours of reporting the bug to you if you agree with this.

Yes thanks to report this, I'll apply your fix,

Regards Tarek

Hi Tarek, It isn't clear to me if you fixed it already or were waiting for my patch, but I just added issue 5132 to the Python issue tracker to document the issue and provide a patch file. -- Dave

Tarek Ziadé wrote:

On Mon, Feb 2, 2009 at 7:29 PM, Dave Peterson wrote:

...

Hi Tarek,

It isn't clear to me if you fixed it already or were waiting for my patch, but I just added issue 5132 to the Python issue tracker to document the issue and provide a patch file.

I was waiting for that, thanks :)

Tarek

I noticed you removed the Python 2.5 version specification. I wasn't aware there were no further planned maintenance releases for the 2.5 branch. A few of the libs we use still seem to have problems building on 2.6. Guess it is just a matter of time. -- Dave

On Feb 2, 2009, at 12:01 PM, Dave Peterson wrote:

I noticed you removed the Python 2.5 version specification. I wasn't aware there were no further planned maintenance releases for the 2.5 branch. A few of the libs we use still seem to have problems building on 2.6. Guess it is just a matter of time.

I maintain a few libraries with compiled C code. I don't know how to build binaries for Python 2.6, because apparently the method that I've been using until now to build binary extension modules (mingw) isn't able to produce 2.6-compatible extension modules yet. For now, I'm just not distributing binaries for Python 2.6 (nor, of course, doing a proper job of testing with Python 2.6). I've been kind of hoping that either mingw would catch up or that all my users would give up on Python >= 2.6 and go back to using Python 2.5, but perhaps I should start making new plans... Meanwhile I'm watching with interest this ticket: http:// bugs.python.org/issue3871 Maybe in the future I can just offer my users a Python executable which is compatible with the Free Software tools that I know and use, instead of figuring out how to make modules which are compatible with the proprietary compiler used to build the official Python 2.6! Regards, Zooko P.S. Whoops, sorry. This message was total flame-bait and off-topic to boot. But it has been bugging me, and I feel better for having gotten it off my chest.