macdeployqt.py picks the wrong version of the dependencies if they're present in the $PATH

[ArthurChiao]

Expected behaviour

On MAC OSX, build the installer, install it, then start it successfully.

More about the building process see my sharing in #5594 .

Actual behaviour

Build & install ok, but client crashed on starting.

Crash info from command line:

$ /Applications/owncloud.app/Contents/MacOS/owncloud --logwindow
dyld: Library not loaded: /usr/lib/libxml2.2.dylib
  Referenced from: /Applications/owncloud.app/Contents/Frameworks/QtWebKit.framework/Versions/5/QtWebKit
  Reason: Incompatible library version: QtWebKit requires version 12.0.0 or later, but libxml2.2.dylib provides version 10.0.0
[2]    50423 abort      /Applications/owncloud.app/Contents/MacOS/owncloud --logwindow

OS and software

• OS: MAC OSX 10.12.6
• xcode: 9.1 (full version, download from App Store)
• brew: 1.3.6
• MacPorts: 2.4.0
• client: 2.2 (customized, but i think official client code should also be ok)
• QT: 5.5.1 (get through qmake --version)
• qt-webkit: ? (installed through macport)

Root Cause

I have two libxml2.2.dylibs in my system, each in /usr/lib and /opt/local/lib. The one in /usr/lib/ is old but in protected (restricted) mode, I could not upgrade it. The new one is automatically installed as dependent libs by sudo port install qt5 qt5-webkit.

I could start the compiled client successfully (pre-packaging), which uses /opt/local/lib/libxml2.2.dylib, but the packaged one will crash, which uses /usr/lib/libxml2.2.dylib.

Looking into the packaging code, I found that in macdeployqt.py, the script checks all dependent libraries in /lib and /usr/lib see code here, if found, it will make the later installed client load the corresponding libarary from the path.

So, i think here is the root cause: the script detects the lib exists in /usr/lib, then make the to-be-installed-client to load the lib from there, before verifiying that whether the version meets the client needs.

The libxml2.2.dylib is not the only one suffers from this, but the first one to be loaded, which directly causes the client to crash.

[ArthurChiao]

I didn't look too much into the packaging code, for a quick fix, I removed the library detection code by letting it directly return None, the installer now works ok.

I've tested it on some other MAC machines except my dev one.

[SamuAlfageme]

Thanks for pointing this out @ArthurChiao - indeed improving the packaging script is in the client's roadmap (see #5447), a replacement is very likely to happen in the near future.

[ArthurChiao]

@SamuAlfageme nice! Drop me a message if i could be of any help.

[guruz]

#6423

[TheOneRing]

We no longer use the script.