MacOS Build Problem ..not finding libwx_baseu-3.2.dylib

[rgleason]

Loading these plugins fails due to not finding /usr/local/lib/libwx_baseu-3.2.dylib`

ERROR dlunix.cpp:120 Failed to load shared library '/Users/mr/Library/Application Support/OpenCPN/Contents/PlugIns/libdeviation_pi.dylib': dlopen(/Users/mr/Library/Application Support/OpenCPN/Contents/PlugIns/libdeviation_pi.dylib, 0x0002): Library not loaded: /usr/local/lib/libwx_baseu-3.2.dylib
https://www.cruisersforum.com/forums/f134/plugin-testing-all-operating-systems-needed-291446.html#post3969429

1. Polar 1.2.36.0 Download the tarball that fails
2. Squiddio 1.3.93 Download the tarball that fails
3. Deviation 0.1.62.0 Download the tarball that fails

Do earlier versions from Cloudsmith "Beta" repositories install properly?

Here are 3 darwin tarballs from Cloudsmith "beta" for squiddio_pi that could be tested for installation on MacOS that could be tested for loading properly.

Here are a number of darwin tarballs from Cloudsmith "beta" for polar_pi that could be tested for loading properly.

Here are a number of darwin tarballs from Cloudsmith "beta" for deviation_pi that could be tested for loading properly.

See these Forum Threads

Which TP Plugins fail to load in MacOS?
https://www.cruisersforum.com/forums/f134/plugin-testing-all-operating-systems-needed-291446.html#post3969429

Using Cloudsmith Beta tarballs which ones fail and which ones load?
https://www.cruisersforum.com/forums/f134/mac-os-plugin-squiddio-polar-and-deviation-failures-292254.html#post3969605

[rgleason]

Jon:

I did look in the squiddio_pi dylib and it had the correct library locations, the plugin was not looking for the libraries in the systems area. So I am not sure why when you run them they are.

The crowdsource plugin had other issues. It used extra submodules in a different directory to the opencpn-libs directory and the FE2 template was not updating them as it should. This particular issue was solved by making sure FE2 updated ALL submodules. The other issue was the these modules were not being included in the final dylib file as the way they were being incorporated into the build did not work. I gave a couple of examples of how to do it, but it was up to the developer to fix that issue (I know nothing about the plugin or how it works), as they are the one who understood what they were trying to do. The changes needed were in the 'plugin' area of the CMakeLists.txt file, i.e. the bits that are customised for the particular plugin, and not the general template.

Is the version of squiddio installable from the beta repositories on macOS via the internet?
I have not looked at squiddio and polar for this. I will try to get to it, but....

Dave:

Using ssh login to CCI build of polar_pi, I could look at the resulting tarball, expand it, and do "otool -L..."
And this looked fine, the wx library references all as expected.

However, after installing the plugin on the target system, running "otool -L ..." there produces links to /usr/local...
Very strange. Looks like somehow the wrong tarball was copied to Cloudsmith, or the wrong dyllib (the un-fixed one) was included in the tarball. But I cannot see how that would happen.
I've asked Pavel about this, will have better internet access in a couple of days, with better access.

Does any of this ring any bells for you?

[jongough]

I used the beta install for squiddio, 1.3.91.0, and it worked OK. Used the prod install, 1.3.93.0, and it failed with the library issue. So will need to look at the two versions and see if a change occurred in any of the build processes have changed that may affect the build.

[jongough]

The only two things that stand out at the moment is the move from OCPN API 117 to 118 and the removal of macos-deps.

[jongough]

I am trying to re-clone the squiddio repository, but there appear to be issues with opencpn-libs submodule and getting it to be up to date. I am getting clone errors from git saying the index is invalid.

[rgleason]

Humm, I will delete it and reinstall and push it to remote.

[rgleason]

Jon,

I've updated the version to 1.3.94 "1.3.94.0 + rm module + add module"

and pushed it. It should land in squiddio_prod
That was fast. It is there now. https://cloudsmith.io/~opencpn/repos/squiddio-prod/packages/?q=1.3.94+darwin+tarball
I hope this is the answer.

R

C:\Users\fcgle\source\squiddio_pi>mod-rm+add.bat

C:\Users\fcgle\source\squiddio_pi>REM Remove the current opencpn-libs submodule linkage and add new linkage

C:\Users\fcgle\source\squiddio_pi>git submodule deinit -f opencpn-libs
Cleared directory 'opencpn-libs'
Submodule 'opencpn-libs' (https://github.com/OpenCPN/opencpn-libs.git) unregistered for path 'opencpn-libs'

C:\Users\fcgle\source\squiddio_pi>git rm --cached opencpn-libs
rm 'opencpn-libs'

C:\Users\fcgle\source\squiddio_pi>rmdir /S .\.git\modules\opencpn-libs
.\.git\modules\opencpn-libs, Are you sure (Y/N)? y

C:\Users\fcgle\source\squiddio_pi>rmdir /S .\opencpn-libs
.\opencpn-libs, Are you sure (Y/N)? y

C:\Users\fcgle\source\squiddio_pi>git config -f .gitmodules --remove-section submodule.opencpn-libs

C:\Users\fcgle\source\squiddio_pi>git add .gitmodules

C:\Users\fcgle\source\squiddio_pi>git commit -m "Remove opencpn-libs submodule."
[master 2f32341] Remove opencpn-libs submodule.
 2 files changed, 4 deletions(-)
 delete mode 160000 opencpn-libs

C:\Users\fcgle\source\squiddio_pi>REM opencpn-libs linkage and files removed and  commit made

C:\Users\fcgle\source\squiddio_pi>REM Add the new linkage

C:\Users\fcgle\source\squiddio_pi>git submodule add https://github.com/OpenCPN/opencpn-libs.git
Cloning into 'C:/Users/fcgle/source/squiddio_pi/opencpn-libs'...
remote: Enumerating objects: 3338, done.
remote: Counting objects: 100% (85/85), done.
remote: Compressing objects: 100% (28/28), done.
remote: Total 3338 (delta 62), reused 71 (delta 57), pack-reused 3253 (from 2)
Receiving objects: 100% (3338/3338), 106.62 MiB | 2.96 MiB/s, done.
Resolving deltas: 100% (1656/1656), done.

C:\Users\fcgle\source\squiddio_pi>git commit -m "Adding revised opencpn-libs submodule main"
[master f0be0c0] Adding revised opencpn-libs submodule main
 2 files changed, 4 insertions(+)
 create mode 160000 opencpn-libs

C:\Users\fcgle\source\squiddio_pi>REM Added new linkage to module opencpn-libs main and made commit.

[bdbcat]

Gentlemen....
I think I have found the culprit.
A recent modification to the FE2 template changed the MacOS build script. I have reverted part of that commit, like so:

diff --git a/ci/circleci-build-macos-universal.sh b/ci/circleci-build-macos-universal.sh
index 7a4aebd..78057d6 100755
--- a/ci/circleci-build-macos-universal.sh
+++ b/ci/circleci-build-macos-universal.sh
@@ -74,12 +74,7 @@ fi
 
 # nor-reproducible error on first invocation, seemingly tarball-conf-stamp
 # is not created as required.
-make package || make package
+#make package || make package
+make
+make install
+make package
+make package
 
 # Create the cached /usr/local archive
 if [ -n "$CI"  ]; then

I cannot explain why the change works. It is something related to CMake, and the install->package step.
Is is clear that separating "make install" and "make package" targets into two steps has something to do with it. More cmake-fu required.

I leave it to Jon/Rick to make the FE2 template update, and promulgate to the affected plugins.
I would start with one plugin, prove it, and then implement everywhere.

[jongough]

That would suggest that for macOS there is a slightly different process invoked by make install than 'make packageas far as building all the requisite parts. Perhaps themake packagedoesn't do the fullmake install` process.

