[Distutils] reservations about pythonv

[Carl Meyer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mark,

On 03/18/2011 01:46 PM, Mark Sienkiewicz wrote:
> Here is a case that might resemble what you are talking about:
> 
> Compile a C extension that requires a shared library that is not in the
> standard system path.  To import it, LD_LIBRARY_PATH needs to be right.

But this required shared library that is not on the standard system path
- - is it something that might have been installed, via Python
(distutils/setuptools/d2/packaging), in the virtualenv, where if it had
been installed in that same way in the system Python installation it
would be on the standard system path?

If so, do you have any specific examples of installable Python projects
that install a shared library that other ones might need in order to
compile, so that I can test this case and make it work?

If not, then it seems this is a general Python packaging issue, not
anything specific to this virtual-python proposal. In which case I don't
have to care, at least not just now ;-)

> This is not really different from what happens in a compiled language,
> except in one way:  In C, I can compile it -static or I can give the
> full path to the .so file.  Either results in a thing that works without
> LD_LIBRARY_PATH.
> 
> With distutils, you can't.  It goes to great lengths to ensure that you
> can only compile a C extension with "cc ... -L/some/directory -lname" --
> I can't find any way to make it do "cc ... /some/directory/libname.so"
> 
> So, the real problem here is that distutils uses "cc -L", but it
> demonstrates a case where LD_LIBRARY_PATH can be important to a python
> program even when Python itself can run without it.

Thanks!

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Dq+MACgkQFRcxmeyPUXJbHwCfa1FpWif7nRJK90EARxxs8yGq
bTMAnAxNj8eU3ohfRiCZyHOlNGIiL33T
=Zmep
-----END PGP SIGNATURE-----