About FET dialog issue

[math]

I just downloaded the OSX version of FET 5.42.2 as provided at Darren's website. In the english translation the "About FET" menu item presents the "About libraries" dialog. In consequence, there is not "About libraries" menu item.

This problem also occurs in the most recent snapshot fet-5.42.3-snapshot-27-jan-2020-01_16.

When I switch to german translation, all entries are correct, so I assume a problem in the english translation.

[Liviu Lalescu]

Thank you for your bug report!

Darren and me and Volker, we know about it. I will write messages to them to also look at this topic.

Probably Mac OS X has a distinct way of treating the Help menu, and if it finds "About ... something" it wants to put it in another place, on the left of the other menu items, and in Help there will remain the rest of the items. But this is not computed perfectly with the latest FET versions.

I attach a screenshot of how FET Help menu should look like (GNU/Linux).

I think we cannot solve this.

[Volker Dirr]

I fear it is a known bug/feature. See https://doc.qt.io/qt-5/macos-issues.html

[math]

Hi!

I really never noticed that the "About fet" entry in the english translation appears under the Apple sign while the german translation appears under "Hilfe" (Help). But you're right, that's really stunning.

But I don't understand why the "About libraries" item does not appear under the Apple sign, but only "About fet" and "About qt". When selecting the german translation, all three items appear under "Hilfe".

And I don't understand why the library dialog shows up when selecting the "About fet" menu item. That not just a menu item that has been moved to a different location, it's a menu item that shows the wrong content. (and that clearly worked in all the previous versions of FET. I used that a lot: when compiling my own FET binaries, I checked that item for ensuring that I started the right binary.)

[Liviu Lalescu]

It is easy: Qt checks the test on the items and moves them if considers so! 

I will fix now, I'll put a new snapshot in 30-60 minutes. Please stay tuned and confirm the problems are gone. I will announce soon the snapshot, I hope you can compile and tell me before tomorrow afternoon, when I planned to release the new FET-5.42.3.

Also the Quit button will be added in the proper place even in German (I assume now it is not).

[Liviu Lalescu]

I added the snapshot in the usual location: https://lalescu.ro/liviu/fet/download/test/

Please let me know as soon as possible if this is solved. I hope to release Saturday February 1st, afternoon.

Things to check:

Please check in English and German each: Quit with mouse, Quit with Ctrl+Q or Ctrl+B; menu About fet and About Qt; Help About libraries.

Generate once with fet-cl. Run fet-cl and ensure it shows the usage instructions.

[math]

FET is working perfectly, thanks a lot. fet-cl is returning the following error on startup:

dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore
  Referenced from: /Users/math/FET/fet-5.42.3/fet-cl
  Reason: image not found
Abort trap: 6

[Liviu Lalescu]

Unfortunately this is from Darren. He did not package or link fet-cl or its libraries. I will redirect him to your post, maybe he can modify his Mac OS X package.

PS: Could you please verify fet-cl on Darren's previous FET versions or compile from the sources FET-5.42.3 official? I hope it is not from me, but we need to compare with these.

[Darren McDonald]

Hi everyone, I hadn't been including fet-cl in the Mac version for some time now, since I remember we encountered an issue several releases ago (and since most people are likely to use the app, I had simply stopped distributing fet-cl).

If anyone can help with getting it working I'm happy to start including it again, but I'm afraid this is beyond my current skill level!

[math]

In a self-compiled version fet-cl is working perfectly.

As far as I understood, OSX does not have something like a library path where the operating system is looking for suitable libraries. Instead each binary can specify a set of directories that are scanned, that's the rpath. Details on this can be displayed with:

Code Select Expand

otool -l fet-cl

In the case of Darren's binary this is:

Code Select Expand

Load command 17
          cmd LC_RPATH
      cmdsize 48
         path @executable_path/../Frameworks (offset 12)
Load command 18
          cmd LC_RPATH
      cmdsize 64
         path /Users/darrenmcdonald/Qt/5.14.1/clang_64/lib (offset 12)

Since these paths do no exist on my system, the qt libraries cannot be found.

