On Sat, 31 Oct 2009 23:58:33 +1300, Lawrence D'Oliveiro wrote:
> In message , Albert
> Hopkins wrote:
>
>> On Sat, 2009-10-31 at 21:32 +1300, Lawrence D'Oliveiro wrote:
>>
>>In message
>><6e603d9c-2be0-449c-9c3c-bab49e09e...@13g2000prl.googlegroups.com>, Carl
>>Banks wrote:
>>
>>> Modules will so
On Oct 31, 6:49 am, Albert Hopkins wrote:
> OTOH this doesn't happen in Linux because a) programs wanting the
> system's crypt library are looking for libcrypt.so and b) Linux doesn't
> look in your current directory (by default) for libraries.
One other thing is that linux binaries are usually l
On Sat, 2009-10-31 at 23:58 +1300, Lawrence D'Oliveiro wrote:
> I just checked my Debian installation:
>
> l...@theon:~> find /lib /usr/lib -name \*.so -a -not -name lib\*
> -print | wc -l
> 2950
> l...@theon:~> find /lib /usr/lib -name \*.so -print | wc -l
> 4708
>
> So 63% of th
On Oct 31, 1:32 am, Lawrence D'Oliveiro wrote:
> In message <6e603d9c-2be0-449c-9c3c-
>
> bab49e09e...@13g2000prl.googlegroups.com>, Carl Banks wrote:
> > It's not Python that's the issue. The issue is that if you have a
> > module with a .dll extension, other programs could accidentally try to
>
On Oct 31, 1:32 am, Lawrence D'Oliveiro wrote:
> In message <6e603d9c-2be0-449c-9c3c-
>
> bab49e09e...@13g2000prl.googlegroups.com>, Carl Banks wrote:
> > It's not Python that's the issue. The issue is that if you have a
> > module with a .dll extension, other programs could accidentally try to
>
In message , Albert
Hopkins wrote:
> On Sat, 2009-10-31 at 21:32 +1300, Lawrence D'Oliveiro wrote:
>
>In message <6e603d9c-2be0-449c-9c3c-bab49e09e...@13g2000prl.googlegroups.com>,
>Carl Banks wrote:
>
>> Modules will sometimes find themselves on the path in Windows, so the
>> fact that Windows
On Sat, 2009-10-31 at 21:32 +1300, Lawrence D'Oliveiro wrote:
> Modules will sometimes find
> > themselves on the path in Windows, so the fact that Windows performs
> a
> > library search on the path is quite significant.
>
> Why is it only Windows is prone to this problem?
I think as someone po
In message <6e603d9c-2be0-449c-9c3c-
bab49e09e...@13g2000prl.googlegroups.com>, Carl Banks wrote:
> It's not Python that's the issue. The issue is that if you have a
> module with a .dll extension, other programs could accidentally try to
> load that module instead of the intended dll, if the mod
On Oct 30, 8:43 am, Dave Angel wrote:
> And I'm guessing that CPython searches down sys.path, and when it finds
> the module, gives a full path to LoadLibrary(), in which case the DLL
> search path is moot.
It's not Python that's the issue. The issue is that if you have a
module with a .dll exte
Carl Banks wrote:
On Oct 29, 9:10 pm, Lawrence D'Oliveiro wrote:
In message , Christian
Heimes wrote:
Lawrence D'Oliveiro schrieb:
In message ,
Christian Heimes wrote:
On Linux and several other Unices the suffix is .so and not .pyd.
Why is that? Or conve
On Oct 29, 9:10 pm, Lawrence D'Oliveiro wrote:
> In message , Christian
>
> Heimes wrote:
> > Lawrence D'Oliveiro schrieb:
>
> >> In message ,
> >> Christian Heimes wrote:
>
> >>> On Linux and several other Unices the suffix is .so and not .pyd.
>
> >> Why is that? Or conversely, why isn't it .dll
In message , Christian
Heimes wrote:
> Lawrence D'Oliveiro schrieb:
>
>> In message ,
>> Christian Heimes wrote:
>>
>>> On Linux and several other Unices the suffix is .so and not .pyd.
>>
>> Why is that? Or conversely, why isn't it .dll under Windows?
>
> On Windows it used to be .dll, too.
>
Philip Semanchuk wrote:
On Oct 29, 2009, at 8:41 PM, Christian Heimes wrote:
Lawrence D'Oliveiro schrieb:
In message ,
Christian
Heimes wrote:
On Linux and several other Unices the suffix is .so and not .pyd.
Why is that? Or conversely, why isn't it .dll under Windows?
.so is the commo
On Oct 29, 2009, at 8:41 PM, Christian Heimes wrote:
Lawrence D'Oliveiro schrieb:
In message ,
Christian
Heimes wrote:
On Linux and several other Unices the suffix is .so and not .pyd.
Why is that? Or conversely, why isn't it .dll under Windows?
.so is the common suffix of shared libra
Lawrence D'Oliveiro schrieb:
> In message , Christian
> Heimes wrote:
>
>> On Linux and several other Unices the suffix is .so and not .pyd.
>
> Why is that? Or conversely, why isn't it .dll under Windows?
.so is the common suffix of shared libraries on Linux. IIRC Python
extensions have .pyd o
In message , Christian
Heimes wrote:
> On Linux and several other Unices the suffix is .so and not .pyd.
Why is that? Or conversely, why isn't it .dll under Windows?
--
http://mail.python.org/mailman/listinfo/python-list
Bakes wrote:
> Can I use a pyd compiled on linux in a Windows distribution?
>
> Or must I recompile it for windows users?
On Linux and several other Unices the suffix is .so and not .pyd. The
compiled extensions depend on the Python version, operating system as
well as platform and architecture.
On Thu, Oct 29, 2009 at 12:44 PM, Bakes wrote:
> Can I use a pyd compiled on linux in a Windows distribution?
No.
> Or must I recompile it for windows users?
Yes.
--
http://mail.python.org/mailman/listinfo/python-list
Bakes wrote:
> Can I use a pyd compiled on linux in a Windows distribution?
>
> Or must I recompile it for windows users?
Yes, you must.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
Can I use a pyd compiled on linux in a Windows distribution?
Or must I recompile it for windows users?
--
http://mail.python.org/mailman/listinfo/python-list
20 matches
Mail list logo