I'm sorry, but I have only a little idea what you are saying means - what is
the relation of the cmf stuff and mach-o stuff to BSD dlopen and dlsym?

============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
Silence, a language for programming music and sound
Available at http://sourceforge.net/projects/silencevst/
============================================


----- Original Message ----- 
From: "Matt J. Ingalls" 
To: "Csound Developers Discussion List" 
Sent: Thursday, November 06, 2003 8:25 PM
Subject: [CSOUND-DEV:3307] RE: load_opcodes.c


>
> plugins work in my port on osx as cfm libraries - very soon now will be
> finally moving to mach-o csoundlib, and i will throw in the mach-o bundle
> stuff in the plugin code too..
>
>
> -m
>
>
>
>
>
> On Wed, 5 Nov 2003, gogins@pipeline.com wrote:
>
> > It's not correct, and it can't be correct, because as far as I know,
nobody
> > has worked on plugin opcodes who knows how to code dynamically loaded
> > libraries on Windows, Linux, and OS X. As far as I know, plugins haven't
> > been implemented on OS X, but I WOULDN'T know, because I don't HAVE OS
X. I
> > would think Matt Ingalls would know. Maybe he's even implemented it. If
so,
> > you could paste his code into the aforementioned functions for Mac OS X.
> >
> > Whatever, the code should be consistent on all platforms. My original
> > intention was to abstract plugin loading with the aforementioned API
> > functions, which would be used by Csound itself as well as plugins
> > themselves.
> >
> > What would really be ideal here, and maybe with you and John Ramsdell
> > working on this maybe we can get there, is a single GNU build system
that
> > would work for all 3 major platforms (Windows, Linux, OS X). This could
be
> > done by building on Windows with Cygwin (with -mno-cygwin) or
mingw/MSYS.
> > But audio is the thorn in our side here. It might take custom build
rules
> > in the Makefile.am's for the audio driver .o's to get the audio drivers
> > building.
> >
> > Original Message:
> > -----------------
> > From: stevenyi stevenyi@csounds.com
> > Date: Tue, 04 Nov 2003 22:54:58 -0800
> > To: csound-dev@eartha.mills.edu
> > Subject: [CSOUND-DEV:3283] load_opcodes.c
> >
> >
> > Hi all,
> >
> > I was trying to work with this file but got a bit confused.  The way the
> > #ifdef's are, if you have WIN32 defined, you get csoundOpenLibrary,
> > csoundCloseLibrary, and csoundGetLibrarySymbol.  If you have LINUX
> > defined, you get the first three plus csoundLoadExternals.  If you have
> > MACINTOSH defined, you get the above four functions plus
> > csoundLoadExternal.
> >
> > Is this correct?
> >
> > Thanks,
> > steven
> >
> >
> >
> > --------------------------------------------------------------------
> > mail2web - Check your email from the web at
> > http://mail2web.com/ .
> >
> >
>

Okay, after brushing up a bit with the Apple developer docs, I think I
understand the situation with the load_opcodes.c a bit better. 

Mac has two types of libraries which they prefer to call bundles (they
also have Frameworks, which are shared-libs bundled together with header
files and docs, and Umbrella Frameworks, which are like bundles of
bundles... yikes.)  Carbon (cfm) bundles which are OS9 style, and Mach-O
which are OSX style (they end in .dylib).  Working with .dylibs is
largely similar to working with linux .so's (they're built with gnu
tools, granted, altered by Mac so that they behave *almost* like gnu
stuff would on other platforms... another yikes), but the functions for
loading .dylib's differ from BSD dlopen and dlsym.  (There's more
functions for working with libraries).

http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/2rt_mach-o_overview/index.html

has the Overview information about Mach-O, as well as API reference for
dynamic linking functions for dylib loading and symbol lookup.

Now, the code from John ffitch and the dlcompat library from opendarwin
are pretty much the same thing in that they wrap all of the Apple
library loading functions to function like BSD dlopen, dlsym, dlerror. 
The dlcompat library, if I read correctly, used to be part of fink,
which is a system to help port linux apps over to OSX.  So, both the
code from John ffitch and dlcompat would be used to wrap the Apple
mach-o functions so that they can be loaded in a BSD/linux fashion.

However, after figuring this all out, it seems that to be more
architecturally clean, it would be better to instead of using the dl-
wrappers would be to implement the csoundLoadLibrary,
csoundCloseLibrary, and csoundGetLibrarySymbol directly for MACOSX,
instead of reusing the Linux implementation of those functions. This
would be for architectural clarity.  It'd probably be easier to use the
dlcompat stuff or figure out what's not working from what I copied over
from John's file.  

Either way, reading through Apple's maze of Mach-O documentation has
gotten me quite spun around.  Will have to give it another go tomorrow
or on the weekend!

steven



On Thu, 2003-11-06 at 17:58, Michael Gogins wrote:
> I'm sorry, but I have only a little idea what you are saying means - what is
> the relation of the cmf stuff and mach-o stuff to BSD dlopen and dlsym?

as far as i remember the bundle stuff is simply just like michael's in the
api, FindBundle(), LoadBundle(), FindFunction(), etc..

although as far as implementation, i think the linux code would be fine if
it works, the only thing i would be concerned with is how the plugins
would appear on the mac -- maybe its not really a problem, but was
thinking a bundle is more "maclike" , i guess the bigger issue is where to
put them?

-m [will get more into this discussions/list/csound5 once im done
with movinghell and get dsl back..]






On Thu, 6 Nov 2003, stevenyi wrote:

