Fixing jcvoronoi_mex build failure on ubuntu in MTEX 6.1

[argerlt]

This is less a bug report, more just creating a paper trail in hopes the next person doesn't also accidentally lose a day to library errors.

April 27th, 2026: edited to reflect feedback from @kilir and @vtvivian

If you are:

1. a Linux user
2. using a newer version of MATLAB (2025b for me)
3. using MTEX 6.1 to automatically download the correct .mexa64 files for you,

You might run into the same issue I did, where jcvoronoi_mex gives a Failure result during MTEX's install, and then a variation of the following error when running calcGrains:

 checking: jcvoronoi_mex.mexa64 failed
  --> [Invalid MEX-file '/path/to/mtex/mtex-6.1.0/mex/jcvoronoi_mex.mexa64': /path/to/matlab/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by jcvoronoi_mex.mexa64)]

This (I believe?) is because jcvoronoi is the only MTEX mex that is compiled from .cpp, and the version it's compiled with needs to match the libstdc++.so.6 INSIDE THE MATLAB INSTALL.

The three solutions that have worked for me:

Option A: soft link your own libstdc++.so.6

Inside the system terminal (not the MATLAB one), find where the MATLAB libstdc++.so.6 file is (usually sys/os/glnx64), move it somewhere else as a backup, and replace it with a softlink to your local library.

        cd <matlabroot>/sys/os/glnxa64 
        sudo mkdir old_libs 
        sudo mv libstdc++.so.6* old_libs 
        sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 libstdc++.so.6 
        # (Adjust paths as needed)

Option B: Recompile the relevant mex

Delete mtext-6.1.0/mex/jcvoronoi_mex.mexa64, get a mex builder if you don't already have one via
sudo apt install build-essential
and run mex_install from matlab.

Option C: Add the system library to matlab

Add the following line to your .bashrc profile:

        export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 
        # (Adjust path as needed)

I'll also add, as a Linux user, the mex changes in 6.1.0 have been a huge time saver and the above has been the only real problem I've seen so far. Thank you for the hard work, it makes my life considerably easier.

[argerlt]

Also, if someone on the MTEX team disagrees with my hotfix here, let me know and I can change it or delete it entirely.

[kilir]

Hi thanks a lot for documenting!
This is all correct.
Another option is to convince matlab to use the system library is:

LD_PRELOAD=/lib64/libstdc++.so.6 /usr/local/MATLAB/R2024b/bin/matlab -desktop

Path will obviously vary.
Cheers,
Rüdiger

[vtvivian]

Update as I found the same problem (MATLAB 2025b)

N.B. These are all commands to run in the Linux terminal, not the MATLAB command window.

Neither Option A nor Option B from argerlt worked for me:

• Option A: mkdir, mv and ln all needed a sudo prefix. I was able to replace MATLAB's libstdc++.so.6 file with a soft link to my own library, but mex files after that still failed.
• Option B: Running mex_install appeared to recompile successfully, but check_mex after that still found the same bad mex files

Rüdiger's solution worked for me with modifications:

• His version only works for a single MATLAB instance, and I didn't want to have to type into the terminal every time to open matlab.
• using the export command makes the change permanent

export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 
matlab

Vivian

[kilir]

In case you don't want to type/remember the whole thing, you could set it as an alias in your .bashrc (or comparable place):

alias mtlab='LD_PRELOAD=/lib64/libstdc++.so.6 /usr/local/MATLAB/R2025b/bin/matlab -desktop'

and then be able to start from the shell with mtlab (or whatever name you assign) or if you like to click on things, just create a .desktop file (https://specifications.freedesktop.org/desktop-entry/latest/) with the relevant entries. e.g.

[Desktop Entry]
Categories=Development;Math;Science
Comment=Scientific computing environment
Exec=env LD_PRELOAD=/lib64/libstdc++.so.6 /usr/local/MATLAB/R2025b/bin/matlab -desktop
Icon=/path/to/matlab/icon
MimeType=text/x-matlab
Name=MATLAB
NoDisplay=false
PrefersNonDefaultGPU=false
Terminal=false
Type=Application

Place it where you desktop environment expects it.

[ralfHielscher]

Thank you for writing this up — the paper trail is what made the cause obvious, and it turned out to be ours, not the users'.

Fixed at the source on develop in b6ff406 (merged as ac7c0bd).

What was wrong. A mex links against the libstdc++ of the compiler that built it, but loads against the one MATLAB ships — and MATLAB's is always the older of the two. The release workflow built the Linux binaries on ubuntu-latest, which is 24.04 with gcc 13/14, so jcvoronoi_mex came out requiring GLIBCXX_3.4.32:

$ objdump -p mex/jcvoronoi_mex.mexa64
  required from libstdc++.so.6:
    GLIBCXX_3.4.32

R2024b ships libstdc++.so.6.0.30, which tops out at GLIBCXX_3.4.30. So the binary could not load on a stock Linux MATLAB at all — your diagnosis was exactly right, and it was not something about your install.

The fix. The Linux job builds on ubuntu-22.04 now, and the workflow verifies the result rather than trusting the runner label: it runs objdump over the built binaries, takes the highest GLIBCXX_* they require, and fails the build above the ceiling. The ceiling is what the pinned MATLAB release ships, so this cannot silently come back when GitHub bumps the runner image.

On the three workarounds — none of them break, and this is worth stating explicitly since people will keep finding this thread. libstdc++ version nodes are additive: a library providing 3.4.34 provides 3.4.29 as well. Lowering what the binary asks for only widens the set of libraries that satisfy it, so Options A, B and C keep working; they simply stop being necessary. @vtvivian, that also explains why Option B did not help you — recompiling on a system with a newer gcc reproduces the same requirement.

One caveat before anyone tries this. The binaries currently committed in mex/ were built the old way and still need 3.4.32 — the new check fails against them today, which is the intended behaviour. They will be rebuilt through this workflow for the next release. Until then, keep the LD_PRELOAD line.

Closing, since the cause is fixed and the check will keep it fixed. Please reopen if a rebuilt binary still misbehaves on your system.