I am trying a build now with the install bit back in place.

[jongough]

Done a build with make install which errors due to not having permissions to install in a system location:

opt/homebrew/bin/cmake -P cmake_install.cmake
-- Install configuration: "Release"
CMake Error at cmake_install.cmake:41 (file):
  file cannot create directory: /OpenCPN.app/Contents/PlugIns.  Maybe need
  administrative privileges.

So that is not a solution.

It is surprising that most plugins are building and working OK, there are just three that seem to be problematic. I am trying to clone the squiddio_pi to try some builds where I can get to the output, but the clone is failing in opencpn-libs as, to me, there appears to be an error in the git submodule update --init process. Still working on it.

[bdbcat]

My test build on CCI, completes OK, build product sent to Cloudsmith Beta, and successfully imports and runs on live MacOS M1 machine.

https://app.circleci.com/pipelines/github/bdbcat/polar_pi/10/workflows/60429d3e-2dbd-41ec-bfbd-51f06ae4930e/jobs/197

Source at:
https://github.com/bdbcat/polar_pi

I think the trouble is that install location should not start with "/". That is, OpenCPN.app is a local directory in the build tree, required to create the proper tree structure in the tarball.
Also, install_prefix must be "".

[jongough]

Your build has the same issue when running make install, it fails to install the plugin. The make package does what it is supposed to and does update the libwx* files as shown at the end of the build process. If this installs OK then I would not think it is the make install doing it.

[bdbcat]

Maybe so. But I can see by using ssh login to CCI after the build, that in my build the dylib used by the "make package" step has been properly "path-adjusted", but only if the make install step runs separately from the "make package".
If I skip "make install", then the dylib used by "make package" has not been so adjusted. Who knows why...
And that is the root of the problem we are trying to solve.

The complication here is that we need to run the "path adjust" step between "make" and "make install". We are depending upon CMake to do this correctly if we use the shortcut "make package". We expect CMake to do this as part of the "install" step, and pass that along to the "package" step. And it is clear by experiment that it does not do this correctly.

So, I suggest to simply be more explicit in our "make" invocations, as we did earlier. And all will be well.

[rgleason]

What an experience, waking up and finding that you are both hot on the trail! How wonderful. Thank you!

[bdbcat]

I note in passing:
weatherfax_pi current build, which I think is current production:
https://github.com/rgleason/weatherfax_pi

contains the following code snippet.

make
make install
make package
make package

And this is known to work on MacOS.