You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David James <ja...@gmail.com> on 2005/08/27 17:10:14 UTC
[PATCH] Explicitly link the python bindings against libpython (was: Re: Major upgrades to SWIG/Python bindings in r15848)
On 8/27/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Sat, Aug 20, 2005 at 02:05:43PM -0400, David James wrote:
> > I've committed some major upgrades to SWIG/Python bindings in r15848
> > (Merged from the python-bindings-improvements branch).
>
> Given that trunk didn't do squat for me (I ran into similar problems as
> Philip did), I switched back to the branch.
>
> However, there's a problem here (both in trunk and the branch): how is
> the SWIG generated code supposed to link to anything?
>
> In my setups, linking consistently fails because of undefined symbols
> that are defined by Python's libraries. Nowhere do I see any mention of
> linking to libpython. Manually defining -lpython2.4 to LSWIGPY works.
> (Note that SWIG_PY_LIBS doesn't get used anywhere, AFAICT.)
>
> With previous SWIG versions, we'd link against libswigpy (defined at
> configure time as LSWIGPY) - which would link in turn to libpython.
> However, with our current setup, I don't see how that is being done.
>
> I don't know if get-py-info.py needs to be 'spruced' up or something
> else. (It wasn't touched at all as part of this work; so perhaps it is
> not useful anymore?)
>
> % python ./get-py-info.py --libs
>
> % python ./get-py-info.py --link
> gcc -pthread -shared
>
> Philip's post contained a configure snippet that is almost identical to
> what I get. So, unless I'm missing something, if he tries the branch
> (or trunk after merge), I think he's going to get the same problem.
>
> I'm kinda stumped as I feel there's some pieces missing that I'm not
> sure where they go or if they are present. -- justin
Hi Justin, Max:
It looks like "get-py-info.py" does not explicitly link Subversion
against libpython. For most people, this works fine, but it's still a
bug. Previously, this bug was hidden because we indirectly link to
libpython when we use the SWIG 1.3.19-1.3.21 runtime libraries.
In r10450, Max Bowsher patched "get-py-info.py" to explicitly link
Subversion against libpython on the Cygwin platform. In this patch, I
have upgraded Max's code to run on all platforms. I have also upgraded
Max's code to be compatible with Python 2.2.
Justin, does this solve your problem?
[[[
* build/get-py-info.py:
(ldshared_process): Explicitly link the python bindings against
libpython.
]]]
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
Re: [PATCH] Link Python bindings against platform-specific library directory v4 (was: Re: [PATCH] Explicitly link the python bindings against libpython (was: Re: Major upgrades to SWIG/Python bindings in r15848))
Posted by David James <ja...@gmail.com>.
On 8/29/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> --On August 28, 2005 5:19:29 PM -0400 David James <ja...@gmail.com> wrote:
>
> > Hi Justin,
> >
> > I've upgraded my patch to follow your advice. This patch should work
> > in all of our build scenarios now. Does this work for you?
>
> Yup. It looks right in my three setups. Please feel free to commit to trunk.
>
> Thanks! -- justin
Great! I've committed this in r15967.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Link Python bindings against platform-specific library
directory v4 (was: Re: [PATCH] Explicitly link the python bindings against
libpython (was: Re: Major upgrades to SWIG/Python bindings in r15848))
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 28, 2005 5:19:29 PM -0400 David James <ja...@gmail.com> wrote:
> Hi Justin,
>
> I've upgraded my patch to follow your advice. This patch should work
> in all of our build scenarios now. Does this work for you?
Yup. It looks right in my three setups. Please feel free to commit to trunk.
Thanks! -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Link Python bindings against platform-specific library directory v4 (was: Re: [PATCH] Explicitly link the python bindings against libpython (was: Re: Major upgrades to SWIG/Python bindings in r15848))
Posted by David James <ja...@gmail.com>.
On 8/28/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> Yup, if we meet all of these scenarios with the same code, we'll be
> doin' good. =)
Hi Justin,
I've upgraded my patch to follow your advice. This patch should work
in all of our build scenarios now. Does this work for you?
[[[
Fix python library options when we have separate platform-specific
library directories, or when we are compiling on Mac OS X without a
framework.
* build/get-py-info.py:
(string): Remove include.
(ldshared_process): Remove function.
(add_option): New function. Adds an option to a list of options.
(add_option_if_missing): New function. Adds an option to a list of
options, if it is not already present.
(link_options): New function. Gets a list of the Python linker options.
(lib_options): New function. Gets a list of the Python library options.
(__main__): Use link_options and lib_options instead of ldshared_process.
]]
Thanks for your help!
David
> On Sun, Aug 28, 2005 at 02:02:04PM -0400, David James wrote:
> > On 8/28/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> > > > Justin, does this patch work better?
> > >
> > > Nope. Here's some pointers as to what I'm getting and what's incorrect with
> > > each output with your patch. (Trunk emits correct output in each case for me.)
> > Thanks! This is very helpful. Before I write another patch, I'll have
> > to figure out what I'm supposed to be outputting on each platform.
> > I'll do this below. Let me know whether you think the proposed output
> > is good.
> >
> > > Mac OS X 10.4:
> > >
> > > % python ./build/get-py-info.py --link
> > > gcc -Wl,-F. -Wl,-F. -bundle -undefined dynamic_lookup
> > > -Wl,-F/System/Library/Frameworks -framework Python
> > > % python ./build/get-py-info.py --libs
> > > -Wl,-F. -Wl,-F. -bundle -Wl,-F/System/Library/Frameworks -framework
> > >
> > > We don't need -F/System/Library/Frameworks, but that's minor.
> > Currently, I add in a "-F" statement with the framework prefix. Is
> > this ever necessary?
>
> Only if it isn't /System/Library/Frameworks - it's like /usr/lib in the
> sense that it's in the 'default' lookup path.
>
> > Here's a few examples where the trunk code doesn't work. I'll show the
> > output of "get-py-info.py --libs" in each case.
> >
> > ---
> > Linux, architecture-dependent library directory, no DSO:
> > NOTE: Static library is stored in /pkgs/python-2.3.4/linux/lib/config
> > Trunk (doesn't work):
> > -L/pkgs/python-2.3.4/lib/python2.3/config -lpython2.3
> > Proposed output (works):
> > -L/pkgs/python-2.3.4/linux/lib/config -lpython2.3
> >
> > ---
> > Solaris, architecture-dependent library directory, no DSO:
> > NOTE: Static library is stored in /pkgs/python-2.3.4/sunos5/lib/python2.3/config
> > Trunk (I assume this doesn't work):
> > -L/cs/src/ddd-3.3.1/readline
> > -L/pkgs/python-2.3.4/lib/python2.3/config -lpython2.3
> > Proposed output (I assume this works):
> > -L/cs/src/ddd-3.3.1/readline
> > -L/pkgs/python-2.3.4/sunos5/lib/python2.3/config -lpython2.3
> >
> > ---
> > Mac OS X, no framework:
> >
> > Trunk (doesn't work, because there is no python2.2 library):
> > -L/usr/lib/python2.2/config -lpython2.2
> > Proposed output (works):
> > -bundle -flat_namespace -undefined suppress -bundle_loader /usr/bin/python
> >
> > ("-bundle -flat_namespace -undefined suppress" is unnecessary, but
> > these arguments are specified in the Python LDSHARED linker options
> > for Python 2.2, so I figure it's a good idea to leave them alone.)
>
> Yah, let's not try to second-guess what is in LDSHARED in the Makefile.
>
> > ---
> > Mac OS X 10.4:
> > NOTE: Framework prefix is /pkgs/python-2.3.4/framework
> > Trunk (This works, but it's missing the dynamic_lookup option):
> > -framework Python
> > Proposed output (Better?):
> > -Wl,-F. -Wl,-F. -bundle -undefined dynamic_lookup -framework Python
> >
> > ("-Wl,-F. -Wl,-F. -bundle -undefined dynamic_lookup" are specified by
> > the LDSHARED linker options, and I believe they allow for better
> > portability.)
>
> *nod*
>
> > ---
> > Linux, home dir install, no DSO:
> > NOTE: Static library is stored in /h/46/james/lib/python2.4/config
> > Trunk (works):
> > -L/h/46/james/lib/python2.4/config -lpython2.4
> > Proposed output: Same output.
> >
> > ---
> > Linux, full install, no DSO:
> > NOTE: Static library is stored in /usr/lib/python2.2/config
> > Trunk (works):
> > -L/usr/lib/python2.2/config -lpython2.2
> > Proposed output: Same output.
>
--
David James -- http://www.cs.toronto.edu/~james
Re: [PATCH] Link Python bindings against platform-specific library directory v3 (was: Re: [PATCH] Explicitly link the python bindings against libpython (was: Re: Major upgrades to SWIG/Python bindings in r15848))
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sun, Aug 28, 2005 at 02:02:04PM -0400, David James wrote:
> On 8/28/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> > > Justin, does this patch work better?
> >
> > Nope. Here's some pointers as to what I'm getting and what's incorrect with
> > each output with your patch. (Trunk emits correct output in each case for me.)
> Thanks! This is very helpful. Before I write another patch, I'll have
> to figure out what I'm supposed to be outputting on each platform.
> I'll do this below. Let me know whether you think the proposed output
> is good.
>
> > Mac OS X 10.4:
> >
> > % python ./build/get-py-info.py --link
> > gcc -Wl,-F. -Wl,-F. -bundle -undefined dynamic_lookup
> > -Wl,-F/System/Library/Frameworks -framework Python
> > % python ./build/get-py-info.py --libs
> > -Wl,-F. -Wl,-F. -bundle -Wl,-F/System/Library/Frameworks -framework
> >
> > We don't need -F/System/Library/Frameworks, but that's minor.
> Currently, I add in a "-F" statement with the framework prefix. Is
> this ever necessary?
Only if it isn't /System/Library/Frameworks - it's like /usr/lib in the
sense that it's in the 'default' lookup path.
> Here's a few examples where the trunk code doesn't work. I'll show the
> output of "get-py-info.py --libs" in each case.
>
> ---
> Linux, architecture-dependent library directory, no DSO:
> NOTE: Static library is stored in /pkgs/python-2.3.4/linux/lib/config
> Trunk (doesn't work):
> -L/pkgs/python-2.3.4/lib/python2.3/config -lpython2.3
> Proposed output (works):
> -L/pkgs/python-2.3.4/linux/lib/config -lpython2.3
>
> ---
> Solaris, architecture-dependent library directory, no DSO:
> NOTE: Static library is stored in /pkgs/python-2.3.4/sunos5/lib/python2.3/config
> Trunk (I assume this doesn't work):
> -L/cs/src/ddd-3.3.1/readline
> -L/pkgs/python-2.3.4/lib/python2.3/config -lpython2.3
> Proposed output (I assume this works):
> -L/cs/src/ddd-3.3.1/readline
> -L/pkgs/python-2.3.4/sunos5/lib/python2.3/config -lpython2.3
>
> ---
> Mac OS X, no framework:
>
> Trunk (doesn't work, because there is no python2.2 library):
> -L/usr/lib/python2.2/config -lpython2.2
> Proposed output (works):
> -bundle -flat_namespace -undefined suppress -bundle_loader /usr/bin/python
>
> ("-bundle -flat_namespace -undefined suppress" is unnecessary, but
> these arguments are specified in the Python LDSHARED linker options
> for Python 2.2, so I figure it's a good idea to leave them alone.)
Yah, let's not try to second-guess what is in LDSHARED in the Makefile.
> ---
> Mac OS X 10.4:
> NOTE: Framework prefix is /pkgs/python-2.3.4/framework
> Trunk (This works, but it's missing the dynamic_lookup option):
> -framework Python
> Proposed output (Better?):
> -Wl,-F. -Wl,-F. -bundle -undefined dynamic_lookup -framework Python
>
> ("-Wl,-F. -Wl,-F. -bundle -undefined dynamic_lookup" are specified by
> the LDSHARED linker options, and I believe they allow for better
> portability.)
*nod*
> ---
> Linux, home dir install, no DSO:
> NOTE: Static library is stored in /h/46/james/lib/python2.4/config
> Trunk (works):
> -L/h/46/james/lib/python2.4/config -lpython2.4
> Proposed output: Same output.
>
> ---
> Linux, full install, no DSO:
> NOTE: Static library is stored in /usr/lib/python2.2/config
> Trunk (works):
> -L/usr/lib/python2.2/config -lpython2.2
> Proposed output: Same output.
Yup, if we meet all of these scenarios with the same code, we'll be
doin' good. =)
Thanks. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Link Python bindings against platform-specific library directory v3 (was: Re: [PATCH] Explicitly link the python bindings against libpython (was: Re: Major upgrades to SWIG/Python bindings in r15848))
Posted by David James <ja...@gmail.com>.
On 8/28/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> > Justin, does this patch work better?
>
> Nope. Here's some pointers as to what I'm getting and what's incorrect with
> each output with your patch. (Trunk emits correct output in each case for me.)
Thanks! This is very helpful. Before I write another patch, I'll have
to figure out what I'm supposed to be outputting on each platform.
I'll do this below. Let me know whether you think the proposed output
is good.
> Mac OS X 10.4:
>
> % python ./build/get-py-info.py --link
> gcc -Wl,-F. -Wl,-F. -bundle -undefined dynamic_lookup
> -Wl,-F/System/Library/Frameworks -framework Python
> % python ./build/get-py-info.py --libs
> -Wl,-F. -Wl,-F. -bundle -Wl,-F/System/Library/Frameworks -framework
>
> We don't need -F/System/Library/Frameworks, but that's minor.
Currently, I add in a "-F" statement with the framework prefix. Is
this ever necessary?
> The big problem is that --libs doesn't have '-framework Python'
Oops. I'll fix this in my next patch.
> Solaris 10:
>
> % python get-py-info.py --link
> cc -G -L/pkg/python-2.4/lib -L/pkg/python-2.4/lib/python2.4/config -lpython2.4
> % python get-py-info.py --libs
> -L/pkg/python-2.4/lib -L/pkg/python-2.4/lib/python2.4/config -lpython2.4
>
> We don't need '-L/pkg/python-2.4/lib' as there's nothing in there.
Okay, I'll implement this.
> % python get-py-info.py --link
> gcc -pthread -shared -L/usr/lib/python2.4/config -lpython2.4
> % python get-py-info.py --libs
> -L/usr/lib/python2.4/config -lpython2.4
>
> Again, this is wrong. It should prefer the DSO sitting in /usr/lib. The
> 'correct' output for Ubuntu would be (and this is what trunk emits):
> % python ./build/get-py-info.py --link
> gcc -pthread -shared -lpython2.4
> % python ./build/get-py-info.py --libs
> -lpython2.4
Okay, I'll implement this.
> The version of get-py-info.py in trunk has some stat()'s to try to prevent us
> from emitting bogus paths and to explicitly prefer DSOs over .a files.
Here's a few examples where the trunk code doesn't work. I'll show the
output of "get-py-info.py --libs" in each case.
---
Linux, architecture-dependent library directory, no DSO:
NOTE: Static library is stored in /pkgs/python-2.3.4/linux/lib/config
Trunk (doesn't work):
-L/pkgs/python-2.3.4/lib/python2.3/config -lpython2.3
Proposed output (works):
-L/pkgs/python-2.3.4/linux/lib/config -lpython2.3
---
Solaris, architecture-dependent library directory, no DSO:
NOTE: Static library is stored in /pkgs/python-2.3.4/sunos5/lib/python2.3/config
Trunk (I assume this doesn't work):
-L/cs/src/ddd-3.3.1/readline
-L/pkgs/python-2.3.4/lib/python2.3/config -lpython2.3
Proposed output (I assume this works):
-L/cs/src/ddd-3.3.1/readline
-L/pkgs/python-2.3.4/sunos5/lib/python2.3/config -lpython2.3
---
Mac OS X, no framework:
Trunk (doesn't work, because there is no python2.2 library):
-L/usr/lib/python2.2/config -lpython2.2
Proposed output (works):
-bundle -flat_namespace -undefined suppress -bundle_loader /usr/bin/python
("-bundle -flat_namespace -undefined suppress" is unnecessary, but
these arguments are specified in the Python LDSHARED linker options
for Python 2.2, so I figure it's a good idea to leave them alone.)
---
Mac OS X 10.4:
NOTE: Framework prefix is /pkgs/python-2.3.4/framework
Trunk (This works, but it's missing the dynamic_lookup option):
-framework Python
Proposed output (Better?):
-Wl,-F. -Wl,-F. -bundle -undefined dynamic_lookup -framework Python
("-Wl,-F. -Wl,-F. -bundle -undefined dynamic_lookup" are specified by
the LDSHARED linker options, and I believe they allow for better
portability.)
---
Linux, home dir install, no DSO:
NOTE: Static library is stored in /h/46/james/lib/python2.4/config
Trunk (works):
-L/h/46/james/lib/python2.4/config -lpython2.4
Proposed output: Same output.
---
Linux, full install, no DSO:
NOTE: Static library is stored in /usr/lib/python2.2/config
Trunk (works):
-L/usr/lib/python2.2/config -lpython2.2
Proposed output: Same output.
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Link Python bindings against platform-specific library
directory v3 (was: Re: [PATCH] Explicitly link the python bindings against
libpython (was: Re: Major upgrades to SWIG/Python bindings in r15848))
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 28, 2005 2:29:33 AM -0400 David James <ja...@gmail.com> wrote:
> Justin, does this patch work better?
Nope. Here's some pointers as to what I'm getting and what's incorrect with
each output with your patch. (Trunk emits correct output in each case for me.)
Mac OS X 10.4:
% python ./build/get-py-info.py --link
gcc -Wl,-F. -Wl,-F. -bundle -undefined dynamic_lookup
-Wl,-F/System/Library/Frameworks -framework Python
% python ./build/get-py-info.py --libs
-Wl,-F. -Wl,-F. -bundle -Wl,-F/System/Library/Frameworks -framework
We don't need -F/System/Library/Frameworks, but that's minor. The big problem
is that --libs doesn't have '-framework Python'
Solaris 10:
% python get-py-info.py --link
cc -G -L/pkg/python-2.4/lib -L/pkg/python-2.4/lib/python2.4/config -lpython2.4
% python get-py-info.py --libs
-L/pkg/python-2.4/lib -L/pkg/python-2.4/lib/python2.4/config -lpython2.4
We don't need '-L/pkg/python-2.4/lib' as there's nothing in there.
% python get-py-info.py --link
gcc -pthread -shared -L/usr/lib/python2.4/config -lpython2.4
% python get-py-info.py --libs
-L/usr/lib/python2.4/config -lpython2.4
Again, this is wrong. It should prefer the DSO sitting in /usr/lib. The
'correct' output for Ubuntu would be (and this is what trunk emits):
% python ./build/get-py-info.py --link
gcc -pthread -shared -lpython2.4
% python ./build/get-py-info.py --libs
-lpython2.4
The version of get-py-info.py in trunk has some stat()'s to try to prevent us
from emitting bogus paths and to explicitly prefer DSOs over .a files.
HTH. Thanks. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Link Python bindings against platform-specific library directory v3 (was: Re: [PATCH] Explicitly link the python bindings against libpython (was: Re: Major upgrades to SWIG/Python bindings in r15848))
Posted by David James <ja...@gmail.com>.
On 8/27/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Sat, Aug 27, 2005 at 05:07:48PM -0400, David James wrote:
> > Great work, Justin! Your code works great on Linux and Cygwin. I also
> > tested on Solaris and Linux with separate platform-specific library
> > directories -- this caused a few problems. I've attached a patch to
> > fix this.
> >
> > I've checked the output of "get-py-info.py" on the following platforms:
> > - Shared libpython DSO / Python 2.2 (Redhat Linux 2.4)
> > - Shared libpython DLL / Python 2.4 (Cygwin)
> > - Custom-built Python 2.4 (Redhat Linux 2.4)
> > - Shared libpython DSO in separate platform-specific library
> > directories (Solaris / Python 2.2, Solaris / Python 2.3, Linux /
> > Python 2.3)
> >
> > The "Shared libpython DSO in separate platform-specific library
> > directories" test case only works with the following patch.
>
> This breaks on Ubuntu as it stores the DSO in $libdir/libpython2.4.so
> not in $libdir/python2.4/config/libpython2.4.so. (LIBP is set to
> $libdir/python2.4/config on Ubuntu.)
>
> Any thoughts? -- justin
Justin, does this patch work better?
[[[
Fix python library options when we have separate platform-specific
library directories, or when we are compiling on Mac OS X without a
framework.
Tested on:
- Shared libpython DSO / Python 2.2 (Redhat Linux 2.4)
- Shared libpython DLL / Python 2.4 (Cygwin)
- Custom-built Python 2.4 (Redhat Linux 2.4)
- Shared libpython DSO in separate platform-specific library
directories (Solaris / Python 2.2, Solaris / Python 2.3, Linux /
Python 2.3)
- Mac OS X without a framework (Mac OS X 10.2 / Python 2.2)
* build/get-py-info.py:
(string): Remove include.
(ldshared_process): Remove function.
(remove_option): New function. Removes an option from a list of options.
(add_option): New function. Adds an option to a list of options.
(link_options): New function. Gets a list of the Python linker options.
(lib_options): New function. Gets a list of the Python library options.
(__main__): Use link_options and lib_options instead of ldshared_process.
]]
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
Re: [PATCH] Link Python bindings against platform-specific library directory (was: Re: [PATCH] Explicitly link the python bindings against libpython (was: Re: Major upgrades to SWIG/Python bindings in r15848))
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sat, Aug 27, 2005 at 05:07:48PM -0400, David James wrote:
> Great work, Justin! Your code works great on Linux and Cygwin. I also
> tested on Solaris and Linux with separate platform-specific library
> directories -- this caused a few problems. I've attached a patch to
> fix this.
>
> I've checked the output of "get-py-info.py" on the following platforms:
> - Shared libpython DSO / Python 2.2 (Redhat Linux 2.4)
> - Shared libpython DLL / Python 2.4 (Cygwin)
> - Custom-built Python 2.4 (Redhat Linux 2.4)
> - Shared libpython DSO in separate platform-specific library
> directories (Solaris / Python 2.2, Solaris / Python 2.3, Linux /
> Python 2.3)
>
> The "Shared libpython DSO in separate platform-specific library
> directories" test case only works with the following patch.
This breaks on Ubuntu as it stores the DSO in $libdir/libpython2.4.so
not in $libdir/python2.4/config/libpython2.4.so. (LIBP is set to
$libdir/python2.4/config on Ubuntu.)
Any thoughts? -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] Link Python bindings against platform-specific library directory (was: Re: [PATCH] Explicitly link the python bindings against libpython (was: Re: Major upgrades to SWIG/Python bindings in r15848))
Posted by David James <ja...@gmail.com>.
On 8/27/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> --On August 27, 2005 1:10:14 PM -0400 David James <ja...@gmail.com> wrote:
>
> > It looks like "get-py-info.py" does not explicitly link Subversion
> > against libpython. For most people, this works fine, but it's still a
> > bug. Previously, this bug was hidden because we indirectly link to
> > libpython when we use the SWIG 1.3.19-1.3.21 runtime libraries.
> >
> > In r10450, Max Bowsher patched "get-py-info.py" to explicitly link
> > Subversion against libpython on the Cygwin platform. In this patch, I
> > have upgraded Max's code to run on all platforms. I have also upgraded
> > Max's code to be compatible with Python 2.2.
> >
> > Justin, does this solve your problem?
>
> It pointed me in the right direction as to how you thought it should be
> solved. I committed this patch with my modifications in r15943 to trunk.
>
> get-py-info.py outputs the right info for me on Solaris (self-compiled Python
> & /usr/sfw/python), Ubuntu Linux (which provides a shared libpython DSO), and
> Mac OS X (which uses frameworks). I confirmed it now builds and links
> correctly on Solaris.
>
> Please give it a go on your platforms to make sure I didn't bust something
> else. ;-)
Great work, Justin! Your code works great on Linux and Cygwin. I also
tested on Solaris and Linux with separate platform-specific library
directories -- this caused a few problems. I've attached a patch to
fix this.
I've checked the output of "get-py-info.py" on the following platforms:
- Shared libpython DSO / Python 2.2 (Redhat Linux 2.4)
- Shared libpython DLL / Python 2.4 (Cygwin)
- Custom-built Python 2.4 (Redhat Linux 2.4)
- Shared libpython DSO in separate platform-specific library
directories (Solaris / Python 2.2, Solaris / Python 2.3, Linux /
Python 2.3)
The "Shared libpython DSO in separate platform-specific library
directories" test case only works with the following patch.
[[[
build/get-py-info.py:
* (ldshared_process): Update libdir to contain the Python standard library
directory, as calculated using the "LIBPL" config variable. Use
-lpython2.x to import python libraries on all platforms.
]]]
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
Re: [PATCH] Explicitly link the python bindings against libpython
(was: Re: Major upgrades to SWIG/Python bindings in r15848)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On August 27, 2005 1:10:14 PM -0400 David James <ja...@gmail.com> wrote:
> It looks like "get-py-info.py" does not explicitly link Subversion
> against libpython. For most people, this works fine, but it's still a
> bug. Previously, this bug was hidden because we indirectly link to
> libpython when we use the SWIG 1.3.19-1.3.21 runtime libraries.
>
> In r10450, Max Bowsher patched "get-py-info.py" to explicitly link
> Subversion against libpython on the Cygwin platform. In this patch, I
> have upgraded Max's code to run on all platforms. I have also upgraded
> Max's code to be compatible with Python 2.2.
>
> Justin, does this solve your problem?
It pointed me in the right direction as to how you thought it should be
solved. I committed this patch with my modifications in r15943 to trunk.
get-py-info.py outputs the right info for me on Solaris (self-compiled Python
& /usr/sfw/python), Ubuntu Linux (which provides a shared libpython DSO), and
Mac OS X (which uses frameworks). I confirmed it now builds and links
correctly on Solaris.
Please give it a go on your platforms to make sure I didn't bust something
else. ;-)
Thanks. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org