I don't know whether this has ben mentioned already on this list, but
also Python has problems with Debian multi-arch. Python doesn't know
that it has to look in /usr/lib/i386-linux-gnu for libraries, so
building the crypt module fails and building some of the hash functions
for hashlib fails.
Setting LD_LIBRARY_PATH and LIBRARY_PATH doesn't help.
Symlinking libcrypt.so and libssl.so into $SAGE_LOCAL/lib does help.
> I don't know whether this has ben mentioned already on this list, but
> also Python has problems with Debian multi-arch. Python doesn't know
> that it has to look in /usr/lib/i386-linux-gnu for libraries, so
> building the crypt module fails and building some of the hash
> functions for hashlib fails.
> Setting LD_LIBRARY_PATH and LIBRARY_PATH doesn't help.
> Symlinking libcrypt.so and libssl.so into $SAGE_LOCAL/lib does help.
> We really have to patch every single Python package? That's awful.
No, only python packages which insist on overriding lib paths, because that means even a patched compiler/interpreter which knows where to look, will still fail because of the override.
> If only distutils/setuptools wouldn't be so broken... why do they > hard-code the directories to look for .so files?
[irony mode on] They know where things are supposed to be, so why not be failsafe and only look there? [irony mode off]
> On 2012-04-23 14:33, Jeroen Demeyer wrote:
> > I hate Python's installer and distutils/setuptools.
> ... but I hate it less than I hate SCons, which is broken by design,
> for example by ignoring environment variables on purpose!
On Monday, April 23, 2012 7:59:11 AM UTC-4, Snark wrote:
> No, only python packages which insist on overriding lib paths, because > that means even a patched compiler/interpreter which knows where to > look, will still fail because of the override
Yes thats awful.
It is yet another thing that could be solved once-and-for-all with the compilerwrapper ;-)
> It is yet another thing that could be solved once-and-for-all with the
> compilerwrapper ;-)
Here, this is not the case. The problem is not with gcc here, the
problem is with Python "detecting" which libraries are installed. No
compilerwrapper can solve this.
On Monday, April 23, 2012 4:50:18 PM UTC-4, Jeroen Demeyer wrote:
> On 2012-04-23 20:06, Volker Braun wrote: > > It is yet another thing that could be solved once-and-for-all with the > > compilerwrapper ;-) > Here, this is not the case. The problem is not with gcc here, the > problem is with Python "detecting" which libraries are installed. No > compilerwrapper can solve this.
