> 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 
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:
With macports:
`otool -L oggread~.pd_darwin`

gives this:

/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 
using homebrew? 

Dan Wilcox

On Oct 10, 2016, at 12:03 PM, Jonathan Wilkes <jancs...@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:

> 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.

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

Reply via email to