When I compile FET myself, the fet-cl binary does not refer to an rpath but an absolute path instead.

Darren:

Code Select Expand

otool -L fet-cl
@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.14.0, current version 5.14.1)


My version:

Code Select Expand

/opt/local/libexec/qt5/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.14.0, current version 5.14.0)

Unfortunately I have no idea how to trigger this. Maybe we have an experienced developer here?

[math]

This seems to be a solution. First I had to remove the RPATH entries of Darren's fet-cl binary:

Code Select Expand

install_name_tool -delete_rpath "/Users/darrenmcdonald/Qt/5.14.1/clang_64/lib" fet-cl
install_name_tool -delete_rpath "@executable_path/../Frameworks" fet-cl

Then I added the default QT path:

Code Select Expand

install_name_tool -add_rpath "/opt/local/libexec/qt5/lib" fet-cl

After these commands I was able to execute Darren's binary.

Btw: Darren, thank you so much for providing us with binaries for OSX. I really appreciate this service!

[Volker Dirr]

I fear most guys haven't installed Qt on their computer.

[math]

Fair point. But since OSX does not support statically linked binaries, we need to have the library available somewhere. My only idea is to use the library shipped within the fet.app. So it's two more lines:

Code Select Expand

install_name_tool -delete_rpath "/Users/darrenmcdonald/Qt/5.14.1/clang_64/lib" fet-cl
install_name_tool -delete_rpath "@executable_path/../Frameworks" fet-cl
install_name_tool -add_rpath "/opt/local/libexec/qt5/lib" fet-cl
install_name_tool -add_rpath "fet.app/Contents/Frameworks/" fet-cl
install_name_tool -add_rpath "@executable_path/fet.app/Contents/Frameworks/" fet-cl


This way the system first searches QT in its default directory. If it is not available there, it looks for a fet.app in the current directory and at last for a fet.app in the standard executable path.

[Liviu Lalescu]

Yes, and I am not sure, but also Qt under GNU (L)GPL might require that you distribute either the sources (of FET+Qt?) or if you distribute the binaries you must only distribute dynamically linked Qt libraries (but as I said, I am not sure).

I think it would be best to use the Qt libraries distributed with the fet GUI.

But I am not the best person here to talk about the Mac executable. Thank you Darren for your commitment to compile FET for Mac!

Edit: and of course thank you math for your research on this!

[Darren McDonald]

Hi everyone, I've been looking into this, and there are some issues that make distributing a working Mac command line executable difficult to prepare, particularly for the latest Mac operating system (Catalina).

Catalina introduces some new security restrictions (using something called Gatekeeper), that, among other things, requires the FET app to be given permission to run when it is first used (this behaviour is not new).

In Catalina Gatekeeper has become even more restrictive. After making the changes suggested by math (thanks for your work on this!), there may still be issues for those using Catalina.

For example, while I can run fet-cl on the Mac I use to compile FET, when I use my other laptop I get an error on trying to load the Qt library (the one included in FET).

Here's the terminal error.

Code Select Expand

% /Applications/fet-5.42.3/fet-cl ; exit;
dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore
  Referenced from: /Applications/fet-5.42.3/fet-cl
  Reason: no suitable image found.  Did find:
/Applications/fet-5.42.3/fet.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore: code signature in (/Applications/fet-5.42.3/fet.app/Contents/Frameworks/QtCore.framework/Versions/5/QtCore) not valid for use in process using Library Validation: library load disallowed by system policy

In short, Gatekeeper won't allow executables to refer to shared libraries in the manner we've tried here. I think it may work with a reference to the library installed with Qt, but typical users won't have this installed. This error can be resolved by disabling Gatekeeper (via a terminal command), but all of these hurdles are likely to make it very complex for a typical user to get the command line version of FET running on a Mac. For this reason, I've not included fet-cl in the distribution version of 5.43.1, and I think we should simply recommend that anyone looking to use the command line version of FET on a Mac should compile FET themselves. This shouldn't be too much of an obstacle, since if they're interested in using the command line, they're probably able to compile FET as well!