Mark Sienkiewicz writes:
> 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.
I just discovered, in the course of repairing my "pyzmq-static" project
after the "pyzmq" folks went crazy and broke their
On 31 March 2011 13:04, Fred Drake wrote:
> On Wed, Mar 30, 2011 at 5:08 PM, kiorky wrote:
>> You have rpath to record search paths for shared libraries at link time.
>> This enables you not to set LD_LIBRARY_PATH at runtime.
>>
>> Something like "cc -Wl,-rpath,/path/to/libdir -L/path/to/libdir -
On Wed, Mar 30, 2011 at 5:08 PM, kiorky wrote:
> You have rpath to record search paths for shared libraries at link time.
> This enables you not to set LD_LIBRARY_PATH at runtime.
>
> Something like "cc -Wl,-rpath,/path/to/libdir -L/path/to/libdir -lfoo" is what
> you want.
This fails once you wa
export LDFLAGS="what i want to be in linker flags".
You have also play the LD_RUN_PATH to modify the RPATH.
See [1]
You can have a look to minitage.recipe.{common, eggs, scripts} for a good
buildout integration.
[1] - http://goo.gl/oPPj0
Le 30/03/2011 23:41, Mark Sienkiewicz a écrit :
> kiorky
You have rpath to record search paths for shared libraries at link time.
This enables you not to set LD_LIBRARY_PATH at runtime.
Something like "cc -Wl,-rpath,/path/to/libdir -L/path/to/libdir -lfoo" is what
you want.
Le 18/03/2011 18:46, Mark Sienkiewicz a écrit :
>
>> The above just means my m
kiorky wrote:
You have rpath to record search paths for shared libraries at link time.
This enables you not to set LD_LIBRARY_PATH at runtime.
Something like "cc -Wl,-rpath,/path/to/libdir -L/path/to/libdir -lfoo" is what
you want.
You left out the hard part: How do I make distutils do tha
Carl Meyer wrote:
-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 i
On Mar 20, 2011, at 01:18 AM, Leonardo Rochael Almeida wrote:
>Another variant of this case, one we're actually facing here at our
>company (Nexedi) right now, is when you need to compile extension
>modules with libraries that are newer than the ones in the system, and
>you don't have root access.
On Sun, Mar 20, 2011 at 1:48 PM, Leonardo Rochael Almeida
wrote:
> It's likely that pythonv shoudn't do anything differently, at least
> from the POV of the Python binary. I just wanted to mention a use-case
> for needing LD_LIBRARY_PATH set while running Python.
I'd agree that for the use-cases
Hi Carl,
On Sun, Mar 20, 2011 at 04:06, Carl Meyer wrote:
> Hi Leonardo,
>
> On 03/19/2011 08:18 PM, Leonardo Rochael Almeida wrote:
>> Another variant of this case, one we're actually facing here at our
>> company (Nexedi) right now, is when you need to compile extension
>> modules with librarie
Hi Leonardo,
On 03/19/2011 08:18 PM, Leonardo Rochael Almeida wrote:
> Another variant of this case, one we're actually facing here at our
> company (Nexedi) right now, is when you need to compile extension
> modules with libraries that are newer than the ones in the system, and
> you don't have r
Another variant of this case, one we're actually facing here at our
company (Nexedi) right now, is when you need to compile extension
modules with libraries that are newer than the ones in the system, and
you don't have root access. The absense of LD_LIBRARY_PATH means a
segfault on an arbitrary mo
Mark Sienkiewicz wrote:
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"
Are you sure you can't use extra_link_args for this?
-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_PA
The above just means my memory is too faulty to of much use ;). I'll just
echo Carl's request for specific cases where $LD_LIBRARY_PATH needs to be set.
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
On Mar 17, 2011, at 12:32 PM, Carl Meyer wrote:
>I also realized last night that if the need for LD_LIBRARY_PATH is as
>rare as it seems to be, people could just as well set it themselves
>before running stuff in their virtualenv. We could even have our shell
>"activate" script set it, so you'd on
On 03/17/2011 10:56 AM, Barry Warsaw wrote:
> Thanks for helping bolster my memory! I still think setting $LD_LIBRARY_PATH
> won't be necessary in the majority of cases, so generally no re-exec should
> happen. I can imagine that if it *were* necessary, an appropriate section in
> the pythonv.c
On Mar 17, 2011, at 08:36 AM, Fred Drake wrote:
>On Wed, Mar 16, 2011 at 10:39 PM, Barry Warsaw wrote:
>> I vaguely recall that while this *should* work, it actually doesn't
>> because once the executable has started, $LD_LIBRARY_PATH isn't consulted
>> again.
>
>I recall less vaguely, since we'v
On Wed, Mar 16, 2011 at 10:39 PM, Barry Warsaw wrote:
> I vaguely recall that while this *should* work, it actually doesn't
> because once the executable has started, $LD_LIBRARY_PATH isn't consulted
> again.
I recall less vaguely, since we've had to deal with this problem more
recently than your
On Mar 16, 2011, at 07:19 PM, Carl Meyer wrote:
>This alternative approach (with a symlink and config file) sounds pretty good
>to me as well after our discussion at the sprints. The downsides I see:
>
>1. Cross-platform inconsistency. Windows virtualenvs would be isolated from
>system python bina
This alternative approach (with a symlink and config file) sounds pretty good
to me as well after our discussion at the sprints. The downsides I see:
1. Cross-platform inconsistency. Windows virtualenvs would be isolated from
system python binary upgrades, *nix would not (some, like Brandon, con
Barry Warsaw python.org> writes:
> Here at the sprints we talked about several possible options, the details of
> which of course will have to be hashed out. There will also be cross platform
> considerations. I think on *nix at least, it would be nice if a symlink and
> configuration file wer
On Mar 16, 2011, at 12:21 PM, Brandon Craig Rhodes wrote:
>I certainly agree with everyone that Python 3.3 should natively support
>a virtualenv mechanism, but I think that it should be the full "python"
>that gets copied. I realize that this means that the "python" binary
>will not get updates w
23 matches
Mail list logo
