How to deal with debug-python?

I've recently discovered that ubuntu has a python-dbg
package that,
unlike every other *nix installation, helpfully follows the
Windows
convention of requiring the "_d" suffix on
extension modules
(https://wiki.ubun
tu.com/PyDbgBuilds).

There doesn't seem to be any way to probe for that, so we
need a way
to allow the user to specify a suffix that will be added to
extension
module names for a particular installation of python
(assuming that
multiple pythons can be configured).  I'm not sure about the
correct
way to handle this.  Should the suffix be a feature?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

David Abrahams wrote:
> [...]                Should the suffix be a feature?

I think, it is a good idea. On HP-UX, the suffix is a
function of
python version: starting with Python 2.5, python uses .so
suffix
while pre-2.5 versions use .sl suffix.

I've submitted a patch for python.jam which, for HP-UX,
determines
the suffix based on python version. If the suffix was a
feature, no
run-time selection would be necessary. The patch has not
been applied
and now, after python.jam was almost completely revamped,
this patch
is irrelevant.

Since I'm using Python 2.5 for boost testing on HP-UX, this
is not an
issue for me. It can be an issue for HP customers using
python version
prior to 2.5. Making suffix a feature would solve this
problem.

Thanks,
  Boris

----- Original Message ----- 
From: "David Abrahams" <daveboost-consulting.com>
To: <boost-buildlists.boost.org>
Sent: Thursday, March 22, 2007 11:47 AM
Subject: [Boost-build] How to deal with debug-python?


>
> I've recently discovered that ubuntu has a python-dbg
package that,
> unlike every other *nix installation, helpfully follows
the Windows
> convention of requiring the "_d" suffix on
extension modules
> (https://wiki.ubun
tu.com/PyDbgBuilds).
>
> There doesn't seem to be any way to probe for that, so
we need a way
> to allow the user to specify a suffix that will be
added to extension
> module names for a particular installation of python
(assuming that
> multiple pythons can be configured).  I'm not sure
about the correct
> way to handle this.  Should the suffix be a feature?
>
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
>
> 


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

on Thu Mar 22 2007, "Boris Gubenko"
<Boris.Gubenko-AT-hp.com> wrote:

> David Abrahams wrote:
>> [...]                Should the suffix be a
feature?
>
> I think, it is a good idea. On HP-UX, the suffix is a
function of
> python version: starting with Python 2.5, python uses
.so suffix
> while pre-2.5 versions use .sl suffix.

Oof.  That's a different suffix.  BBv2 is designed so that
when you
"set-generated-target-suffix" (etc.) you only
specify the part after
the dot.  Unfortunately that means I need a different
mechanism
altogether for handling "_d.so"

> I've submitted a patch for python.jam which, for HP-UX,
determines
> the suffix based on python version. If the suffix was a
feature, no
> run-time selection would be necessary. The patch has
not been applied
> and now, after python.jam was almost completely
revamped, this patch
> is irrelevant.
>
> Since I'm using Python 2.5 for boost testing on HP-UX,
this is not an
> issue for me. It can be an issue for HP customers using
python version
> prior to 2.5. Making suffix a feature would solve this
problem.

Could you try this patch while using a Python version prior
to 2.5?

Thanks,






-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

David Abrahams wrote:
>
> Could you try this patch while using a Python version
prior to 2.5?

I'll do it and report back. The build is running now and
when it is
complete, I'll try the patch. Just python library build and
tests will
be enough, right?

Thanks,
  Boris

----- Original Message ----- 
From: "David Abrahams" <daveboost-consulting.com>
To: <boost-buildlists.boost.org>
Sent: Thursday, March 22, 2007 4:21 PM
Subject: Re: [Boost-build] How to deal with debug-python?


>
> on Thu Mar 22 2007, "Boris Gubenko"
<Boris.Gubenko-AT-hp.com> wrote:
>
>> David Abrahams wrote:
>>> [...]                Should the suffix be a
feature?
>>
>> I think, it is a good idea. On HP-UX, the suffix is
a function of
>> python version: starting with Python 2.5, python
uses .so suffix
>> while pre-2.5 versions use .sl suffix.
>
> Oof.  That's a different suffix.  BBv2 is designed so
that when you
> "set-generated-target-suffix" (etc.) you only
specify the part after
> the dot.  Unfortunately that means I need a different
mechanism
> altogether for handling "_d.so"
>
>> I've submitted a patch for python.jam which, for
HP-UX, determines
>> the suffix based on python version. If the suffix
was a feature, no
>> run-time selection would be necessary. The patch
has not been applied
>> and now, after python.jam was almost completely
revamped, this patch
>> is irrelevant.
>>
>> Since I'm using Python 2.5 for boost testing on
HP-UX, this is not an
>> issue for me. It can be an issue for HP customers
using python version
>> prior to 2.5. Making suffix a feature would solve
this problem.
>
> Could you try this patch while using a Python version
prior to 2.5?
>
> Thanks,
>
>
>


