Am 08.07.2015 um 13:08 schrieb Jerry <lancebo...@qwest.net>:

> 
> On Jul 8, 2015, at 3:32 AM, Stephan Witt <st.w...@gmx.net> wrote:
> 
>> Am 08.07.2015 um 12:06 schrieb Jerry <lancebo...@qwest.net>:
>> 
>>> 
>>> On Jul 7, 2015, at 10:54 PM, Stephan Witt <st.w...@gmx.net> wrote:
>>> 
>>>> Am 08.07.2015 um 01:20 schrieb Jerry <lancebo...@qwest.net>:
>>>> 
>>>> This means you didn't add --enable-qt5=yes - but this is only useful for 
>>>> systems
>>>> with Qt4 and Qt5 installed side by side (like Linux distros typically do) 
>>>> and
>>>> with different names for QtCore et al.
>>>> 
>>>> The problem with Qt detection here is the complete ignorance of the 
>>>> --with-qt-dir
>>>> command line option given to configure. I don't know how this should work 
>>>> intentionally
>>>> but your Qt4 MacPorts Qt-version wins because of the position of 
>>>> /opt/local/bin in
>>>> PATH and configure trying to detect Qt with pkg-config with without using 
>>>> the value
>>>> given by --with-qt-dir.
>>>> 
>>>> Why this doesn't work at the end I don't know - I don't have the MacPorts 
>>>> Qt package.
>>>> 
>>>> Regards, Stephan
>>>> 
>>>> PS. I fear, you'll have a long way to go if you want to solve all issues 
>>>> coming along
>>>> this route. In case you want to ditch the MacPort route and go for Qt5 - I 
>>>> tried it with
>>>> Qt5.5.0 now and this is broken too. They've fixed the issue with RPATH 
>>>> dyld at runtime
>>>> lookup of the Qt-frameworks and now the LyX binary aborts on startup 
>>>> because of this.
>>>> I have to get a working environment with Qt5.5.0 myself first before I can 
>>>> tell you
>>>> the recipe for building LyX this way.
>>> 
>>> So I gather that somehow configure is ignoring --with-qt-dir and defaulting 
>>> to the path precedence. Would it help if I prepended 
>>> /Applications/Words/LyXOuterFolder/git/qt/Qt_Creator.app/Contents/Frameworks
>>> to the front of PATH so that it finds Qt5 first?
>> 
>> No, I don't think so. IMHO, the problem is in configure using the
>> /opt/local/bin/pkg-config utility first and trying the given qt-dir
>> as a fallback only.
>> 
>>> I'm not sure I follow everything in your PS. I can use MacPorts to install 
>>> qt5-mac 5.4.2 (5.5 is not yet available at MacPorts). Is that worth a try 
>>> while also adding --enable-qt5=yes? (I need to keep MacPorts Qt4 around for 
>>> other stuff, I assume.)
>> 
>> This one I cannot answer. I'd try it probably.
>> 
>> But I fear this conflicts with the MacPorts way of doing things.
>> I'd guess you have to choose the active port of Qt after having
>> both versions installed and MacPorts will create some links to
>> the active version for you. I don't know.
>> 
>> Regards, Stephan
> 
> Hmmm.... It looks like there are activate and deactivate commands for 
> MacPorts. I don't know how they handle things if one programs wants one 
> version and another program wants another version. Seems like this wouldn't 
> be allowed in general but I might get away with playing around for a bit.

I've put a change in to add the necessary -rpath options to the linker command 
line.
These are required to use the self-made Qt5.5.x and probably for the frameworks 
built by Digia.
Look at git commit 6e9bd23a1f1888b2022335b2d05a3f770ada935a

I'm not sure if this is enough to use the Digia frameworks.

Regards, Stephan

Reply via email to