Invalid MEX file...cannot dynamically load executable OR -shared option in MEX causes "bad values" in compiling and linking

I am currently creating a MEX wrapper for a C++ program which utilizes a Makefile to compile and link.

I am running everything on Linux Ubuntu 10.04, with the g++-4.3 compiler.

My short-term goal is to have it compile and link all libraries and source code with the MEX options (found when performing mex -v) and then have it run, even if it did not input or output any values.

Currently, I stand at a point where including the "-shared" flag in the final linking command will result in the following error:

/usr/bin/ld: ./src/radsrc/src/radsrc.a(dbmanager.o): relocation R_X86_64_32S against `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_S_empty_rep_storage' can not be used when making a shared object; recompile with -fPIC
./src/radsrc/src/radsrc.a: could not read symbols: Bad value

If I exclude the "-shared" option, I successfully compile and link with the makefile, but on running the MEX, I get the following error in the Matlab Console:

??? Invalid MEX-file '/home/[PATH TO DIRECTORY]/xpassv3/xpass.mexa64': /home/[PATH TO DIRECTORY]/xpassv3/xpass.mexa64:
cannot dynamically load executable

Can anyone give me advice on how to continue? I suspect leaving out the -shared option results in problems with dynamically loading the executable, however I don't know how to resolve the "recompile with -fPIC" since I've already tried including -fPIC in the g++ options.

Any help resolving this would be greatly appreciated.

Answer 1

[Kaustubha Govind]

What library are you attempting to load dynamically? Is it radsrc.a? The .a extension suggests that this is an archive, not a shared library. You need to compile it as a .so (shared object) file to be able to load it dynamically. Shared object files need to be position independent, so you need to use the -fPIC option to compile a shared object. For example, if you have two files square.c and factorial.c, that you want to create a .so from:

To compile their respective position independent object files.

   $ gcc -c -fPIC square.c factorial.c

Then, to generate a shared library from the object files:

   $ gcc -shared -o libstuff.so square.o factorial.o

Once you have thus compiled radsrc.so, you should be able to load it dynamically from your MEX-file.

However, if you did not intend to use radsrc.a as a dynamic library, but as a static library, you should still be able to link it against the MEX-file using the -l option (AFAIK). Perhaps it will help if you provide the exact compiler/linker command you are using.

[Derek]

Exactly what you said. I simply missed the -fPIC flag in the compilation of dbmanager.o as well as a few other source files. The Makefile structure is a little confusing, which is how I overlooked it. Thanks!

Answer 2

[Derek]

I feel silly, but I went and found where dbmanager.o was created in the Makefile. I then found that contrary to what I stated earlier, I had missed placing the -fPIC flag in the compilation of a handful of files. Once I placed the -fPIC flag in that list of g++ options, the program successfully compiled.