How to Tell Mex to Link with the Libstdc++.So.6 in /Usr/Lib Instead of the One in the Matlab Directory

How to tell mex to link with the libstdc++.so.6 in /usr/lib instead of the one in the MATLAB directory?

You need to create a symbolic link to the gcc 4.7 library so matlab knows to use it. Something like:

ln -s {/path/to/file-name} {link-name}

If you don't want to use symbolic links, then just define this path in a terminal from which you launch matlab:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/libstdc++.so.6
./matlab

mysql and matlab mex - libmysqlcppconn not finding glibcxx_3.4.15

This can occur because Matlab includes its own copy of the library that differs from the one you used to compile it. You can replace the symbolic link to this library so that it points to the system library against with you compiled the mex file. On my machine this would look something like this:

sudo ln -sf /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16 /usr/local/MATLAB/R2012a/bin/glnxa64/libstdc++.so.6

See also: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found

/usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found

I'm compiling gcc 4.6 from source, and apparently

sudo make install 

didn't catch this one. I dug around and found

gcc/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.15

I copied it in to /usr/lib and redirected libstdc++.so.6 to point to the new one, and now everything works.

Version GLIBCXX_3.4.11 not found (required by buildW.mexglx)

Matlab (and a ton of other commercial programs like Steam, Mathematica, etc.) ships its own version of the libstdc++ so:

/usr/local/MATLAB/R2011a/bin/glnx86/../../sys/os/glnx86/libstdc++.so.6

The problem is that when you start matlab, it loads this one first, and since it is loaded, this version is used to resolve all dynamic loader dependencies.

You compiled with your system GCC and linked to your system's libstdc++, which is newer. The resulting binary then requests symbols of a certain (newer) version and the loader does not find them in the already loaded version (i.e. Matlab's).

There are two ways to solve this:

1a. Delete/rename Matlab's libstdc++ so and symlink your system's version to the exact same name:

    sudo rm /usr/local/MATLAB/R2011a/bin/glnx86/../../sys/os/glnx86/libstdc++.so.6
    sudo ln -s /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/local/MATLAB/R2011a/bin/glnx86/../../sys/os/glnx86/libstdc++.so.6

1b. Delete Matlab's version and let your OS's loader pick up the system's libstdc++:

    sudo rm /usr/local/MATLAB/R2011a/bin/glnx86/../../sys/os/glnx86/libstdc++.so.6

1c. Use the environment variable LD_PRELOAD to "inject" the system's version of libstdc++ into the execution environment before anything else, which prevents the old Matlab version to be loaded:

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

2. Install the GCC version Matlab expects and modify the Mex building options (or use update-alternatives) to use that instead of the system's GCC.

Note that for 1-3, you may need to mess with additional libraries like libgcc_s.so, in the same way.

The reason that using the new version works is because of the symbol versioning scheme employed in libstdc++ internally (hence also the detailed error message mentioning the version). A similar "fix" needs to be done for Steam on e.g. Arch Linux, where several system libraries Steam uses are linked to the newer libstdc++.

The real solution is for Matlab not to ship the libstdc++ so and instead use the OS provided version.

---

Related Topics