> Okay, after brushing up a bit with the Apple developer docs, I think I
> understand the situation with the load_opcodes.c a bit better.
>
> Mac has two types of libraries which they prefer to call bundles (they
> also have Frameworks, which are shared-libs bundled together with header
> files and docs, and Umbrella Frameworks, which are like bundles of
> bundles... yikes.)  Carbon (cfm) bundles which are OS9 style, and Mach-O
> which are OSX style (they end in .dylib).  Working with .dylibs is
> largely similar to working with linux .so's (they're built with gnu
> tools, granted, altered by Mac so that they behave *almost* like gnu
> stuff would on other platforms... another yikes), but the functions for
> loading .dylib's differ from BSD dlopen and dlsym.  (There's more
> functions for working with libraries).
>
> http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/2rt_mach-o_overview/index.html
>
> has the Overview information about Mach-O, as well as API reference for
> dynamic linking functions for dylib loading and symbol lookup.
>
> Now, the code from John ffitch and the dlcompat library from opendarwin
> are pretty much the same thing in that they wrap all of the Apple
> library loading functions to function like BSD dlopen, dlsym, dlerror.
> The dlcompat library, if I read correctly, used to be part of fink,
> which is a system to help port linux apps over to OSX.  So, both the
> code from John ffitch and dlcompat would be used to wrap the Apple
> mach-o functions so that they can be loaded in a BSD/linux fashion.
>
> However, after figuring this all out, it seems that to be more
> architecturally clean, it would be better to instead of using the dl-
> wrappers would be to implement the csoundLoadLibrary,
> csoundCloseLibrary, and csoundGetLibrarySymbol directly for MACOSX,
> instead of reusing the Linux implementation of those functions. This
> would be for architectural clarity.  It'd probably be easier to use the
> dlcompat stuff or figure out what's not working from what I copied over
> from John's file.
>
> Either way, reading through Apple's maze of Mach-O documentation has
> gotten me quite spun around.  Will have to give it another go tomorrow
> or on the weekend!
>
> steven
>
>
>
> On Thu, 2003-11-06 at 17:58, Michael Gogins wrote:
> > I'm sorry, but I have only a little idea what you are saying means - what is
> > the relation of the cmf stuff and mach-o stuff to BSD dlopen and dlsym?
>
>

Hi All,

I modified the ffitch OSX code a little bit (mostly just renamed the
functions to adhere to the CsoundAPI names of csoundLoadLibrary, etc. as
well as changed argument names to match the other implementations),
#included the missing mach-o/dyld.h file, and moved some common headers
out to the top.  load_opcodes.c now compiles fine for OSX, though I
haven't tested it as I got some errors in the linking stage for csound. 
I looked at code from PD for how it loads libraries and it uses the same
mach-o library loading code (pretty much) as dlcompat and ffitch's
code.  

Will try to finish getting past linking later this weekend and test out
some opcode libs!

steven


On Fri, 2003-11-07 at 09:43, Matt J. Ingalls wrote:
> as far as i remember the bundle stuff is simply just like michael's in the
> api, FindBundle(), LoadBundle(), FindFunction(), etc..
> 
> although as far as implementation, i think the linux code would be fine if
> it works, the only thing i would be concerned with is how the plugins
> would appear on the mac -- maybe its not really a problem, but was
> thinking a bundle is more "maclike" , i guess the bigger issue is where to
> put them?
> 
> -m [will get more into this discussions/list/csound5 once im done
> with movinghell and get dsl back..]

> bundles... yikes.)  Carbon (cfm) bundles which are OS9 style, and Mach-O
> which are OSX style (they end in .dylib).  Working with .dylibs is

cant you have mach-o .bundles too?

Yeah, I think I was getting mixed up in terminology. I think this is 
what tripped me up:

    * Bundles are executable files that your program can load at runtime
      using dynamic linking functions. Bundles implement plug-in
      functionality, such as file format importers for a word processor.
      The term “bundle ” has two related meanings in Mac OS X:
          o the actual Mach-O file containing the executable code

          o a file package—a folder containing the Mach-O bundle file
            and associated resources. A file package bundle need not
            contain a Mach-O bundle file.

      The latter usage is the more common. However, unless otherwise
      specified, this book refers to the former.


which, like most of the apple dev docs, continues to obfuscate 
everything in my head.
=o

steven


Matt J. Ingalls wrote:

>>bundles... yikes.)  Carbon (cfm) bundles which are OS9 style, and Mach-O
>>which are OSX style (they end in .dylib).  Working with .dylibs is
>>    
>>
>
>cant you have mach-o .bundles too?
>
>
>
>  
>

On 11/6/03 8:25 PM, Matt J. Ingalls etched in stone:

> plugins work in my port on osx as cfm libraries - very soon now will be
> finally moving to mach-o csoundlib, and i will throw in the mach-o bundle
> stuff in the plugin code too..

Glad that you have the plugins working.  I am wondering if it will be
possible to support opcode plugins under the Legacy MacOS (System 7 through
OS 9).  Since you are currently using CFM libraries on OS X, do you think
this code can be adapted to work on OS 9?  (Or do you already have it
working there?)

In any case, let's not "throw out" the CFM code when you move to Mach-O
since it will probably be useful for OS 9.


On 11/7/03 12:43 PM, Matt J. Ingalls etched in stone:

> it works, the only thing i would be concerned with is how the plugins
> would appear on the mac -- maybe its not really a problem, but was
> thinking a bundle is more "maclike" , i guess the bigger issue is where to
> put them?

Bundles sound good.  As for where, I think the logical choice is somewhere
in /Library and ~/Library (both need to be supported since users may not
have access to /Library).

I would suggest

/Library/Audio/Plug-Ins/Csound/
or 
/Library/Application Support/Csound/

and 

~/Library/Application Support/Csound/
or
~/Library/Csound/Plug-Ins/

(~/Library/Audio/ does not seem to exist by default, but I suppose we could
create it for consistency).

Anthony Kozar
anthony.kozar@utoledo.edu