conflict with macports

[Adam Dershowitz Ph.D., P.E.]

On Jun 12, 2014, at 4:41 PM, Mojca Miklavec <mojca at macports.org> wrote:

> On Thu, Jun 12, 2014 at 10:20 PM, Daniel J. Luke wrote:
>> On Jun 12, 2014, at 4:10 PM, Mojca Miklavec wrote:
>> 
>>> Lack of manpower (and understanding about best packaging practice on
>>> different OSes). It is also not impossible that they simply don't know
>>> how to install MacPorts elsewhere.
>> 
>> they don't need to install macports anywhere else
>> 
>> they can copy the libs they want (and the libs that those libs use), put them somewhere else, and use install_name_tool to fix the path(s) embedded in the libs so that they still work.
> 
> I'm not claiming it's the case here, but there is some software where
> install_name_tool simply isn't enough. A lot of software packages
> hardcode the configure-time variables into the binary and use those
> variables to find files later (when running the software).
> 
> Such sources might need special attention and fixes.
> 
> Mojca
> ______________________________________________


In this case, I believe that they are just using gtk+, and then all of the dependencies.  But, that includes things like pango that have a bunch of other modules.  I have no idea if that set can be moved trivially or not.