thank you both, autoload in PKG_ADD indeed solved the problem I have.
1 Like
Iâm not opposed to supporting the mexext names, but it has a low priority for me. The names used by Matlab are a bit limited and Iâm not really interested in attempting to support undocumented names.
Since the (old) MEX interface uses a set of C language functions, itâs possible that you could compile a MEX file with different compiler than the one used for building Octave.
When mkoctfile builds a MEX file, it doesnât link with any Octave libraries. Any required MEX interface functions are expected to be accessed from the Octave binary that loads it.
Although it seems that it should be possible to use a MEX file built by Matlab in Octave, I donât expect that would always work. Does Matlab link MEX files with Matlab-specific libraries? Likewise, MEX files built with Octave might not always work with Matlab. Also, the interface has changed over time and Octave makes no attempt to support past interfaces through versioned symbol names.
As for legalities, we canât provide any certain advice but some thoughts about our general intent may be found in the Octave FAQ.
thanks @jwe for chiming in.
When mkoctfile builds a MEX file, it doesnât link with any Octave libraries. Any required MEX interface functions are expected to be accessed from the Octave binary that loads it.
it is interesting that you mention this. I noticed that older versions of mkoctfile (4.2.2) does link various octave libraries for --mex output. I just tested my OpenCL based toolbox (mmclab, built with make oct inside the src folder, output is ../mmclab/mmc.mex), ldd prints a number of octave related libraries, and many others are perhaps dependencies to octave, but not to this toolbox, see
fangq@ubuntu18_04$ ldd mmc.mex
linux-vdso.so.1 (0x00007ffeff1a4000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8219a54000)
libOpenCL.so.1 => /usr/local/cuda/lib64/libOpenCL.so.1 (0x00007f821984d000)
liboctinterp.so.4 => /usr/lib/x86_64-linux-gnu/liboctinterp.so.4 (0x00007f82185f3000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f821826a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8217ecc000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f8217c9d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8217a85000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8217866000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8217475000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8217271000)
liboctave.so.4 => /usr/lib/x86_64-linux-gnu/liboctave.so.4 (0x00007f8216070000)
libhdf5_serial.so.100 => /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.100 (0x00007f8215b18000)
libGraphicsMagick++-Q16.so.12 => /usr/lib/libGraphicsMagick++-Q16.so.12 (0x00007f82158a8000)
libGraphicsMagick-Q16.so.3 => /usr/lib/libGraphicsMagick-Q16.so.3 (0x00007f8215351000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f82150c5000)
libGLU.so.1 => /usr/lib/x86_64-linux-gnu/libGLU.so.1 (0x00007f8214e56000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f8214c11000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f821495d000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f8214625000)
libgl2ps.so.1.4 => /usr/lib/x86_64-linux-gnu/libgl2ps.so.1.4 (0x00007f8214411000)
liblapack.so.3 => /usr/lib/x86_64-linux-gnu/liblapack.so.3 (0x00007f8213b52000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8219f10000)
libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007f82138d2000)
libcholmod.so.3 => /usr/lib/x86_64-linux-gnu/libcholmod.so.3 (0x00007f82135fc000)
libumfpack.so.5 => /usr/lib/x86_64-linux-gnu/libumfpack.so.5 (0x00007f8213350000)
libcxsparse.so.3 => /usr/lib/x86_64-linux-gnu/libcxsparse.so.3 (0x00007f8213125000)
libsuitesparseconfig.so.5 => /usr/lib/x86_64-linux-gnu/libsuitesparseconfig.so.5 (0x00007f8212f22000)
libarpack.so.2 => /usr/lib/x86_64-linux-gnu/libarpack.so.2 (0x00007f8212cd8000)
libqrupdate.so.1 => /usr/lib/x86_64-linux-gnu/libqrupdate.so.1 (0x00007f8212ac0000)
libfftw3_threads.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3_threads.so.3 (0x00007f82128b9000)
libfftw3.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3.so.3 (0x00007f82124b7000)
libfftw3f_threads.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3f_threads.so.3 (0x00007f82122b0000)
libfftw3f.so.3 => /usr/lib/x86_64-linux-gnu/libfftw3f.so.3 (0x00007f8211ea3000)
libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007f82118e1000)
libreadline.so.7 => /lib/x86_64-linux-gnu/libreadline.so.7 (0x00007f8211698000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f8211426000)
libgfortran.so.4 => /usr/lib/x86_64-linux-gnu/libgfortran.so.4 (0x00007f8211047000)
libsz.so.2 => /usr/lib/x86_64-linux-gnu/libsz.so.2 (0x00007f8210e44000)
libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007f8210c36000)
libwebp.so.6 => /usr/lib/x86_64-linux-gnu/libwebp.so.6 (0x00007f82109cd000)
libwebpmux.so.3 => /usr/lib/x86_64-linux-gnu/libwebpmux.so.3 (0x00007f82107c3000)
liblcms2.so.2 => /usr/lib/x86_64-linux-gnu/liblcms2.so.2 (0x00007f821056b000)
libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x00007f82102f4000)
libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f821008c000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f820fe5a000)
libwmflite-0.2.so.7 => /usr/lib/x86_64-linux-gnu/libwmflite-0.2.so.7 (0x00007f820fc3c000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f820fa2a000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f820f81a000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f820f459000)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f820f228000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f820ef72000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f820ed40000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f820eb18000)
libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f820e8f3000)
libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f820e6d6000)
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f820e4ba000)
libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f820e2ac000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x00007f820e076000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f820dd10000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f820dac5000)
libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f820d873000)
liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f820d665000)
libamd.so.2 => /usr/lib/x86_64-linux-gnu/libamd.so.2 (0x00007f820d45c000)
libcolamd.so.2 => /usr/lib/x86_64-linux-gnu/libcolamd.so.2 (0x00007f820d255000)
libccolamd.so.2 => /usr/lib/x86_64-linux-gnu/libccolamd.so.2 (0x00007f820d04b000)
libcamd.so.2 => /usr/lib/x86_64-linux-gnu/libcamd.so.2 (0x00007f820ce41000)
libmetis.so.5 => /usr/lib/x86_64-linux-gnu/libmetis.so.5 (0x00007f820cbd3000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f820c9cb000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f820c7a1000)
libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f820c561000)
libaec.so.0 => /usr/lib/x86_64-linux-gnu/libaec.so.0 (0x00007f820c359000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f820c133000)
libicuuc.so.60 => /usr/lib/x86_64-linux-gnu/libicuuc.so.60 (0x00007f820bd7b000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f820bb77000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f820b971000)
libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f820b5f3000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x00007f820b3bd000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f820b13c000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f820ae0d000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f820abfa000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f820a924000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f820a6f2000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f820a4ee000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f820a2e3000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f820a0c9000)
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f8209eae000)
libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f8209c6d000)
libicudata.so.60 => /usr/lib/x86_64-linux-gnu/libicudata.so.60 (0x00007f82080c4000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f8207eaf000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f8207ca7000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f8207aa3000)
libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f820789a000)
libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f820760d000)
libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f820736b000)
libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f8207135000)
libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007f8206f1f000)
libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007f8206cf6000)
libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f8206ae7000)
libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f820689d000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f8206594000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f820635c000)
however, compiling the same mex file using mkoctfile 5.2.0 on Ubuntu 20.04, the linked libraries are much cleaner - and as you said, none of the octave-specific libraries are needed.
fangq@ubuntu20_04$ ldd mmc.mex
linux-vdso.so.1 (0x00007ffe9e7fe000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe0c218b000)
libOpenCL.so.1 => /usr/lib/x86_64-linux-gnu/libOpenCL.so.1 (0x00007fe0c1f80000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe0c1d9e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe0c1c4f000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007fe0c1c0d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe0c1bf2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe0c19fe000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe0c19f8000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe0c2291000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe0c19d5000)
As for legalities, we canât provide any certain advice but some thoughts about our general intent may be found in the Octave FAQ.
I wish I had read the FAQ section you pointed out, very clear and useful.
Almost all of the toolboxes I wrote are for research purposes and they are all released under open-source licenses. The reason that I used the mex interface instead of oct is not because I intend to work with proprietary libraries, but rather simplifying the maintenance by writing a single C code to work for both MATLAB and Octave. I do understand that oct has some speed advantages in certain operations and helps building more attractions for octave.
Nearly all my packages only use open-source licensed libraries, the only complication is CUDA (libcudart.so) and OpenCL (libOpenCL.so) for high-performance computing. For mex files built with dynamic linking for either of these libraries, I think it is likely fine - the linking happens in the user-land, so should be permitted. Only when statically linking CUDA (-lcudart_static) could cause a license issue if the binary package is to be released.
We are currently collaborating with AMD to use hipcc/rocm to run my CUDA codes, overall it works fine, only some minor performance downgrades that need to be addressed. In the long term, hopeful ROCm will offer an open-source solution for many CUDA related codes.
1 Like
yes, for basic mexFunction APIs, it usually has links to libmx.so and libmex.so, although these files do not have a version - so a mex file compiled on older MATLAB usually works fine with all newer versions. For example, this is the ldd output from a MATLAB mex compiled mex file (and libmx/libmex will be linked inside MATLAB)
fangq@~/git/Project/github/zmat$ ldd zipmat.mexa64
linux-vdso.so.1 (0x00007ffed932e000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f5eaed9c000)
libmx.so => not found
libmex.so => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5eaebba000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5eae9c8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5eae879000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5eaee46000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5eae85c000)
one of my observations for mkoctfile --mex generated mex file usually link with version-specific liboctinterp.so, such as /usr/lib/x86_64-linux-gnu/liboctinterp.so.4, and wonât run directly when a different version of Octave is installed, however, as I mentioned above, using mkoctfile 5.2 seems to have eliminated this dependency, so this is no longer an issue.