------------------------------------------------------------
--------------------


> --- python.jam 22 Mar 2007 08:22:48 -0400 1.12.2.43
> +++ python.jam 22 Mar 2007 16:20:21 -0400
>  -904,6 +904,15 
> type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>windows : pyd ;
> type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>cygwin : dll ;
>
> +# Prior to python 2.5, HPUX extension modules had a
".sl" extension
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>2.4 : sl ;
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>2.3 : sl ;
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>2.2 : sl ;
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>2.1 : sl ;
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>2.0 : sl ;
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>1.6 : sl ;
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>1.5 : sl ;
> +
> # Unset 'lib' prefix for PYTHON_EXTENSION
> type.set-generated-target-prefix PYTHON_EXTENSION : :
"" ;
>
>


------------------------------------------------------------
--------------------


>
>
>
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>


------------------------------------------------------------
--------------------


> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
> 


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

David Abrahams wrote:
>
> Could you try this patch while using a Python version
prior to 2.5?

I tried it with Python 2.4.3 and it worked like a champ. I
did not do
the full build, I downloaded fresh 1.34 from cvs, applied
the patch,
ran python library tests and they all succeeded. The suffix
on test
images was ".sl", as expected. Thanks for the
patch!

While we are dealing with HP-UX - specific code in
python.jam, can
you do me a favour and remove 'pthread' on line 602:

        case hpux : return pthread rt ;

It was me who added 'pthread' in the previous incarnation of
python.jam:

        case HPUX :
        {
            extra-libs = pthread rt ;
        }

and it was a mistake. As stated in

  <htt
p://docs.hp.com/en/8759/options.htm#opt-mt>

the aC++ driver takes care of linking against pthread
library when
appropriate. In the best case, explicit -lpthread is
redundant. In
the worst case, if the program was compiled without -mt,
forcing
pthread to the link is illegal and may lead to runtime
error:

  aCC runtime: Use of "-mt" must be consistent
during both compilation
  and linking.

If you could remove this erroneous 'pthread' on line 602, it
would be
great. It is a safe change because it only affects HP-UX
platform.

Thanks again,
  Boris

----- Original Message ----- 
From: "David Abrahams" <daveboost-consulting.com>
To: <boost-buildlists.boost.org>
Sent: Thursday, March 22, 2007 4:21 PM
Subject: Re: [Boost-build] How to deal with debug-python?


>
> on Thu Mar 22 2007, "Boris Gubenko"
<Boris.Gubenko-AT-hp.com> wrote:
>
>> David Abrahams wrote:
>>> [...]                Should the suffix be a
feature?
>>
>> I think, it is a good idea. On HP-UX, the suffix is
a function of
>> python version: starting with Python 2.5, python
uses .so suffix
>> while pre-2.5 versions use .sl suffix.
>
> Oof.  That's a different suffix.  BBv2 is designed so
that when you
> "set-generated-target-suffix" (etc.) you only
specify the part after
> the dot.  Unfortunately that means I need a different
mechanism
> altogether for handling "_d.so"
>
>> I've submitted a patch for python.jam which, for
HP-UX, determines
>> the suffix based on python version. If the suffix
was a feature, no
>> run-time selection would be necessary. The patch
has not been applied
>> and now, after python.jam was almost completely
revamped, this patch
>> is irrelevant.
>>
>> Since I'm using Python 2.5 for boost testing on
HP-UX, this is not an
>> issue for me. It can be an issue for HP customers
using python version
>> prior to 2.5. Making suffix a feature would solve
this problem.
>
> Could you try this patch while using a Python version
prior to 2.5?
>
> Thanks,
>
>
>


------------------------------------------------------------
--------------------


> --- python.jam 22 Mar 2007 08:22:48 -0400 1.12.2.43
> +++ python.jam 22 Mar 2007 16:20:21 -0400
>  -904,6 +904,15 
> type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>windows : pyd ;
> type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>cygwin : dll ;
>
> +# Prior to python 2.5, HPUX extension modules had a
".sl" extension
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>2.4 : sl ;
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>2.3 : sl ;
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>2.2 : sl ;
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>2.1 : sl ;
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>2.0 : sl ;
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>1.6 : sl ;
> +type.set-generated-target-suffix PYTHON_EXTENSION :
<target-os>hpux 
> <python>1.5 : sl ;
> +
> # Unset 'lib' prefix for PYTHON_EXTENSION
> type.set-generated-target-prefix PYTHON_EXTENSION : :
"" ;
>
>


