I know Linux Matlab only has official support for gcc 4.9 for mex.
Does anyone know how to get either the Linux Intel compilers (icc) working with mex on Linux or more recent versions of the gcc?
This is for recent versions of Matlab (2015-2017).
I assume you talk about C++ projects. Yes, its possible with newer versions of gcc.
Check supported compilers to find out which Matlab uses which gcc version.
Tell your newer version of gcc to use the ABI version of the gcc version that your Matlab was made in for the compilation of your project and all dependencies.
Tell Matlab to use the standard c++ library in /usr/lib and not the one it contains itself. It is backwards compatible.
Example with gcc > 4.9.x for Matlab 2017b:
Matlab 2017b was built with gcc 4.9.x
gcc 4.9.x is compatible with CXX ABI version 8
use your gcc with compile flag -fabi-version=8 for your mex file and all dependencies
in a shell export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libstdc++.so.6 before a call to matlab
I am trying to compile a library in linux with gcc. I want the lib to run on a different platform.
With configure, we normally use build and host. However, this library has no configure option. So I am writing my own code to compile lib using GCC. How I can specify the target machine as an option with GCC?
Unless the target is already possible with the current GCC (e.g. like the -m32 option of GCC on x86-64 Linux) you cannot compile your code with your usual GCC.
You have to either download and install a GCC cross-compiler or compile (as a cross-compiler using the --target= option for ./configure) GCC from its source code.
Every GCC installation has one single (main) target.
BTW, some Linux distributions are packaging some GCC cross-compilers. On Debian I have gcc-arm-none-eabi (targeted for ARM) and gcc-msp430 (targeted for MSP430)
I have a c++11 library ( https://github.com/matiu2/cdnalizer ). I want to distribute it on centos6 and ubuntu12.04 LTS.
It compiles happily on Ubuntu 13.10 and Gentoo.
I tried compiling with as much staticness as I could, but it still depends on a glibc that centos doesn't have:
matiu#matiu-laptop:~/projects/cdnalizer/build/src/apache$ readelf -d mod_cdnalizer.so | grep NEED
0x0000000000000001 (NEEDED) Shared library: [libapr-1.so.0]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000006ffffffe (VERNEED) 0xd520
0x000000006fffffff (VERNEEDNUM) 3
build line:
/usr/bin/g++ -fPIC -I/usr/local/include -I/usr/include -I/usr/include/x86_64-linux-gnu -I/usr/include/x86_64-linux-gnu/c++/4.8 -Wall -Wextra -g -shared -Wl,-soname,mod_cdnalizer.so -o mod_cdnalizer.so CMakeFiles/mod_cdnalizer.dir/mod_cdnalizer.cpp.o CMakeFiles/mod_cdnalizer.dir/config.cpp.o CMakeFiles/mod_cdnalizer.dir/filter.cpp.o ../libbase.a -lapr-1
I have tried compiling gcc-4.8.2 on centos, but the binaries it produces have similar glibc dependencies:
[root#matt src]# ./test_config
./test_config: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./test_config)
./test_config: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./test_config)
I heard that you can't escape glibc dependencies for shared libraries because c++ throws excoptions and so needs the shared libstdc++ (but my lib doesn't throw exceptions across the library boundary).
I also heard that you can't link in glibc statically because the static lib was not compiled with -fPIC.
My main question is:
How can I distribute my c++11 shared library on centos6 ?
My sub questions are:
Can I compile a c++11 shared library on ubuntu 13.10, and have it load on centos6 (and older ubuntus) ? how ?
Can I compile a c++11 shared library on centos6 and have it work on standard centos installs ?
(Don't worry about Apache2.2 vs 2.4 dependency .. that's the easy bit)
Can I compile a c++11 shared library on centos6 and have it work on standard centos installs ?
If you can't build your code with the standard CentOS 6 g++/glibc/libstdc++, then no, it's not going to run on standard CentOS 6 installs.
The CentOS distro is for long term support (LTS). Critical bugs get fixed with updates, but software otherwise doesn't change, usually. This is a feature. Even with 3rd party repositories (e.g. EPEL), the available software for CentOS isn't really recent.
Can I compile a c++11 shared library on ubuntu 13.10, and have it load on centos6 (and older ubuntus) ? how ?
If you can compile it using the g++ 4.4 toolchain, sure. In this case, you cannot use a more advanced compiler. A quick search on Ubuntu's 12.04 LTS package list shows libstdc++6-4.5-dbg using a version of libstdc++.so.6 which would be backward incompatible, based on error messages above.
How can I distribute my c++11 shared library on centos6 ?
As you've shown above, you'll have at least one updated dependency (libstdc++.so.6) that you'll need to ship with your library, and install in some odd location, with it's attendant headaches (LD_LIBRARY_PATH, what happens to any other C++ plugins, etc.). And update at some point.
Some enterprise users would object to something like this, mainly because it doesn't mesh well with the existing OS.
Statically linking in dependencies (like in Ali's answer with the Developer Toolset below) could work also. It's also not without problems (updates to dependencies again), but might be the best chance for your code to work on CentOS 6.
I see from comments to Ali's answer, that devtools 1 (gcc 4.7.0) didn't work, making it unlikely that devtools 1.1 would work. So it seems you do need C++11 support up to the level of gcc 4.8 in this case.
Your problem has nothing to do with GLIBC.
Your problem is that libstdc++.so.6 on the CentOS6 is too old.
According to distrowatch, CentOS 6.5 shipped with GCC 4.4.7. C++11 support was mostly complete in GCC 4.8, and in 4.4 had only incomplete support.
If you can build your library with GCC 4.4.7, then it should work (provided you build it on an old enough system). If you can't, then you'll have to update GCC on your target CentOS system.
Alternatively, you can distribute a newer version of libstdc++.so.6 (one from GCC 4.8), install it in non-default location, and ask your customers to link against that newer version (either via LD_LIBRARY_PATH, or better by supplying appropriate -Wl,-rpath=... option at link time).
In short:
Things are only backward compatible. You need to pick the oldest
release of the distro you want to support and build on
that. The later releases of that distro will most likely be backward
compatible so your shared library will do just fine on later releases.
You either need to build the compiler with C++11 support from source or install it from some repo of the distro. Prefer the latter if possible due to compatibility issues.
Any non-system library should be statically linked into your shared
library: -Wl,--static -lmylib1 -lmylib2 -Wl,--dynamic. The important here is that -Wl,--dynamic is at the end, after all statically linked stuff.
I haven't tried it myself but my colleague who does this routinely says:
Use CentOS 6.5 (the latest of the 6.x versions as of writing).
Install devtools / Developer Toolset. The compatibility issues are supposed to be resolved by special, patched version of the developer tools. Developer Toolset 2.1 Beta comes with gcc 4.8.
Link statically all third party libraries and libstdc++. However, do not
link glibc and other system libraries statically that are supposed to be on the target machine
anyway.
The programs that my colleague compiles this way work on my Ubuntu machine just fine. (He uses CentOS 5.10, which seems to be the oldest, still supported distro that has glibc 2.5.)
Hope this helps.
I want to use Red Hat Enterprise Linux 5.8 to compile folly, and gcc is 4.1.2. But folly needs gcc >=4.6. So I need to upgrade gcc to 4.6, maybe binutils etc. If new toolchain generates binary files such as *.a *.so, would running them on old Red Hat Enterprise Linux 5.8 bring any problem or unstabitily?
Probably no big trouble (because GCC 4.1 & soon released GCC 4.8 produces compatible code), at least for C code.
For C++ code I believe there is a incompatibility. Certainly the libstdc++ is tied to the compiler version. Sometimes it may be compatible in practice, sometimes not (but the C++ ABI slightly changed too). And this incompatibility may spread to every C++ library.
I believe you should try. If you recompile -with the same newest GCC- all the C++ dependencies, you'll probably be quite safe. So you could compile the newest GCC, then compile folly and all its dependencies with it.
BTW, I would suggest going to the latest GCC (today 4.7, in a few weeks 4.8).
I met an err when I installed JikesRVM, that is,
skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.4/libstdc++.so when searching for -lstdc++
So I am trying to install/update it to a later version. Now, the machine already has
gcc (SUSE Linux) 4.4.1 [gcc-4_4-branch revision 150839]
I am new to openSUSE, could you help?
Thanks!
You need to install 32 bit support for the GNU C/C++ compiler since JikesRVM on x86_64 currently supports only the 32 bit architecture.
To install this support in OpenSuSE 11.2 type
sudo zypper install gcc44-32bit gcc-32bit libstdc++44-devel-32bit
The first two provide runtime support for the C language and the 32-bit version of libgcc, the GCC low level runtime library. The third provides the 32-bit version of libstdc++, both the static import library and the dynamic library. It is the static libstdc++.a that was missing for JikesRVM.
To verify that the 32bit C++ build system is installed correctly you can test it with the following
echo "int main(){}" | g++ -x c++ -m32 -
Note Official support for OpenSuSE 11.2 has ended. Evergreen support will be available through 2013. Yet it is reasonable to update to 11.3 or a later version soon.