Mac issues Re: Language warning in preferences is annoying

[Anton Lundin]

On 13 December, 2013 - Dirk Hohndel wrote:

> On Fri, 2013-12-13 at 18:08 +0100, Anton Lundin wrote:
> > On 13 December, 2013 - Dirk Hohndel wrote:
> > 
> > > On Fri, 2013-12-13 at 09:01 +0100, Robert Helling wrote:
> > > > Hi,
> > > > 
> > > > On 12.12.2013, at 06:53, Dirk Hohndel <dirk at hohndel.org> wrote:
> > > > 
> > > > > if you open the Subsurface preferences dialog for
> > > > > the first time on a machine (or for the first time since we added the
> > > > > language selection), the state of the language selection ended up
> > > > > inconsistent -
> > > > 
> > > > speaking of which: On my Mac, the language selection is completely empty. Both for self built and for the last beta DMG from the webpage. But it does in fact use the German locale for me.
> > > 
> > > I am finally back home and have access to my Mac again. My UPS failed
> > > while I was gone and took one of the routers in my home network (don't
> > > ask). I'll take a look at that if no one else gets to it first.
> > > 
> > > But please file a blocker bug on this one.
> > > 
> > > > To other things I noticed:
> > > > 
> > > > It still seems to use the local marble libs that I have installed. This results results in a crash when running the from the downloaded DMG unless I delete them from /usr/local/lib
> > > 
> > > I wish I knew what to do about it. It's clear that Marble has some
> > > hard-coded paths and prefers them to whatever we do when trying to tell
> > > it where to find its files.
> > > 
> > > We may have to patch the Marble sources for our Mac builds.
> > > 
> > 
> > I would guess that this could have something to do with that the marble
> > for Mac OS X is built with -DCMAKE_INSTALL_PREFIX=/usr/local ?
> 
> Well, yes. But whichever prefix you choose you'll be in trouble... I
> have considered using the same nasty hack I did for our Gtk libs
> (building them with /Applications/Subsurface.app/Contents/Resources as
> the install prefix) but then people trying to run the binary from a
> mounted DMG will see things fail.
> 
> It's really annoying. Fundamentally a library on a Mac MUST NOT make
> assumptions about existing paths that aren't relative to
> @execution_path.

Not the same problem. macdeployqt rewrites the linker paths to be
@executable_path. The problem here is that libmarblewidget might
hard code some plugin path to whatever MAKE_INSTALL_PREFIX it was built
with.

Yes, it might be a problem if someone installs another libmarblewidget
in for example
/Users/jenkins/Downloads/marble/install//Marble.app/Contents/MacOS/resources/data
but that feels kinda like a long shot, and not as common as someone
having a libmarblewidget install in /usr/local.

//Anton

-- 
Anton Lundin	+46702-161604