------------------------------------------------------------
--------------------


>
>
>
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>


------------------------------------------------------------
--------------------


> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
> 


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

on Fri Mar 23 2007, "Boris Gubenko"
<Boris.Gubenko-AT-hp.com> wrote:

> While we are dealing with HP-UX - specific code in
python.jam, can
> you do me a favour and remove 'pthread' on line 602:
>
>         case hpux : return pthread rt ;
>
> It was me who added 'pthread' in the previous
incarnation of python.jam:
>
>         case HPUX :
>         {
>             extra-libs = pthread rt ;
>         }
>
> and it was a mistake. As stated in
>
>   <htt
p://docs.hp.com/en/8759/options.htm#opt-mt>
>
> the aC++ driver takes care of linking against pthread
library when
> appropriate. In the best case, explicit -lpthread is
redundant. In
> the worst case, if the program was compiled without
-mt, forcing
> pthread to the link is illegal and may lead to runtime
error:
>
>   aCC runtime: Use of "-mt" must be
consistent during both compilation
>   and linking.
>
> If you could remove this erroneous 'pthread' on line
602, it would be
> great. It is a safe change because it only affects
HP-UX platform.

Is GCC available on HPUX and if people use gcc there does
the same
logic apply?  Or do I need 

   <toolset>gcc:<library>pthread

??

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

David Abrahams wrote:
> Is GCC available on HPUX and if people use gcc there
does the same
> logic apply?

  GCC is available on HP-UX and the same logic applies. From
g++ manpage:

      -pthreads
          Add support for multithreading using the POSIX
threads library.
          This option sets flags for both the preprocessor
and linker. This
          option does not affect the thread safety of object
code produced
          by the compiler or that of libraries supplied with
it.

  A quick experiment confirms that, like aC++, g++
automatically adds
  pthread library to the link when compiled/linked
-pthread:

bash-2.03$ g++ -v x.o 2>&1 | (grep -q
"-lpthread" ; echo $?)
1
bash-2.03$ g++ -v x.o 2>&1 -pthread | (grep -q
"-lpthread" ; echo $?)
0
bash-2.03$

> Or do I need
>
>    <toolset>gcc:<library>pthread

  No, you don't.

  Thanks for looking into it!
    Boris

----- Original Message ----- 
From: "David Abrahams" <daveboost-consulting.com>
To: <boost-buildlists.boost.org>
Sent: Friday, March 23, 2007 12:44 AM
Subject: Re: [Boost-build] How to deal with debug-python?


>
> on Fri Mar 23 2007, "Boris Gubenko"
<Boris.Gubenko-AT-hp.com> wrote:
>
>> While we are dealing with HP-UX - specific code in
python.jam, can
>> you do me a favour and remove 'pthread' on line
602:
>>
>>         case hpux : return pthread rt ;
>>
>> It was me who added 'pthread' in the previous
incarnation of python.jam:
>>
>>         case HPUX :
>>         {
>>             extra-libs = pthread rt ;
>>         }
>>
>> and it was a mistake. As stated in
>>
>>   <htt
p://docs.hp.com/en/8759/options.htm#opt-mt>
>>
>> the aC++ driver takes care of linking against
pthread library when
>> appropriate. In the best case, explicit -lpthread
is redundant. In
>> the worst case, if the program was compiled without
-mt, forcing
>> pthread to the link is illegal and may lead to
runtime error:
>>
>>   aCC runtime: Use of "-mt" must be
consistent during both compilation
>>   and linking.
>>
>> If you could remove this erroneous 'pthread' on
line 602, it would be
>> great. It is a safe change because it only affects
HP-UX platform.
>
> Is GCC available on HPUX and if people use gcc there
does the same
> logic apply?  Or do I need
>
>   <toolset>gcc:<library>pthread
>
> ??
>
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
>
> 


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

on Fri Mar 23 2007, "Boris Gubenko"
<Boris.Gubenko-AT-hp.com> wrote:

>> Or do I need
>>
>>    <toolset>gcc:<library>pthread
>
>   No, you don't.

patched.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

David Abrahams wrote:
> patched.

Thanks!
-boris

----- Original Message ----- 
From: "David Abrahams" <daveboost-consulting.com>
To: <boost-buildlists.boost.org>
Sent: Friday, March 23, 2007 9:35 AM
Subject: Re: [Boost-build] How to deal with debug-python?


>
> on Fri Mar 23 2007, "Boris Gubenko"
<Boris.Gubenko-AT-hp.com> wrote:
>
>>> Or do I need
>>>
>>>    <toolset>gcc:<library>pthread
>>
>>   No, you don't.
>
> patched.
>
> -- 
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost-build
>
> 


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build