[PD] readanysf~ v0.30

[Hans-Christoph Steiner]

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