|
Boost-Build : |
From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2006-09-29 08:13:54
Vladimir Prus wrote:
> On Friday 29 September 2006 13:56, Markus Schöpflin wrote:
>
>>> 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.
>
> Is there some "standard" Python package for this system? We can add -lz, of
> course, but the fact that python is built in different way on different boxes
> is concerning.
Well, there is a python RPM in the 'Open Source Software Collection for
Tru64 UNIX' provided by HP. But it's python version 2.0, so I don't know if
it's of any relevance to the discussion. This aside, it doesn't have the
dependency on libz.
> If the "standard" Python lib includes libz inside it, then can you try
> rebuilding Python and rerunning the tests?
I will rebuild and reinstall my local python installation using a dynamic
libz when the current regression run is finished.
This discussion makes me wonder why other systems are not affected by the
same problem. There is nothing Tru64 specific at the root cause of this.
Markus
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk