Build problem with MacOSx (Catalina)

2020/10/27

Helen Middleton from CSA team has recently reported a problem while building CEFlib for Python on Mac OSX Catalina.

But same problem should occurs also when building the IDL or Matalb library.

She wrote some notes on CSA FAQ web page:

Q11: How I installed CEFLIB for Python on Catalina

This problem is related to a missing header file in LIB/inc/COMPAT.h:

#include "values.h"

This line has to be replaced with:

#include "limits.h"

We will probably provide a new release of CEFLIB, but we have to check before if this modification doesn’t break CEFlib installation procedure on older platforms.

Software requirements on MacOSX (any release)

In order to build the CEFLIB API on MacOSX, either for IDL or MATLAB, you will need to install first the XCode application.

Note

Some incompatibilities have been found between Matlab and Xcode on MacOSX "El Capitan".

Read More…

Afterwards, you will need to install some Xcode optional tools :

  • Command Line Tools

  • System Tools

  • Unix Development

Problem with Matlab API on MacOSX "El Capitan"

It seems there are incompatibilities between Matlab/Xcode with MacOSX "El Capitan".

Combination that works:

  • MacOSX El Capitan

  • CEFLIB v1.8.0

  • Xcode 7.2

  • Matlab 2016a

Combination that doesn’t works:

  • MacOSX El Capitan

  • CEFLIB v1.7.3

  • Xcode 7.x

  • Matlab 2015

When using an older MacOSX version (Darwin, Yosemite,…) you can use:

  • CEFLIB v1.7.3 (or upper)

  • Xcode 7.x

  • Matlab 2014 (or lower)

Not all combinations could be tested, so we encourage you to check for software requirements on Matlab Web site :

http://mathworks.com/support

Problem with CEFLIB 1.7.1 on Fedora 19 computer

This bug was discovered on 2013/09/26 by Nalaliya Bourrel, when building the CEFLIB C API in a Fedora Core 19 computer.

This Linux distribution embed zlib-1.2.7 package, which has a different interface, and the build process failed.

This zlib version redefines the gzFile data type, that was previously :

typedef voidp           gzFile;

And becomes now :

typedef struct gzFile_s *gzFile;        /* semi-opaque gzip file descriptor */

Some changes were necessary in the following files :

  • LIB/inc/ZZLIB.h

  • LIB/src/ZZLIB.c

  • C/src/CEF.c

Caution These changes don’t break software compatibiliy with previous versions of zlib library.

Problem with CEFLIB MATLAB API on MacOSX "Mountain Lion"

This bug was detected by Arnaud MASSON, while building the MATLAB CEFLIB API on his MacOSX computer (Mountain Lion).

There was a problem to find the gcc compiler used to build the library.

2 solutions were found :

Solution that needs "Administrator" privileges

Update the file :

/Applications/MATLABRxxxx/bin/mexopts.sh

Where MATLABRxxxx has to be replaced by the Matlab version installed on your computer.

Search the following lines :

case $Arch in
...
maci64)
        CC='gcc-4.2'

And replace with :

CC='gcc'

Solution for regular system users

Run the followind command in your Matlab command window :

mex -setup

That will create a copy of the /Applications/MATLABRxxx/bin/mexopts.sh under :

/Users/<username>/.matlab/mexopts.sh

Now, update the mexopts.sh file, as described in the previous paragraph, replacing :

CC='gcc-4.2'

By :

CC='gcc'

Header files conflict under MacOS

MacOSX system accepts both case-sensitive and case-insensitive file systems, and that can generate a bug while building the CEFLIB.

If the source tree is extracted in a case-insensitive file system, there is a conflict between the two following files :

/usr/include/zlib.h
CEFLIB/LIB/inc/ZLIB.h

The first one is the zlib original header file installed on each system.

The second one contains some overloaded functions to be used with the CEFLIB, and needs to include the first one to work.

Obviously, on case-insensitive file systems, with included header path directives, when we try to include the first one, the system chooses the second one and building process fails.

If the library is extracted on a case-sensitive file system (ZFS for example), this problem doesn’t occur.

A solution should be to rename the uppercase ZLIB.h to avoid such problem.

This will be done for the next release V1.7

Bug with ZLIB

A bug was found while using the CEFLIB IDL interface on CentOS 5.6 x86_64 architecture

It seems that this bug came from /usr/lib64/libz.so ⇒ /usr/lib64/libz.so.1.2.3

Solution

Download source code from www.zlib.org ⇒ zlib-1.2.5.tar.gz

$ gzip -d zlib-1.2.5.tar.gz
$ tar xvf zlib_1.2.5.tar
$ cd zlib-1.2.5
$ ./configure
$ make

Add the directory to LD_LIBRARY_PATH :

$ export LD_LIBRARY_PATH=/home/cisdds/zlib-1.2.5

Check dynamic linkage of idl_cef.so :

$ ldd /DATA/CLUSTER/SOFT/CEFLID_IDL/bin/idl_cef.so
linux-vdso.so.1 =>  (0x00007fff84736000)
libz.so.1 => /home/cisdds/zlib-1.2.5/libz.so.1 (0x00002b6fd4308000)
libc.so.6 => /lib64/libc.so.6 (0x00002b6fd4538000)
/lib64/ld-linux-x86-64.so.2 (0x0000003091800000)

Try using CEFLIB from IDL :

$ idl
IDL> n = cef_read("C3_CP_CIS-HIA_ONBOARD_MOMENTS__20080101_V08.cef.gz"
% Loaded DLM: CEF.
1 : CEF.Open_CEF_file              : C3_CP_CIS-HIA_ONBOARD_MOMENTS__20080101_V08.cef.gz
1 : CEF.Read_CEF_header            : 20725 records found in 0.04 seconds
1 : CEF.Read_CEF_header            : 24 values per record
1 : CEF.Display_variables          : 12 variables + 0 constants
1 : CEF.Read_CEF_file              : 20725 records physically read in 0.07 seconds
1 : CEF.Read_CEF_file              : STATUS = 0 : OK : Terminaison correcte