On 2014-6-13 04:54 , Adam Dershowitz Ph.D., P.E. wrote: > > > On Jun 12, 2014, at 8:41 AM, Mark Brethen <[email protected]> wrote: > >> Begin forwarded message: >> >>> From: Z88Aurora Support <[email protected]> >>> Subject: AW: conflict with macports >>> Date: June 12, 2014 at 5:14:38 AM CDT >>> To: "'Brethen, Mark Douglas. (MSFC-ER41)[ESSSA]'" >>> >>> Hello Mark, >>> >>> we tried to get everything working from z88aurorav2/bin/mac, but there are >>> several problems with the dylibs. >>> Unfortunately, even with linking the dylibs not from /opt/local/lib but from >>> .../bin/mac, those dylibs are depending on other dylibs and this is why they >>> contain static links to opt/local/lib. >>> >>> To get everything working without using /opt/local, we would have to edit >>> every library like libgtk, libatk, libglib, etc. >>> >>> At the moment, we don't plan to tackle this issue because of the massive >>> time and manpower it would need compared to the limited number of OS X users >>> with MacPorts installed. >>> >>> The only (quick) solution at our minds is to use different opt folders and >>> softlink them to /opt. >>> Which of course leads to MacPorts and Z88 not working simultaneously. >>> >>> Maybe we will get this working with an upcoming version, which could be >>> switching from GTK2 to GTK3, but this is nothing which is to be expected >>> during the next months. >>> >>> I'm sorry I couldn't solve this for you, but my power is limited on this >>> domain. >>> >>> Kind regards, >>> >>> Stefan >>> Support Z88Aurora >>> Lehrstuhl für Konstruktionslehre und CAD >>> Universität Bayreuth >>> Universitätsstraße 30 >>> 95447 Bayreuth >>> E-Mail: [email protected] >>> Internet: www.z88.de >> >> He doesn't go into specifics, but it sounds like they're trying to use two >> sets of libraries? >> >> Mark >> > I received the same email as you did. > I suggested that he could use MacPorts into /opt/z88 or something similar. > But, given this email chain, I will instead suggest using dylibbundler.
It's not clear exactly what they're doing that prevents them from installing into a different prefix. But it's not inconceivable that the same reasons mean they haven't built with -headerpad_max_install_names and thus can't use the various options for relocation. Maybe they're using a binary of gtk + deps and not building it themselves? That's all I can think of anyway. (Unless perhaps the only guy that knew how to build it left the company...) In any case, it's difficult for us to help find a solution when the problem hasn't been clearly laid out. - Josh _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
