[PD] Purr Data beta 2
jancsika at yahoo.com
Wed Oct 12 17:30:24 CEST 2016
> You’ll probably need to build form source in either environment if you want to be
> sure of the deployment target. Both Homebrew and Macports are focused on
> running OS software for the current system, much less so for building baked
> libraries to run on other systems.
Ok, so I tried out homebrew on a fresh OSX 10.11 vm. Great speed of installation,
and flawless downloading of necessary packages. And it results in completely
borked external libs-- at least the ones that depend on an external library.
Take oggread~.pd_darwin for example:
`otool -L oggread~.pd_darwin`
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)/opt/local/lib/libvorbis.0. dylib (compatibility version 5.0.0, current version 5.8.0)/opt/local/lib/libvorbisenc.2. dylib (compatibility version 3.0.0, current version 3.11.0)/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 915.0.0)
When building the app bundle, Hans (I think) wrote a script that can grab the
/opt/local/lib dependencies, copy them to the app bundle, and revise the path
in the binary using @executable_path to make sure the dependecies in the app
bundle are correctly found when loading an external.
Now, with homebrew:otool -L oggread~.pd_darwin
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 915.0.0)
There's no path listed at all to the ogg lib dependencies. When I try to load
oggread~ with the Purr Data app bundle I just created it doesn't search
/usr/local/lib and consequently reports missing symbols.
Any clue how to get the compiler to actually link to the necessary libs when
On Oct 10, 2016, at 12:03 PM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
> Judging from the output of brew —env, there is a MACOSX_DEPLOYMENT_TARGET you should be able to set/override. Simplest way would be when running brew:
> MACOSX_DEPLOYMENT_TARGET=10.6 brew …
> That, in combination with —build-from-source when installing packages, might give you want you need.
That could work, but then I'm back to building from source. (macports uses binaries for most stuff, btw.)
I'm happy to investigate further _if_ a homebrew dev says that they officially support installing this way. There's a similar way
to change the deployment target for macports. But one of the devs told me that kind of compatibility isn't a design goal and
they don't support doing that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list