Not on Windows! -- if you don't call those functions. 

And on Unix/Linux, the runtime linker will be able to link the functions,
even across versions if the symbols don't change. 

But if you want to enable plugins on Unix/Linux with no dynamic linking by
the operating system - all linking done by the host dlopen, dlsym, push
Csound interface into plugin - then you would be better off with just the
interface in a header (plugin header).

Original Message:
-----------------
From: steven stevenyi@csounds.com
Date: Wed, 19 Nov 2003 14:54:02 -0800
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3426] Re: Csound API Split, design




Matt J. Ingalls wrote:

>>And in regards to pushing everything into csound.h, wouldn't that cause
>>all the trouble with linking against the host API functions and
>>requiring libcsound.a?  It seems that the API for hosts and plugins then
>>    
>>
>
>but all the functions you call from csound.h are via a pointer, so you
>have no linking issues, or am i not understanding what you are saying?
>-m
>
[probably a rudimentary question]
Maybe this is where my inexperience shows through, but if the 
csoundXXX(...) function prototypes in csound.h are used when compiling 
an opcode plugin, won't the runtime linker then expect to link up 
csoundXXX(...) functions to the opcode plugin, considering that csound.c 
implementation of the functions are compiled with csound and not with 
the plugin?  It's not the function pointers in the GLOBAL I was worried 
about, but the csoundXXX(...) prototypes. 

thanks for any clarifications!
steven




--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .