«

Can I use a pyd compiled on linux in a Windows distribution?

Or must I recompile it for windows users?

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

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.

In message <mailman.2268.1256841007.2807.python->, 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 Oct 29, 2009, at 8:41 PM, Christian Heimes wrote:

> Lawrence D'Oliveiro schrieb:
>> In message <mailman.2268.1256841007.2807.python->,
>> 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 on Mac OS X.

I've never seen a .pyd under OS X (although that doesn't mean they
don't exist).

The Python extensions I've written in C compile to a .so under OS X.

Cheers
P

Philip Semanchuk wrote:
>
> On Oct 29, 2009, at 8:41 PM, Christian Heimes wrote:
>
>> Lawrence D'Oliveiro schrieb:
>>> In message <mailman.2268.1256841007.2807.python->,
>>> 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 on Mac OS X.
>
> I've never seen a .pyd under OS X (although that doesn't mean they don't
> exist).
>
> The Python extensions I've written in C compile to a .so under OS X.

This is true of all Python extensions on OS X. .pyd is only used on Windows.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

In message <mailman.2297.1256863331.2807.python->, Christian
Heimes wrote:

> Lawrence D'Oliveiro schrieb:
>
>> In message <mailman.2268.1256841007.2807.python->,
>> 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.
> The suffix was changed to avoid issues with other dlls and name clashes.

What clashes? How come other OSes don't seem prone to the same problems?

On Oct 29, 9:10*pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:
> In message <mailman.2297.1256863331.2807.python-l...@python.org>, Christian
>
> Heimes wrote:
> > Lawrence D'Oliveiro schrieb:
>
> >> In message <mailman.2268.1256841007.2807.python-l...@python.org>,
> >> 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.
> > The suffix was changed to avoid issues with other dlls and name clashes..
>
> What clashes? How come other OSes don't seem prone to the same problems?

Yeah, because who ever heard of one OS having a problem that another
OS didn't?

Windows searches for DLLs on the executable path, which always
includes the current directory. So if you have a module called
system32.dll in your currently directory, you could be in big trouble.

Unix doesn't automatically search the current dir, doesn't use the
executable search path (libraries have their own search path, which is
not used when loading shared libs by hand), and system libraries on
Unix conventionally are prefixed by lib. So name collisions are rare,
but even if if you have a module called libc.so in your current
directory it will not conflict with /lib/libc.so.


Carl Banks

Carl Banks wrote:
> On Oct 29, 9:10 pm, Lawrence D'Oliveiro <l...@geek-
> central.gen.new_zealand> wrote:
>
>> In message <mailman.2297.1256863331.2807.python-l...@python.org>, Christian
>>
>> Heimes wrote:
>>
>>> Lawrence D'Oliveiro schrieb:
>>>
>>>> In message <mailman.2268.1256841007.2807.python-l...@python.org>,
>>>> 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.
>>> The suffix was changed to avoid issues with other dlls and name clashes.
>>>
>> What clashes? How come other OSes don't seem prone to the same problems?
>>
>
> Yeah, because who ever heard of one OS having a problem that another
> OS didn't?
>
> Windows searches for DLLs on the executable path, which always
> includes the current directory. So if you have a module called
> system32.dll in your currently directory, you could be in big trouble.
>
> Unix doesn't automatically search the current dir, doesn't use the
> executable search path (libraries have their own search path, which is
> not used when loading shared libs by hand), and system libraries on
> Unix conventionally are prefixed by lib. So name collisions are rare,
> but even if if you have a module called libc.so in your current
> directory it will not conflict with /lib/libc.so.
>
>
> Carl Banks
>
>
I don't believe changing the extension modifies the search order for
LoadLibrary(). However, it does make a name collision much less likely,
which is a "goodthing." And I'd bet that more than 50% of DLL's on a
typical machine have some other extension.

As for search order, I believe it's a bit different than the one used by
CMD to search for an executable. I do not think it includes the current
directory, but instead includes the executable directory (which is
frequently where Python.exe is located).

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.

DaveA

On Oct 30, 8:43*am, Dave Angel <da...@ieee.org> 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 extension, other programs could accidentally try to
load that module instead of the intended dll, if the module is in the
current directory or system path. 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.


Carl Banks