Building mayo in conda environment on macOS

[andrsd]

If you are building mayo in conda environment on macOS, you can do so, but you will need to patch the build.

1. opencascade can be obtained via conda-forge channel conda install occt
2. You won't have libTKXSDRAW.dylib (most likely because they do not build it with conda)
3. You may have a conflicting libconv.dylib installed.

Patch the source with:

$ cd /path/to/mayo
$ git apply conda-build.patch

To build, use:

$ export CASCADE_BASE_DIR=$CONDA_PREFIX
$ qmake ../mayo CASCADE_INC_DIR=$CASCADE_BASE_DIR/include/opencascade CASCADE_LIB_DIR=$CASCADE_BASE_DIR/lib
$ make

conda-build.patch

[HuguesDelorme]

Hello, thank you so much for the hint. Do you know if there is a way to check any potential conflict with the iconv library? How did you install iconv library on your system?

Maybe users with the same build issue can try: $> qmake ../mayo "LIBS -= -liconv -lTKXSDRAW" "LIBS+=$SDKROOT/usr/lib/libiconv.2.tbd" ...

[andrsd]

How did you install iconv library on your system?

The system one (i.e. the .tbd one) comes from Xcode/CommandLineTools which is the Apple supplied tool chain. The offending one came via conda when installing opencascade. So, you cannot really get rid of that one :-(

Do you know if there is a way to check any potential conflict with the iconv library?

It could be a version collision, i.e. Apple's iconv have different version that the conda one. I can check that. The problem is that you use iconv, iconv_open and iconv_close and these symbols are in the system iconv, but they are named libiconv, libiconv_open and libiconv_close in the conda iconv. The linking step finds the conda iconv, because the conda environment is preferred over the system one (that's by design).

I can try that qmake command you provided - much better solution than patching the sources :+1:

[andrsd]

The qmake command works, but needs to have this form:

$ qmake ../mayo CASCADE_INC_DIR=$CASCADE_BASE_DIR/include/opencascade \
  CASCADE_LIB_DIR=$CASCADE_BASE_DIR/lib \
  -after "LIBS -= -liconv -lTKXSDRAW" "LIBS+=$SDKROOT/usr/lib/libiconv.2.tbd"

Then, all builds as expected without patching.

[HuguesDelorme]

Thanks for the feedback, for now I will add some "troubleshooting" notes on this iconv topic for the macOS build wiki page. Let's see later in the mid-term how to solve this iconv issue with some compiler checks in the qmake script.

[HuguesDelorme]

Hello @andrsd Do you think that these issues still happen with the CMake build process?

[andrsd]

Hi @HuguesDelorme !

1. iconv: cmake seems to find the system-wide iconv provided by Apple, so it is not using the "wrong" one provided by conda. So this is no longer a problem for me.

2. TKXSDRAW: conda provided opencascade does not have TKXSDRAW at all. But, the cmake build script is not linking this module explicitly like the qmake-based system was, so this is also fixed. However there was this issue that was fixed by explicitly linking TKXSDRAW. It can still be a thing. I assume OCCT can be build with that module enabled (or maybe it was a thing with an older version of OCCT - the one in conda right now is 7.7.x)

I tested this against 17fe28e627404a5884140bb96a09a3108664b67a (Apr 26, 2024) which is a bit older. IDK, if there were any further updates to the cmake-based scripts. All worked as expected.