Yes, _csnd.pyd "dynamically links" with csnd.dll. The terminology can be confusing, especially because the terminology, and even the technology, are different for different operating systems. Some precise definitions:

Compile - translate symbols to a machine language object file. Addresses that lie outside the compiled object file (external addresses) must be left as symbolic addresses.

Link - combine different object files into one, in the process resolving all external addresses.

Load - load machine language into memory for execution.
  
Bind - replace all symbolic addresses with actual valid numerical addresses.

Relocate - adjust bound addresses as required for where, in memory, code actually has been loaded (we neglect this here, but it usually happens).

Now the different kinds of linking can be understood.

Static linking - the compiler makes a program out of a number of machine language objects. The operating system can simply load and run the program. Linking and binding have all been done at compile time.

Dynamic linking - the compiler makes a program and one or more shared libraries out of a number of machine language objects. The linker links the program with the shared libraries, but does not bind them. When the operating system loads the program, the program contains instructions put in automatically by the linker that tell the operating system how to load and bind the shared libraries. Linking (resolving external symbolic addresses) happens at compile time. Loading and binding (replacing symbolic addresses with numerical addresses) happen at load time.

Dynamic loading - the compiler makes a program and one or more shared libraries out of a number of machine language objects. The linker does NOT link the program with the shared libraries. The operating system loads and runs the program. The program itself, as instructed by the programmer, loads (e.g. with dlopen) and binds (e.g. with dlsym) the shared libraries. Loading, linking, and binding all happen at run time.

All Python extension modules must be dynamically loaded libraries (hence the "module" term). The Python interpreter itself, when it imports an extension module, loads, links, and binds its dynamically loaded library. 

Now for differences between operating systems and compilers. 
  
On Windows, with Visual C++, dynamic linking requires an import library that contains the symbolic addresses for the dynamically linked library. But with MinGW, the linker can link a program directly with a dynamically linked library. Both dynamically linked libraries and dynamically loaded libraries are called "dlls," but a "plugin" is always a dynamically loaded library.
  
On Unix and Linux, dynamically linked libraries are called "shared libraries", and dynamically loaded libraries are called "modules", and both are also called "shared libraries."

On OS X, a dynamically linked library is called a "dylib" or a "shared library", and a dynamically loaded library is called a "bundle" (if I understand this correctly).

Obviously, "shared library" is a dangerous term because it means one thing on Linux and a slightly different thing on OS X.
  
So, _csnd.pyd is a dynamically loaded library ("module" on Linux or I suppose it should be a "bundle" on OS X), which is dynamically linked at compile time with the dynamically linked library csnd.dll or csnd.so ("shared library" on Linux or I suppose "dylib" on OS X).

The question of course is does this really work on OS X? I should think that it would, but I just haven't done it myself.

Also, please correct me if I got the OS X stuff wrong.

Regards,
Mike




-----Original Message-----
>From: Victor Lazzarini 
>Sent: May 3, 2007 10:57 AM
>To: csound-devel@lists.sourceforge.net
>Subject: [Cs-dev] new python code question
>
>I have updated my Windows CVS and built the python module; I tested it
>and it loads.
>
>I am just a little confused, because I thought that _csnd.pyd
>was supposed to load csnd.dll, but as far as I can see in SConstruct, it
>is actually linked to it:
>
>csndPythonEnvironment.Append(LIBS = ['csnd'])
>
>I am just thinking ahead now to OSX. This would of course be OK, but
>I thought your idea was to have _csnd.pyd loading csnd.dll. I  can't see
>the code that does that, so I am supposing it's not how it's going to be
>done.
>
>Could clear that up?
>
>Victor
>Victor Lazzarini
>Music Technology Laboratory
>Music Department
>National University of Ireland, Maynooth
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel




-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net