eCAL record application doesn't work on MacOS

[harlenli2022]

Dear eCAL Team,

I'm trying to build eCAL in MacOS, reference to the workflow of build-macos.yml, I had built eCAL successfully in my Mac.
Seems all apps work fine except record function, once record app launched, it will report below Protobuf related errors:

[libprotobuf ERROR /Users/HarlenLI/workspace/ecal/thirdparty/protobuf/src/google/protobuf/descriptor_database.cc:120] File already exists in database: ecal/pb/host.proto
[libprotobuf FATAL /Users/HarlenLI/workspace/ecal/thirdparty/protobuf/src/google/protobuf/descriptor.cc:1356] CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size):
libc++abi: terminating with uncaught exception of type google::protobuf::FatalException: CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size):

My source environment is forked eCAL master branch in commit 33de7e8, all submodules keep the original tags/commits.
so the Protobuf repository used in my workspace is v3.11.4, I also installed the built v3.11.4 Protobuf into my system.

btw, with same repository deployment, everything works fine in Ubuntu 18.4.

Best regards,
Harlen

[FlorianReimold]

Hi Harlen,

The macOS support is experimental at the moment. I have also noticed that issue in the past, when I worked on the macOS Support. When debugging with QtCreator I remember that the crash occured before the application even entered the main() function.

When I look at the error message now, this looks to me like some kind of static / shared library linking / loading issue.

Let's say for example, that ecal_rec loads 2 shared libraries:

• lib_a.so (contains ecal/pb/host.proto)
• lib_b.so (also contains ecal/pb/host.proto)

now the ecal/pb/host.proto is added to protobufs internal database by boths libraries. This will cause an exception.

Debugging on macOS is very hard for us due to the closed Apple ecosystem. Neither of us owns a (recent) mac. So you will have to help us out here.

Can you do the following:

• Start ecal_rec_client, which is the most minimalistic rec appliction in eCAL and see if it crashes
• Trace the loaded shared libs up until the crash. On Linux you would do that with gdb.

Maybe then we will at least be able to see which lib causes the crash.

Regards
Florian

[harlenli2022]

Hi Florian,

As your comment, ecal_rec_client can be started normal.
I also tried to find out the libs which included host.proto via command 'grep -rnw host.proto', the result as below:

Then I checked link status of rec client and rec gui, the result as below:


Now, we can see, both libecal_pb and libecal_core were linked by ecal_rec_gui, instead only libecal_core was linked by ecal_rec_client.
Check the CMakeLists of libecal_core, libecal_pb has been linked to libecal_core already:

but in CMakeLists of ecal_rec_gui, both libs were added to target link libraries

After remove eCAL::pb library linking in ecal_rec_gui, then rec gui can be launched now~~

Best regards,
Harlen

[Kerstin-Keller]

@harlenli2022,

thanks for this analysis. I think your solution to remove eCAL::pb from the linking in ecal_rec_gui is fine for the moment.
Now that I think about why it doesn't crash on Ubuntu, it's because you compile eCAL::pb as a static lib (libecal_pb.a), while the default build on Ubuntu is to build with -DBUILD_SHARED_LIBS=ON. You then get a libecal_pb.so/dylib which contains the symbols for the eCAL proto datatypes only once.

Can you build eCAL instead with -DBUILD_SHARED_LIBS=ON? Is there any reason you are not doing it? I though this was also the default on MacOS.

[harlenli2022]

hi @Kerstin-Keller

Regarding the build options in macos, I refered to .github/workflow/build-macos.yml, BUILD_SHARED_LIBS was not set here.

What's more, in ecal/pb/CMakeLists.txt, the library ecal_pb was added as static lib:
ecal_add_static_library(${PROJECT_NAME} src/ecalpb.cpp)
So even BUILD_SHARED_LIBS set to ON, libecal_pb will still be built as static lib...

Best regards,
Harlen

[Kerstin-Keller]

Thanks for pointing it out.
Can you replace it with ecal_add_library . To me it's not 100% clear why it would be forced to be a static library.
And again, then it doesn't explain why it won't crash on Ubuntu 😞