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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
