If you define LOSE_LOAD_LIBRARY, I take it that means dynamically loaded
plugin opcodes don't function? Or do they use other functions? If they use
other functions, it would be less confusing to use another name for your
macro. If they don't function, they should; you could either move the
functions into csound.c or make another.c file with them.

Original Message:
-----------------
From:  ramsdell@mitre.org (John D. Ramsdell)
Date: 04 Nov 2003 12:22:07 -0500
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3266] Re: ccsound.c



stevenyi  writes:

> Hi John R and all,
> 
> Trying out ccsound.c, the linker is missing a few functions.  
> 
> oload.o(.data+0x1d0): undefined reference to `csoundOpenLibrary'
> oload.o(.data+0x1d4): undefined reference to `csoundCloseLibrary'
> oload.o(.data+0x1d8): undefined reference to `csoundGetLibrarySymbol'
> 
> These are available in jpff_glue.c.  What I had done previously to
> replace jpff_glue.c with csound.c was to copy these three functions into
> csound.c.  (They're empty stubs, so shouldn't be a big deal).  
> 
> These seem appropriate to place in csound.c and not ccsound.c.  

To avoid this problem, I build my library with -DLOSE_LOAD_LIBRARY.

When I build without real time support and without -DLINUX, I also build
with -DLOSE_MIDI_TTY.

Sorry, I should have not made people guess these procedures.  I just
quickly knocked off the code and contributed it as I found it useful.
(It's stolen from the looping driver that shows the bug on Windows
with MinGW.)

John


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

"gogins@pipeline.com"  writes:

> If you define LOSE_LOAD_LIBRARY, 

It means use the stubs in load_opcodes.c.  I placed the stubs there a
while ago, but I'll move them if you want.  I'll change the name of
the defined symbol too.  Just tell me what you prefer.  Then again,
Steven may be solving this problem as we correspond.

John

>From load_opcodes.c line 159.

#elif defined LOSE_LOAD_LIBRARY

void *csoundOpenLibrary(const char *libraryPath)
{
	return 0;
}
void *csoundCloseLibrary(void *library)
{
   	return 0;
}
void *csoundGetLibrarySymbol(void *library, const char *procedureName)
{
	return 0;
}
#endif


> I take it that means dynamically loaded
> plugin opcodes don't function? Or do they use other functions? If they use
> other functions, it would be less confusing to use another name for your
> macro. If they don't function, they should; you could either move the
> functions into csound.c or make another.c file with them.
> 
> Original Message:
> -----------------
> From:  ramsdell@mitre.org (John D. Ramsdell)
> Date: 04 Nov 2003 12:22:07 -0500
> To: csound-dev@eartha.mills.edu
> Subject: [CSOUND-DEV:3266] Re: ccsound.c
> 
> 
> 
> stevenyi  writes:
> 
> > Hi John R and all,
> > 
> > Trying out ccsound.c, the linker is missing a few functions.  
> > 
> > oload.o(.data+0x1d0): undefined reference to `csoundOpenLibrary'
> > oload.o(.data+0x1d4): undefined reference to `csoundCloseLibrary'
> > oload.o(.data+0x1d8): undefined reference to `csoundGetLibrarySymbol'
> > 
> > These are available in jpff_glue.c.  What I had done previously to
> > replace jpff_glue.c with csound.c was to copy these three functions into
> > csound.c.  (They're empty stubs, so shouldn't be a big deal).  
> > 
> > These seem appropriate to place in csound.c and not ccsound.c.  
> 
> To avoid this problem, I build my library with -DLOSE_LOAD_LIBRARY.
> 
> When I build without real time support and without -DLINUX, I also build
> with -DLOSE_MIDI_TTY.
> 
> Sorry, I should have not made people guess these procedures.  I just
> quickly knocked off the code and contributed it as I found it useful.
> (It's stolen from the looping driver that shows the bug on Windows
> with MinGW.)
> 
> John
> 
> 
> --------------------------------------------------------------------
> mail2web - Check your email from the web at
> http://mail2web.com/ .

I didn't notice the ifdef'd code for LOSE_LOAD_LIBRARY so went ahead 
with moving the stubs from jpff_glue.c into csound.c.  This seems 
compiles fine and probably don't need to ifdef as the functions are 
harmless anyways. 

So if we use the ones now in csound.c, should we remove the ones in 
load_opcodes.c or is that a better place for these functions? 

steven

John D. Ramsdell wrote:

>"gogins@pipeline.com"  writes:
>
>  
>
>>If you define LOSE_LOAD_LIBRARY, 
>>    
>>
>
>It means use the stubs in load_opcodes.c.  I placed the stubs there a
>while ago, but I'll move them if you want.  I'll change the name of
>the defined symbol too.  Just tell me what you prefer.  Then again,
>Steven may be solving this problem as we correspond.
>
>John
>
>>From load_opcodes.c line 159.
>
>#elif defined LOSE_LOAD_LIBRARY
>
>void *csoundOpenLibrary(const char *libraryPath)
>{
>	return 0;
>}
>void *csoundCloseLibrary(void *library)
>{
>   	return 0;
>}
>void *csoundGetLibrarySymbol(void *library, const char *procedureName)
>{
>	return 0;
>}
>#endif
>
>  
>
>  
>

Dynamically loaded plugin opcodes continue to work.  I'm not sure of the 
function of the these functions; I guessed that they were for csound API 
clients to use to load individual libraries, but didn't look beyond that.

The dynamically loaded library functions from the commandline using 
--opcode-lib happens in main.c and calls csoundLoadExternals().  Maybe 
the code in csoundLoadExternals should be refactored out to fill out the 
other stub functions and then be included into API(?).

steven

gogins@pipeline.com wrote:

>If you define LOSE_LOAD_LIBRARY, I take it that means dynamically loaded
>plugin opcodes don't function? Or do they use other functions? If they use
>other functions, it would be less confusing to use another name for your
>macro. If they don't function, they should; you could either move the
>functions into csound.c or make another.c file with them.
>