WebViewerCEF.bundle / Chromium Embedded Framework error on 4D launch

I’m trying to upgrade a server from 17.2 HF1 to 17.4 HF1, and I’m getting an error on client startup I’ve never seen before (shown below), “Failed to load library” followed by the path to “WebViewerCEF.bundle”, then another “Library not loaded: @rpath/Frameworks/Chromium Embedded Framework.framework/Chromium Embedded Framework”. Looking in the Library folder on the machine, there is no “Chromium Embedded Framework” installed. The application seems to run OK once this alert is closed.

It’s a built & merged server running on Windows Server 2012 with a Mojave client, but I’ve duplicated the issue running the server on a Windows 10 server and Catalina client.

The same error comes up running 17.4 as downloaded from 4D’s “current versions” page.

The error DOES NOT come up running 17.2 HF1 on the same combinations of server and client.

Has anyone run into this before, and figured out a way around it? It seems like 4D is looking for a library that doesn’t exist, but I’m not sure how to talk 4D out of looking for it.

Thanks,
Ben

EDIT: Edited image to remove client’s name from pathnames

You can find some clues in this component code:

see the method “TEST” and search for “CEF”.

Thanks for the reply. I took a look at the component, but since I’m not familiar with code signing at all, I’m not really able to follow it all that well or figure out what I need to do to get this working.

I’m trying to build a cross-platform client/server application on Windows, and if the issue is that the Mac client application for 17.4 isn’t properly code signed, do I need to do that myself for the 4D Volume Desktop application on the Mac side, and then copy that over to the Windows VM that I’m using to build the server? Or is this as simple as removing/replacing some things in the 4D Volume Desktop app?

All of my builds using 17.2 HF1 have worked fine; did that much change between that version and 17.4?

The piece of code related to CEF does not concern code signing.

There is a “rogue” symbolic link file. You could replace it with a real copy of the CEF but since CEF is already more than 50% of the app size, you wouldn’t want to do that. The code modifies the loader path using a relative path (../../).

This issue happens on current OS when you build your Mac Client on a Windows computer.
That’s the only case I’m aware.

Please confirm if you build the Mac Client on Mac or on Windows?

I tried running the following code:

$componentPath:=$path+ New collection ("";"Contents";"Native Components";"WebViewerCEF.bundle";"Contents";"Frameworks";"4D Helper.app";"Contents";"MacOS";"4D Helper").join (Folder separator)
$from:="@executable_path/../Frameworks/Chromium Embedded Framework.framework/Chromium Embedded Framework"
$to:="@executable_path/../../../../Frameworks/Chromium Embedded Framework.framework/Chromium Embedded Framework"
install_name_tool ($componentPath;$from;$to)

… with $path set to the 4D Volume Desktop.app for 17.4 HF1. It runs successfully (or at least doesn’t return an error in the “install_name_tool” method).

I copied the modified Volume Desktop app over to the Windows machine to build the server. It didn’t work - I’m still getting the error after connecting to the server with the old version of the client and then having 4D upgrade the client application. The upgrade works, but then shows the error when the new version launches.

I’m trying to create a built & merged server on Windows, using the auto-update option to upgrade the clients that are currently running 17.2 HF1. I’m not building the Mac client at all - I’m including the 4D Volume Desktop app when I build the server on Windows, and letting 4D handle the client upgrade when they connect with the old version of the client.

How would I build the client on the Mac and include that in the server application that will be running on the Windows server?

Some years ago it was possible for us to build a Mac application on Windows.
Or more exact: we build the parts - and the updater merged that on update together as application.
Apple does not allow that any longer, Gatekeeper makes it very hard.
Even while some tricks still sometimes work, it will destroy the signature, so Gatekeeper will not trust this app.

As result, while it worked in the past, building on the “other” platform will need to be removed sooner or later.

So you need to build once on Mac and once on Windows.
As you are only interested in the Windows server, when both build, copy the Archive.mac from the updater folder from Mac into the updater folder on Windows. You do not need to build Mac on Windows any longer, as it will not be useable anyway. The only thing you need to exchange is the client archive.

1 Like

I’m having the exact same problem. But I don’t see how the error about not being able to load the Chromium Embedded Framework has anything to do with GateKeeper. If you acknowledge the error, it continues to launch normally.

Thanks Thomas - I tested it both on my machine and my client’s test environment, and I can confirm your solution works. Thank you!

I agree with Richard, though - this doesn’t seem like a Gatekeeper issue. The same process (building the Mac client update on Windows) works fine in 17.2 running on the same server and clients 17.4 fails on, and the error displayed with 17.4 isn’t a Gatekeeper message - it’s a 4D alert. It seems the issue is 17.4 not properly creating (or copying) the framework link.

At any rate, I’m glad to have a working version just in time to do my server update tonight. Thanks again, and thanks Miyako for your replies.