Unable to use libc++ with clang++-5.0 - c++

I've installed clang++-5.0 to try out new C++17 features, but to get the full experience I need a new library. After being unable to find newer libstdc++, I decided to try out libc++.
I've checked it out using similar way described here.
After checkout, I've compiled it with clang itself, since it was advised to use clang. Compilation went without problems. Then I installed it, make put them in the /usr/local/include/c++/v1 directory.
When I tried to compile anything, I was getting an error saying the compiler couldn't find <stddef.h>. I solved the problem with "redirecting" the includes: -isystem /usr/local/include/c++/v1.
But then linker throws a lot of errors related to exceptions and virtual tables. I have no idea what to do in this case.
Is it possible to fix it?
My setup: ubuntu 16.04 LTS with all updates, clang++-5.0, cmake-3.6 .
Here are my flags:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -v -stdlib=libc++ -Wall -Wextra -pedantic-errors -std=c++1z -isystem /usr/local/include/c++/v1")
Excerpt from error messages:
//usr/local/lib/libc++.so: undefined reference to `__cxa_end_catch'
//usr/local/lib/libc++.so: undefined reference to `__cxa_pure_virtual'
//usr/local/lib/libc++.so: undefined reference to `__cxa_rethrow'
//usr/local/lib/libc++.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
//usr/local/lib/libc++.so: undefined reference to `vtable for __cxxabiv1::__class_type_info'
//usr/local/lib/libc++.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info'
UPDATE:
After building libc++abi it successfully passes build step, though now it crashes with error saying
error while loading shared libraries: libc++abi.so.1: cannot open shared object file: No such file or directory
Current flags:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -isystem /usr/local/include/c++/v1 -stdlib=libc++ -lc++abi -Wall -Wextra -pedantic-errors -std=c++1z")
After having a look, I found that they are absent in /usr/lib/, but are present in /usr/local/lib.
Here is the output of ldd program:
linux-vdso.so.1 => (0x00007ffd1b7da000)
libc++abi.so.1 => /usr/local/lib/libc++abi.so.1 (0x00007f69bd322000)
libc++.so.1 => /usr/local/lib/libc++.so.1 (0x00007f69bcf80000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f69bcc76000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f69bca60000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f69bc697000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f69bc479000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f69bc271000)
/lib64/ld-linux-x86-64.so.2 (0x000055e63a9a9000)

So what lead to problem was actually me leaving the part with libc++abi. Most of the procedure is as specified in the docs, with minor deviation.
The procedure for me was roughly as following:
Checkout llvm
Checkout libc++ and libc++abi. Remember to checkout both!
Configure. I'm not sure if it matters, but I builded it with release configuration, e.g. specified -DCMAKE_BUILD_TYPE=Release. Also, make sure that it will be compiled with clang itself.
Install both. They will probably be somewhere around /usr/local/lib/ folder.
Let compiler know that you want libc++. The flags are -stdlib=libc++ -lc++abi. If it will complain about missing <stddef.h>, add -isystem path/to/includes/ to the compiler flags, which in my case was -isystem /usr/local/include/c++/v1.

Related

Old GCC can not automatically find the new version libstdc++?

