On May 1, 2009, at 3:12 AM, august wrote:
what exactly does that mean? Do you mean compiling it in
statically? Or, do you mean compiling and installing the libraries? If you mean statically, I'm not sure, but I think it will be difficult since
it is gmerlin based on a plugin architecture of shared objects.-a
Static is one option, but not the only. You can also compile it as a dynamic lib and included it with the external. That makes it harder to distribute though. With Windows and Mac OS X distros of Pd- extended, there are many included dynamic libs. If there were fink packages for gmerlin/gavl then this happens automatically as part of the build system.
Basically what I mean in something like this:
externals/readanysf externals/readanysf/readanysf~.c externals/readanysf/gavl externals/readanysf/gmerlin
Then in the Makefile for readanysf, build gavl and gmerlin, then use something like "-I./gavl -I./gmerlin" for CFLAGS and "-L./gavl -L./ gmerlin" for LDFLAGS. Using automake would make that process easier. Then whereever the readanysf~.pd_linux is, the .so would be included (or .pd_darwin/.dylib, or .dll/dll).
I'm not sure it can work like that. For one, and correct me if I am wrong...cause I am certainly not the master of dynamic linking, but
just because you compile an app with -L/gavl doesn't mean your system
will be able to load that needed dynamic library with the app. You need to
tell the system that the dynamic library is somewhere where it can find it. The second problem is that the gmerlin_avdecode library itself is
based on dynamic object plugins (one for madlib, one for theora, etc.) and those object need to be in a findable place as well.please correct me if I am missing something about how you are
packaging PD. Is there a folder somewhere that you are installing shared libs
that are used by pd or externals?
This kind of thing various a lot by platform:
- Windows will use .dlls in ".", it will also look in the same folder
as the pd.exe. With the Pd-extended installer, the dlls can be
installed and managed in the "system32" folder too.
- I think GNU/Linux can also look in "." for .so files, but I haven't
really tried much because I haven't had too, I just statically link,
or use packaged libraries there.
- Mac OS X is the hardest. The .dylibs need to have their path coded
in them. I don't think "." will work, but it might. In Pd-extended,
I wrote a script that looks for Fink libs (based on the /sw base path)
then it copies them into the Pd-extended.app/Contents/lib and rewrites
their path using the @executable_path variable that allows some kind
of relative path. This is fully automated for years now, so I think
making fink packages for this stuff will be the easiest path on Mac OS
X. But it would be good to figure out how to automatically
load .dylibs from '.' so they can be included in any standalone
libdirs. By the way, libquicktime also has plugins, but they are also
included in the Pd-extended.app package. That required setting an
envvar with the location.
After writing all that, I am thinking that linking everything
statically on all platforms is probably going to be the easiest thing
to do for now... it would be the same makefile, more or less, on all
platforms. The dynamic lib stuff will all be totally different on
each platform.
.hc
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White