py-run vs. bpl-test

Markus Schöpflin <markus.schoepflincomsoft.de> writes:

> Interestingly, all of the failing tests either use the
jam rule run or 
> py-run. All tests using the rule bpl-test are working
fine.

I think I fixed that case.

> And the toolset gcc-4.1.1_sunos_i86pc shows failures
for the same tests, 
> although the exact error is different.

I think that's a different, but related, issue.  At first I
thought
it had to do with the fact that python.jam is using
<find-shared-library> when no libpythonXX on unix is
ever shared
[Volodya, why did you specify find-shared-library there?],
but
it seems gcc doesn't distinguish between find-shared-library
and
find-static-library anyway, so that can't be the
explanation.  I've
asked Caleb to look at that failure.

> What is the intended difference between these two test
rules? 

One runs python, which dynamically loads extension modules. 
The other
runs a user program that embeds python.

> Why isn't there just one test rule?

They're totally different.

> And does anyone know why it works in one case, but not
the other?

Python is already linked with libz on those platforms where
it's
required.

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

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

David Abrahams wrote:

> Markus Schöpflin <markus.schoepflincomsoft.de> writes:
> 
>> Interestingly, all of the failing tests either use
the jam rule run or 
>> py-run. All tests using the rule bpl-test are
working fine.
> 
> I think I fixed that case.

Thank you.

[...]

> 
>> What is the intended difference between these two
test rules? 
> 
> One runs python, which dynamically loads extension
modules.  The other
> runs a user program that embeds python.

So, bpl-test runs python and run/py-run runs a user program,
right?

>> Why isn't there just one test rule?
> 
> They're totally different.
> 
>> And does anyone know why it works in one case, but
not the other?
> 
> Python is already linked with libz on those platforms
where it's
> required.

So the explanation why it works at Comsoft but not at HP
TestDrive, which 
are the same platform, is that at HP the libpython2.4.a
somehow contains 
references to libz and at Comsoft it doesn't.

HP:

 > nm libpython2.4.a | grep adler32
adler32                          | 0000000000000000 | U |
0000000000000008
 >

Comsoft:

 > nm libpython2.4.a | grep adler32
 >

Ok, I think I understood that now. This difference probably
results from 
the fact that when compiling python at the TestDrive machine
I linked libz 
statically, but not when compiling at Comsoft.

Maybe I should change that, because the static libz will
most probably not 
be found by the link process, as it's not installed in a
standard location.

Markus

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