I'm trying to use the 3rd-party lib, called DocToText, with gcc 4.4.7.
I compiled the program with:
g++ -I./doctotext/ -L./doctotext/ -Wl,-rpath=./doctotext -ldoctotext -o example test_doctotext.cpp
In the beginning, it returned libstdc++.so.6: version GLIBCXX_3.4.15 not found
I manually downloaded the newer version, and re-linked, here is the result
[root#mail]~xian# find / -name "libstdc++.so.6"
/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6
[root#mail]~xian# strings /lib64/libstdc++.so.6 | grep GLIBCXX_3.4.15
GLIBCXX_3.4.15
[root#mail]~xian# strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX_3.4.15
GLIBCXX_3.4.15
But when I compiled again, it returned:
[root#mail]~xian# g++ -I./doctotext/ -L./doctotext/ -Wl,-rpath=./doctotext -ldoctotext -o example test_doctotext.cpp
./doctotext//libdoctotext.so: undefined reference to `std::__detail::_List_node_base::swap(std::__detail::_List_node_base&, std::__detail::_List_node_base&)#GLIBCXX_3.4.15'
./doctotext//libdoctotext.so: undefined reference to `std::__detail::_List_node_base::_M_transfer(std::__detail::_List_node_base*, std::__detail::_List_node_base*)#GLIBCXX_3.4.15'
./doctotext//libdoctotext.so: undefined reference to `std::__detail::_List_node_base::_M_unhook()#GLIBCXX_3.4.15'
./doctotext//libdoctotext.so: undefined reference to `std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)#GLIBCXX_3.4.15'
collect2: ld returned 1 exit status
I also tried
g++ -I./doctotext/ -L./doctotext/ -L/lib64/ -Wl,-rpath=./doctotext,-rpath=/lib64 -ldoctotext -lstdc++ -o example test_doctotext.cpp
, and I got the same errors (undefined reference).
libdoctotext.so indeed link to /lib64/libstdc++.so.6
[root#mail]~xian# ldd doctotext/libdoctotext.so | grep libstdc++.so.6
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f96c7ab4000)
Fortunately, I found two method to solve this problem:
use newer gcc:
I used gcc 9.1.1 (with scl), then g++ -I./doctotext/ -L./doctotext/ -Wl,-rpath=./doctotext -ldoctotext -o example test_doctotext.cpp directly works.
specify the path to libstdc++.so.6 with gcc 4.4.7:
g++ -I./doctotext/ -L./doctotext/ -Wl,-rpath=./doctotext -ldoctotext /lib64/libstdc++.so.6 -o example test_doctotext.cpp
But I'm really curious about why my gcc 4.4.7 can not link to that libstdc++ under the system default path?
Is the version of libstdc++ be tightly coupled to the version of gcc in someway?
===============================================================================
Eventually, I found gcc would use
[root#mail]/usr/lib64# find / -name "libstdc++.so"
/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/32/libstdc++.so
/opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/libstdc++.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/32/libstdc++.so
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libstdc++.so
[root#mail]/usr/lib64# ll /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libstdc++.so
lrwxrwxrwx. 1 root root 37 Aug 21 15:22 /usr/lib/gcc/x86_64-redhat-linux/4.4.4/libstdc++.so -> ../../../../lib64/libstdc++.so.6.0.13
6.0.13 doesn't have GLIBCXX_3.4.15
I re-link this to libstdc++.so.6.0.17, problem solved
Every GCC release is accompanied by its very own libstdc++ release.
The C++ standard library (and support libraries like libsupc++) often rely on specific implementation details in the compiler, including bugs, and specific changes in behaviour due to defect reports etc.
Sometimes even a new GCC release also needs a matching binutils (linker) release, as the way the code is generated changed to use a specific feature only available in the newer linker.
You can explicitly link it to the system libstdc++ by passing that path to the compiler/linker, but I don't recommend it, as the ABI may have changed in an incompatible way.

C++ / G++ Maxmind geolite2++ third party shared object undefined reference

I posted this question yesterday which was marked as a duplicate, after reading the original I was able to get my compile to go a bit further. (Will delete the linked question once I've got this resolved or given up).
Now I have two g++ commands compiling to a .o file but remain with the undefined reference errors regarding a third party .so that I obtained from this library (geolite2++).
Here are my compile commands:
sudo g++ -std=c++11 -I/home/ubuntu -L/home/ubuntu -g -lstdc++ -lgeolite2++ -c -O2 -MMD -MP -MF "main.o.d" -o main.o main.cpp
(appears to work)
sudo g++ -std=c++11 -L/home/ubuntu -I/home/ubuntu -pthread -g -o main main.o -lstdc++ -lgeolite2++ -lz -ldl
(generates the following errors)
/home/ubuntu/libgeolite2++.so: undefined reference to `MMDB_lookup_string'
/home/ubuntu/libgeolite2++.so: undefined reference to `MMDB_free_entry_data_list'
/home/ubuntu/libgeolite2++.so: undefined reference to `MMDB_open'
/home/ubuntu/libgeolite2++.so: undefined reference to `MMDB_strerror'
/home/ubuntu/libgeolite2++.so: undefined reference to `MMDB_lib_version'
/home/ubuntu/libgeolite2++.so: undefined reference to `MMDB_aget_value'
/home/ubuntu/libgeolite2++.so: undefined reference to `MMDB_get_entry_data_list'
/home/ubuntu/libgeolite2++.so: undefined reference to `MMDB_get_metadata_as_entry_data_list'
/home/ubuntu/libgeolite2++.so: undefined reference to `MMDB_close'
collect2: error: ld returned 1 exit status
I've done more research and read here (answer by Dmitry Yudakov) that I can use the ldd command to see if the /home/ubuntu/libgeolite2++.so shared object has found it's dependencies. My output indicates this isn't the case:
ldd /home/ubuntu/libgeolite2++.so
linux-vdso.so.1 => (0x00007ffe7fae1000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb281442000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb28122c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb280e64000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb280b5e000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb2819d6000)
Here is my programs code:
#include <cstdlib>
#include <iostream>
#include <GeoLite2PP.hpp>
#include <GeoLite2PP_error_category.hpp>
#include <GeoLite2PP_version.hpp>
using namespace std;
using namespace GeoLite2PP;
int main(int argc,char* argv[]) {
GeoLite2PP::DB db( "./GeoIP2-City.mmdb" );
std::string json = db.lookup( "216.58.216.163" );
std::cout << json << std::endl;
}
As such my question is, is this a problem with the /home/ubuntu/libgeolite2++.soshared library that's my fault or is it a problem with the library? Is the answer to be found in the duplicate of my original question (link above) or is it something else? Apologies in advance if this question is very newbie, but I am a bit out of my depth. Thanks in advance for any help.
Regards,
James
Googling those undefined symbols, it seems libgeolite2++ has an undeclared (and undocumented) dependency on libmaxminddb.
Since it's undeclared, ldd is of no help; however, even it were declared, you'd still need to link that other dependency into your executable.
You can dive into installing and linking that dependency, and/or you can talk to the author of libgeolite2++.

Undefined reference to `sc_dt::sc_uint_base::to_string[abi:cxx11]

I have some code using the SystemC library which compiles fine when I'm physically at the machine, but throws undefined references when I'm ssh'ing in.
g++ -Wno-deprecated -O0 -g3 -I/path/to/include socex2.cpp -L/path/to/lib -lsystemc
/tmp/ccCNdiMA.o: In function `sc_dt::sc_uint_base::print(std::ostream&) const':
/path/to/include/sysc/datatypes/int/sc_uint_base.h:844: undefined reference to `sc_dt::sc_uint_base::to_string[abi:cxx11](sc_dt::sc_numrep, bool) const'
collect2: error: ld returned 1 exit status
At first I thought it was a problem with LD_LIBRARY_PATH, set in ~/.bashrc to /path/to/lib. I source ~/.bashrc in ~/.bash_profile for non-interactive sessions such as ssh.
To verify, here's the relevant bits of /usr/bin/env:
TERM=xterm
SHELL=/bin/bash
SSH_CLIENT=xx.xx.xx.xx 56176 22
LD_LIBRARY_PATH=/path/to/lib
SSH_CONNECTION=xx.xx.xx.xx 56176 yy.yy.yy.yy 22
_=/usr/bin/env
Why won't my program link? The headers and libraries I'm using are exactly the same and in the exact same places.
P.S.
I don't have admin access on these machines
gcc is 5.4.0
OS is Ubuntu 16.04
Dependent libraries:
$ ldd /path/to/lib/libsystemc.so
linux-vdso.so.1 => (0x00007ffe29d36000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb9b85f5000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb9b8273000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb9b7f69000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb9b7ba0000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb9b798a000)
/lib64/ld-linux-x86-64.so.2 (0x000056093a23e000)
...to_string[abi:cxx11] ...
One of two things...
First, GCC and Clang are being mixed and matched. If you were compiling with Clang, this would be a likely suspect because of GCC5 and the C++11 ABI and LLVM Issue 23529: Add support for gcc's attribute abi_tag (needed for compatibility with gcc 5's libstdc++).
Second, to_string is C++11, so you need either -std=c++11 or -std=gnu++11. C++11 is the likely candidate if all other things are equal. It also gets you the new ABI unless you -D_GLIBCXX_USE_CXX11_ABI=0.
You could still have problems with dependent library configurations, and they could be surfacing in your question.

undefined references in libpthread and libc

I'm having trouble compiling some examples in a odbc sdk. After some time mingling with the library order, I somehow managed to get the number of undefined references to just a handful of them.
Sadly, I can't figure out how to get rid of the remaining ones. Here's the command that's failing:
g++ -Wall -z defs -m64 -DSIMBA -D_REENTRANT -fPIC -O0 -g -shared Common/TabbedUnicodeFileReader_Linux_x8664_debug.cpp.o Core/QSConnection_Linux_x8664_debug.cpp.o Core/QSDriver_Linux_x8664_debug.cpp.o Core/QSEnvironment_Linux_x8664_debug.cpp.o Core/QSStatement_Linux_x8664_debug.cpp.o DataEngine/QSDataEngine_Linux_x8664_debug.cpp.o DataEngine/QSMetadataHelper_Linux_x8664_debug.cpp.o DataEngine/QSTable_Linux_x8664_debug.cpp.o DataEngine/QSTableUtilities_Linux_x8664_debug.cpp.o DataEngine/QSTypeInfoMetadataSource_Linux_x8664_debug.cpp.o Common/QSTableMetadataFile_Unix_Linux_x8664_debug.cpp.o Common/QSUtilities_Unix_Linux_x8664_debug.cpp.o Main_Unix_Linux_x8664_debug.cpp.o -Wl,--no-undefined -Wl,--no-allow-shlib-undefined -Wl,--whole-archive,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libSimbaDSI_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libSimbaSupport_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libAEProcessor_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libCore_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libDSIExt_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libExecutor_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libParser_debug.a,/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//Lib/Linux_x8664/libSimbaODBC_debug.a -Wl,--no-whole-archive -Wl,--soname=../Bin/Linux_x8664/libQuickstart_debug.so -L/home/hector/Downloads/SimbaEngineSDK/9.0/DataAccessComponents//ThirdParty/icu/Linux_x8664/lib -licuuc_simba64 -licudata_simba64 -licui18n_simba64 -lpthread -lm -lc -ldl -Wl,--version-script=exports_Linux.map -o ../Bin/Linux_x8664/libQuickstart_debug.so
Edit: Missing symbols
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libdl.so: undefined reference to `_dl_rtld_di_serinfo#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_allocate_tls_init#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `__libc_stack_end#GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_get_tls_static_info#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `__tls_get_addr#GLIBC_2.3'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_deallocate_tls#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_rtld_global#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `_dl_argv#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libc.so.6: undefined reference to `__libc_enable_secure#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_allocate_tls#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_rtld_global_ro#GLIBC_PRIVATE'
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `_dl_make_stack_executable#GLIBC_PRIVATE'
Fixed:
Removing -Wl,--no-allow-shlib-undefined seemed to do the trick. The built shared library seems to work perfectly.
I had a similar issue with a completely separate application. The following compile time flag worked for me:
-B/usr/lib/gold-ld/
which i found at:
https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/885927
I'm using gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1 I was trying to compile with lto.
You do a very common newbie mistake. you place the libraries to link with in the middle or the beginning of the command line. The linker GCC uses needs dependencies in reverse order. That means if you have an source/object file S using a function in library L, the file A has to be before the library L on the command line.
In short, put the libraries (-lm -lc -ldl) last on the command line instead.
If linker fails to resolve all referenced symbols then this can be a result of wrong order of provided libraries. If you are not sure what is the correct order then put archives in "--start-group archives --end-group" which according to ld manual will force linker to search the specified archives repeatedly until no new undefined references are created. But pay attention to a performance cost.
The OP mentioned "Removing -Wl,--no-allow-shlib-undefined" helped.
In my case I had to add the opposite:
-Wl,--allow-shlib-undefined
(Everything was working fine with an older version of GCC)

How to call Matlab from C++ code?

I am trying to call Matlab functions from C++ code.
With Matlab it comes an example of such code at /extern/examples/eng_mat/engdemo.cpp, however I found no way to build that source code.
Here is the makefile I use:
CFLAGS = -Wall -O3
INCLUDES = -I/opt/Matlab-2009a/extern/include
LIBRARIES = -Wl,-R/opt/Matlab-2009a/bin/glnx86 -L/opt/Matlab-2009a/bin/glnx86 -lmx -lmat -leng
out : engdemo.cpp
g++ $(CFLAGS) $(INCLUDES) -static $^ $(LIBRARIES) -o out
clean :
rm -f out
(Here /opt/Matlab-2009a is my Matlab root.) I am getting a linker error like this:
/usr/bin/ld: cannot find -lmx
collect2: ld returned 1 exit status
make: *** [out] Error 1
And the question is: how can I make g++ to compile engdemo.cpp ?
Note, that the shared library exists:
$ locate libmx.so
/opt/Matlab-2009a/bin/glnx86/libmx.so
/opt/Matlab-2009a/bin/glnx86/libmx.so.csf
and
$ ldd /opt/Matlab-2009a/bin/glnx86/libmx.so
linux-gate.so.1 => (0x004b4000)
libut.so => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/libut.so (0x0078f000)
libmwfl.so => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/libmwfl.so (0x00110000)
libicudata.so.38 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/libicudata.so.38 (0xb7f82000)
libicuuc.so.38 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/libicuuc.so.38 (0x00bee000)
libicui18n.so.38 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/libicui18n.so.38 (0x001f7000)
libicuio.so.38 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/libicuio.so.38 (0x00e1c000)
libz.so.1 => /usr/lib/libz.so.1 (0x0098e000)
libstdc++.so.6 => /opt/Matlab-2009a/bin/glnx86/../../sys/os/glnx86/libstdc++.so.6 (0x00531000)
libm.so.6 => /lib/libm.so.6 (0x00194000)
libgcc_s.so.1 => /opt/Matlab-2009a/bin/glnx86/../../sys/os/glnx86/libgcc_s.so.1 (0x00eaa000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00900000)
libc.so.6 => /lib/libc.so.6 (0x00345000)
librt.so.1 => /lib/librt.so.1 (0x00964000)
libdl.so.2 => /lib/libdl.so.2 (0x0014e000)
libexpat.so.1 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/../../bin/glnx86/libexpat.so.1 (0x00152000)
libboost_thread-gcc42-mt-1_36.so.1.36.0 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/../../bin/glnx86/libboost_thread-gcc42-mt-1_36.so.1.36.0 (0x00fc2000)
libboost_signals-gcc42-mt-1_36.so.1.36.0 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/../../bin/glnx86/libboost_signals-gcc42-mt-1_36.so.1.36.0 (0x0017d000)
libboost_system-gcc42-mt-1_36.so.1.36.0 => /opt/Matlab-2009a/bin/glnx86/../../bin/glnx86/../../bin/glnx86/libboost_system-gcc42-mt-1_36.so.1.36.0 (0x00a06000)
/lib/ld-linux.so.2 (0x001db000)
So, how can I make g++ to compile engdemo.cpp ?
Assuming $MATLABROOT is the path to MATLAB:
$MATLABROOT/bin/mex -f $MATLABROOT/bin/engopts.sh engdemo.cpp
If you add the -v switch, the verbose output will show you what commands are being used to compile the engine application.
Why are you compiling with -static? From "man gcc":
-static
On systems that support dynamic linking, this prevents linking with the shared libraries. On other systems, this option has no effect.
In other words, the -static option forces the linker to only consider static libraries, meaning that it will try to find libmx.a rather than libmx.so. Since Matlab only ships with shared (dynamic) libraries, it fails.
Try removing that option & see what happens.
If that doesn't work, you may need to run libtool to help it find the .so's at runtime.
I thought I'd post something that related that might be of use to someone who stumbles upon this post in the future, on the theme of calling a Matlab function from C++.
In a tutorial posted on the Mathworks site the use of shared libraries is demonstrated for calling Matlab function(s) from a C++ file. Here, the mcc command is used to create a shared library.
Subsequently, the mbuild command is used to build the executable. However, if you have a complicated C++ code, which itself needs its own set of shared libraries for compilation, mbuild won't work. The tutorial doesn't demonstrate what needs to be done in this case. So, the purpose of my reply is to post that solution. The user C++ file is vigenere.cpp, and the shared library to be linked in this case is libvigenere.so, and this is the resultant call to g++:
g++ -o vigenere -L/usr/local/MATLAB/R2013b/runtime/glnxa64 -L. -I/usr/local/MATLAB/R2013b/extern/include/ vigenere.cpp -lmwmclmcrrt -lm -lvigenere
Some prerequisites:
The Matlab Compiler Runtime (MCR) needs to be installed. Either type mcrinstaller at the Matlab prompt, or download the appropriate installer from the Matlab site.
After doing this, make sure to set your LD_LIBRARY_PATH as per the instructions at the end of the installer.
The current working directory needs to be added to the LD_LIBRARY_PATH. In bash, I do this by export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PWD
Note that 1&2 are also described in a readme.txt file generated by the mcc command.