Krzysztof Czaja said this at Wed, 20 Nov 2002 20:07:48 +0100:
This is very much an alpha release, to be used by fellow coders, or the very brave of all Pdiers. It is known to crash or behave wildly.
Krzysztof,
Well, compilation on Mac OS X went *extremely* easily... absolutely no code changes necessary, and minimal flag changes in Makefile.common. (I'm blown away by your build system.) Once I got the libraries to work with PD (more below), the test patches gave very plausible results (but I don't know the behavior of the Max objects well enough to verify the mis- features).
Miller, here's where you come in...
But the test patches didn't work with PD right away. I tried opening something like Borax-test.pd and crashed with the following result:
dyld: /usr/local/pd/bin/pd multiple definitions of symbol _hammer_checkint ./Borax.pd_darwin definition of _hammer_checkint ./funbuff.pd_darwin definition of _hammer_checkint
The same function was included in two externals, and they clobbered each other when loaded by PD/Mac. Krzysztof, PD/Linux doesn't work that way, right?
Not having a Linux box to compare with, I assumed that this wasn't supposed to be happening, and rather than trying to figure out how to package hammer and sickle as libraries, I took a look at s_loader.c. I poked in a few places, and as a lucky guess, I added the following flag to line 116 or so in s_loader: ret = NSLinkModule( image, filename, NSLINKMODULE_OPTION_BINDNOW + NSLINKMODULE_OPTION_PRIVATE);
A new PD made from this works well with cyclone. I haven't tested for ill effects in enough other places yet. A bunch of questions fall out of this: Is changing PD the right approach in this case? Is the Linux behavior the one we want to emulate? Does this screw anything else up?
I've attached my Makefile.darwin (replace Makefile.common in cyclone with a link to this), in case others want to experiment.
adam
PS. from the Mach-O Runtime Architecture PDF, page 123: NSLINKMODULE_OPTION_PRIVATE Do not add the global symbols from the module to the global symbol list. Instead, you must use the NSLookupSymbolInModule (page 128) function to obtain symbols from this module. http://developer.apple.com/techpubs/macosx/DeveloperTools/MachORuntime/ MachORuntime.pdf
Adam T. Lindsay said this at Thu, 21 Nov 2002 13:56:03 +0000:
rather than trying to figure out how to package hammer and sickle as libraries,
Erm, at that point I hadn't noticed that they *are* packaged as libraries. Running "pd -lib hammer" works fine without any changes to PD.
But I think the underlying issue with the MacOSX loader is still instructive.
Sorry for any confusion, adam
hi Adam,
thank you!
I think I will add an OS X branch (containing your changes) into the common makefile. Could you tell me what 'uname -s' prints out on OS X?
For the time being, the Mac branch would not generate single-class externals, but in the long run I think it should, as the main libs are likely to grow in size.
It seems like in each system Pd loads externals differently. Windows .dll does not export external symbols, .pd_linux does (with the flag RTLD_GLOBAL) -- but dlopen kindly resolves any name clashes -- and now you tell that .pd_darwin is so fragile... You are right, something needs to be done to unify loader's behaviour.
Krzysztof
(My build tools are horrible, I know, but still, they do their job of maintaining (not only building) all my Pd-related stuff, of which cyclone and xeq are only a part.)
Adam T. Lindsay wrote: ...
The same function was included in two externals, and they clobbered each other when loaded by PD/Mac. Krzysztof, PD/Linux doesn't work that way, right?
Krzysztof Czaja said this at Fri, 22 Nov 2002 16:37:44 +0100:
thank you!
My pleasure. Everything about PD is so portable that MacOSX ports of externals are becoming very trivial.
I think I will add an OS X branch (containing your changes) into the common makefile. Could you tell me what 'uname -s' prints out on OS X?
Darwin uname -m, as I've seen in other makefiles, gives the slightly less- helpful "Power Macintosh"
For the time being, the Mac branch would not generate single-class externals, but in the long run I think it should, as the main libs are likely to grow in size.
It seems like in each system Pd loads externals differently. Windows .dll does not export external symbols, .pd_linux does (with the flag RTLD_GLOBAL) -- but dlopen kindly resolves any name clashes -- and now you tell that .pd_darwin is so fragile... You are right, something needs to be done to unify loader's behaviour.
Okay. I wasn't sure what the Mac should be emulating. As you now say, that's not an easy question to answer, but thanks for the explanation.
(My build tools are horrible, I know, but still, they do their job of maintaining (not only building) all my Pd-related stuff, of which cyclone and xeq are only a part.)
No! My comment was that they were amazingly good, from my beginner's point-of-view. I had to do *minimal* work to get the Mac part going.
cheers, adam
-
Adam T. Lindsay -
Krzysztof Czaja