Are *.pyd's universal?

Dave Angel davea at ieee.org
Fri Oct 30 16:43:11 CET 2009


Carl Banks wrote:
> On Oct 29, 9:10 pm, Lawrence D'Oliveiro <l... at geek-
> central.gen.new_zealand> wrote:
>   
>> In message <mailman.2297.1256863331.2807.python-l... at python.org>, Christian
>>
>> Heimes wrote:
>>     
>>> Lawrence D'Oliveiro schrieb:
>>>       
>>>> In message <mailman.2268.1256841007.2807.python-l... at 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





More information about the Python-list mailing list