On Apr 8, 2009, at 7:19 AM, IOhannes m zmoelnig wrote:

Hans-Christoph Steiner wrote:
On Apr 6, 2009, at 5:26 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
So a library like 'audiomath' would then have audiomath/ libaudiomath.pd_linux. Normally, audiomath/libaudiomath.pd_linux would only include shared code, but for this case, it would also include the >~ class, etc.

i guess you meant to name it either "audiomath/ libaudiomath.so" (or .dll or .dylib) or "audiomath/ audiomath.pd_linux".
Perhaps audiomath/libaudiomath.so makes the most sense so that it can't be loaded by Pd as an objectclass. But I am guessing.

the question is why you would want to enforce Pd not being able to load this library. at the worst this would allow to mix abstractions, single-object- binaries, multi-object-binaries and shared-code dylibs into a single "bundle" (libdir-like directory defining a library)

the only reason i see to create an explicit mechanism to prevent Pd from loadinga file as an object-class is a notorious aversion against multiboject-binaries.

it's ok for me if someone doesn't like these. it's not ok for me declaring war on them.

I have traditionally had an aversion to multiobject-binaries because of the pain they caused many people, me included. It seems that they could be fine as long as we have the right mechanisms to be able to put the objectclasses in that binary into a fully functioning namespace, and be able to address them using namespace prefixes. From the Pd interface point of view, all objectclasses should behave the same, regardless of how they are implemented.

The idea for the audiomath/libaudiomath.so chunk is for shared code that would be loaded when the library is loaded, whether or not any object class has been loaded. I suppose it might just be simpler to make it a .pd_linux. I just have a feeling that it will cause problems down the line, I don't have an example off hand to back up that feeling.

i admit that currently all C-code is considered "shared" (that is: there is no "list2symbol.pd_linux"), but once you start blurring the two worlds it get's blurry anyhow (and "l2s" and "list2symbol" share about 100% of their code anyhow)
I like having each objectclass as its own file.

i know

Then only the code that is in use will be loaded into memory. linking everything together into one zexy.pd_linux means the whole thing is loaded into memory, no?

but you are surely aware that you cannot avoid people doing this with shared libs (that cannot be loaded directly by Pd) as well.

so again, the only reason to make this explicit is because to throw feeble hurdles on the path of freedom of a developer.
<trying to turn pathos mode off>

I think the archives have some long discussions about the problems with multi-object binaries. I am not opposed to using them if someone wants to do the work to make them behave like abstractions in a libdir currently do. (i.e. [import mylib] then [myobj]; [mylib/myobj], etc.) Then we would have a relatively straightforward solution for the problems with >~, etc.

i would also like to have Pd's loading mechanism modified so that it _temporarily_ adds Gem/ to the dylib-searchpath, so one could ship a library with external dependencies (without having to link them statically)
I am sure you don't mean to do this on GNU/Linux, right?

yes i want to do this on all platforms.

What lib would you include with Gem on GNU/Linux? Shouldn't Gem use the Debian/Ubuntu/Fedora packages? Or am I missing something?

I take it you mean like including a .dylib in the Gem folder?

but i am not talking about including libGL.so with Gem.

it is really something along the lines of your proposal on "audiomath/libaudiomath.so".

Kind of like what I do with Pd-extended and the Fink dylibs? That is not a great system. I think due to the limitations of the Mac OS X shared lib loading, it would be painful. Basically, AFAIK, a .dylib in Mac OS X must have its path hard-coded in the file. Otherwise, you have to load it manually with a direct call to dlopen.

but the path can be relative, no?

Not really, IIRC. It has to be an absolute path, but then there is this @executable_path@ variable which is replaced by the path to the executable that is loading the lib. Its all a bit hazy in my brain, it would be worth checking the docs and maybe trying a relative path. I remember trying a lot of things, then giving up and thinking that Pd would have to open audiomath/libaudiomath.so directly using dlopen().


I don't remember the details in Windows, I think that it already checks "." for .dlls by default.

this is how i remember it as well.



                  ¡El pueblo unido jamás será vencido!

Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 

Reply via email to