Posts Tagged ‘gcc’

Compiling OpenSubDiv on mac os x with gcc

Monday, March 16th, 2015

I had a bit of trouble compiling OpenSubDiv on Mac OS X Yosemite with gcc. I could at least manage to compile the cpu library with:

mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DNO_EXAMPLES=1 -DNO_GCD=1 -DNO_CUDA=1 ..
make osd_static_cpu

This creates lib/libosdCPU.a. It seems -DNO_GCD=1 is the most critical option as grand central dispatch uses apple’s “blocks” extension C which is only supported by clang.

Linker order error with matlab dynamic libraries and gcc on mac os x

Monday, November 3rd, 2014

I had a nasty time tracking down a runtime error in our libigl tutorials. It seems that the newest version of matlab comes with some dynamic libraries which do not agree with the stdc++ library of my gcc compiler. I had a link command that looked something like this:

/opt/local/bin/g++ -std=c++11
  /Applications/MATLAB_R2014b.app/bin/maci64/libmex.dylib \
  /Applications/MATLAB_R2014b.app/bin/maci64/libmx.dylib \
  ...

Here’s the debugger output of the error I got at runtime

* thread #1: tid = 0x153aa3, 0x00007fff86d08866 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff86d08866 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff8341f35c libsystem_pthread.dylib`pthread_kill + 92
    frame #2: 0x00007fff8571fb1a libsystem_c.dylib`abort + 125
    frame #3: 0x00007fff8b1c007f libsystem_malloc.dylib`free + 411
    frame #4: 0x00000001001d47a0 libmex.dylib`std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf() + 96
    frame #5: 0x0000000100451da2 libstdc++.6.dylib`std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::~basic_ostringstream() + 36

Seems like libmex and libmx were the culprits. I fixed this problem by telling the linker to find the stdc++ library before the matlab dynamic libraries:

/opt/local/bin/g++ -std=c++11
  -lstdc++ \
  /Applications/MATLAB_R2014b.app/bin/maci64/libmex.dylib \
  /Applications/MATLAB_R2014b.app/bin/maci64/libmx.dylib \
  ...

Using embree compiled with gcc from a program compiled with clang

Friday, September 12th, 2014

I compiled Embree using my standard compiler gcc 4.7 (I’m holding out on clang for openmp support), but for a specific project I need to use clang. When I try to link against libembree.a and libsys.a I get this sort of error:

  "std::string::find(char, unsigned long) const", referenced from:
      embree::AccelRegistry::create(std::string, embree::RTCGeometry*) in libembree.a(registry_accel.o)
      embree::BuilderRegistry::build(std::string, embree::TaskScheduler::Event*, embree::Accel*) in libembree.a(registry_builder.o)
      embree::IntersectorRegistry<embree::Intersector1>::get(std::string, std::string, embree::Accel*) in libembree.a(registry_intersector.o)
      embree::IntersectorRegistry<embree::Intersector4>::get(std::string, std::string, embree::Accel*) in libembree.a(registry_intersector.o)
  "std::string::compare(char const*) const", referenced from:
      embree::AccelRegistry::create(std::string, embree::RTCGeometry*) in libembree.a(registry_accel.o)
      embree::BuilderRegistry::build(std::string, embree::TaskScheduler::Event*, embree::Accel*) in libembree.a(registry_builder.o)
      embree::IntersectorRegistry<embree::Intersector1>::get(std::string, std::string, embree::Accel*) in libembree.a(registry_intersector.o)
      embree::IntersectorRegistry<embree::Intersector4>::get(std::string, std::string, embree::Accel*) in libembree.a(registry_intersector.o)
...

I tried using the flag -stdlib=libc++ but this doesn’t fix the problem. Using -stdlib=libstdc++ most errors go away except for:

  "std::ctype<char>::_M_widen_init() const", referenced from:
      embree::rtcBuildAccel(embree::RTCGeometry*, char const*) in libembree.a(embree.o)
      embree::BVHStatisticsT<embree::BVH2>::print() in libembree.a(bvh2.o)
      embree::BVHStatisticsT<embree::BVH4>::print() in libembree.a(bvh4.o)
      embree::BVHBuilderT<embree::BVH4, embree::HeuristicBinning<0> >::createLeafNode(unsigned long, embree::atomic_set<embree::PrimRefBlock>&, embree::HeuristicBinning<0>::PrimInfo const&) in libembree.a(bvh4.o)
      embree::BVHBuilderT<embree::BVH4, embree::HeuristicBinning<2> >::createLeafNode(unsigned long, embree::atomic_set<embree::PrimRefBlock>&, embree::HeuristicBinning<2>::PrimInfo const&) in libembree.a(bvh4.o)
      embree::BVHBuilderT<embree::BVH4, embree::HeuristicSpatial<0> >::createLeafNode(unsigned long, embree::atomic_set<embree::PrimRefBlock>&, embree::HeuristicSpatial<0>::PrimInfo const&) in libembree.a(bvh4.o)
      embree::BVHBuilderT<embree::BVH4, embree::HeuristicSpatial<2> >::createLeafNode(unsigned long, embree::atomic_set<embree::PrimRefBlock>&, embree::HeuristicSpatial<2>::PrimInfo const&) in libembree.a(bvh4.o)

This error seems trickier and to remove it I explicitly link against libgcc_s.a found in my gcc’s libraries: add the linker argument /opt/local/lib/gcc47/libstdc++.a. This gets me close, but there’s a new error:

  "___emutls_get_address", referenced from:
      ___cxa_get_globals_fast in libstdc++.a(eh_globals.o)
      ___cxa_get_globals in libstdc++.a(eh_globals.o)

Turns out that I need another library from gcc making the arguments now: /opt/local/lib/gcc47/libstdc++.a /opt/local/lib/gcc47/libgcc_s.1.dylib. And this finally works.

Update: Oddly it seems on the static libstdc++.a has the final problem. Linking to the dymnamic library libstdc++.dylib in the same directory works fine (maybe because I’m just avoiding the issue with this example).

Compiling C++ with C++11 support on bluehost servers

Monday, September 8th, 2014

I asked bluehost to install a modern version of gcc with C++11 support. They told me that only gcc4.3 was deemed stable.

So then I tried to compile gcc4.7 and gcc4.9 from scratch. This seemed promising but eventually I hit some apparent bug in the make routine of gcc giving me the error:

"cp: cannot stat `libgcc_s.so.1': No such file or directory"

Manually copying the file for make did not help.

So then I switched to trying to compile clang. This worked. I followed the instructions in this answer.

Namely, I added this to my .bashrc

export LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.4.7/:$LD_LIBRARY_PATH
export CC=/usr/bin/gcc
export CXX=/usr/bin/g++

Then issued the following:

source .bashrc
wget http://llvm.org/releases/3.3/cfe-3.3.src.tar.gz
tar xzf llvm-3.3.src.tar.gz && cd llvm-3.3.src/tools/ && tar xzf ../../cfe-3.3.src.tar.gz
cd llvm-3.3.src
mv tools/cfe-3.3.src tools/clang
./configure --prefix=$HOME/llvm-3.3.src/llvm
make -j8
make install

Now to test it out, I created a file test.cpp with this inside:

#include <iostream>
int main(int argc, char *argv[])
{
  const auto & hello = []()
  {
    std::cout<<"Hello, world."<<std::endl;
  };
  hello();
}

Then I could try to compile with:

llvm-3.3.src/llvm/bin/clang++ -std=c++11 test.cpp -o test

But I get the error:

In file included from test.cpp:1:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/iostream:40:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/ostream:40:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/ios:40:
In file included from /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/exception:148:
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/exception_ptr.h:143:13: error: unknown type name
      'type_info'
      const type_info*
            ^
1 error generated.

This seems to be a known bug with old “stable” versions of gcc’s standard library. The fix is to add a class declaration before the #include <iostream>:

#ifdef __clang__
    class type_info;
#endif
#include <iostream>
int main(int argc, char *argv[])
{
  const auto & hello = []()
  {
    std::cout<<"Hello, world."<<std::endl;
  };
  hello();
}

This compiles and runs.

gdb, lldb not showing line numbers for binaries compiled from stdin

Tuesday, June 17th, 2014

I recently figured out why my self-compiling C++ files didn’t play nicely with debuggers. It seems that when compiling with gcc (from Macports) and reading in the C++ code from standard input (using the -x c++ - arguments), the debuggers gdb and lldb won’t show high level information like code snippets or line numbers even if the -g option is present. Seems that gcc isn’t really including that information in the binary, rather it’s looking it up at run-time. You can verify this by changing the source file after compiling and then running the debugger. clang++ on the otherhand seems to embedd information from stdin into the executable so that it can be properly debugged.

In the meantime, I’ll keep using gcc but for self-compiling routines I need to use auxiliary files.

Fixing Pardiso libraries

Wednesday, May 28th, 2014

Here’s what I did to get pardiso’s dynamic libraries working on mac os x:

sudo mv ~/Downloads/libpardiso500-MACOS-X86-64.dylib /usr/local/lib
sudo ln -s /usr/local/lib/libpardiso500-MACOS-X86-64.dylib /usr/local/lib/libpardiso.dylib
sudo install_name_tool -id /usr/local/lib/libpardiso500-MACOS-X86-64.dylib /opt/local/lib/libpardiso500-MACOS-X86-64.dylib
sudo install_name_tool -change /usr/local/lib/libgfortran.3.dylib /opt/local/lib/libgcc/libgfortran.3.dylib /usr/local/lib/libpardiso500-MACOS-X86-64.dylib
sudo install_name_tool -change /usr/local/lib/libgomp.1.dylib /opt/local/lib/libgcc/libgomp.1.dylib /usr/local/lib/libpardiso500-MACOS-X86-64.dylib
sudo install_name_tool -change /usr/local/lib/libgcc_s.1.dylib /opt/local/lib/libgcc/libgcc_s.1.dylib /usr/local/lib/libpardiso500-MACOS-X86-64.dylib
sudo install_name_tool -change /usr/local/lib/libquadmath.0.dylib /opt/local/lib/libgcc/libquadmath.0.dylib /usr/local/lib/libpardiso500-MACOS-X86-64.dylib

I think there’s a fancier way to do this using @rpath, but these hardcoded paths got me rolling at least

No `gdb` in OS X 10.9, Mavericks

Monday, April 21st, 2014

Use lldb, even works with binaries compiled with gcc.

Matlab’s mex can’t find std headers

Friday, April 18th, 2014

Trying to compile the ecos mex files I ran into the following errors:

In file included from /opt/local/lib/gcc47/gcc/x86_64-apple-darwin13/4.7.3/include-fixed/syslimits.h:7:0,
                 from /opt/local/lib/gcc47/gcc/x86_64-apple-darwin13/4.7.3/include-fixed/limits.h:34,
                 from ../external/SuiteSparse_config/SuiteSparse_config.h:45,
                 from ../external/ldl/include/ldl.h:11,
                 from ../external/ldl/src/ldl.c:157:
/opt/local/lib/gcc47/gcc/x86_64-apple-darwin13/4.7.3/include-fixed/limits.h:169:61: error: no include path in which to search for limits.h
In file included from ../external/ldl/include/ldl.h:11:0,
                 from ../external/ldl/src/ldl.c:157:
../external/SuiteSparse_config/SuiteSparse_config.h:46:20: fatal error: stdlib.h: No such file or directory
compilation terminated.

    mex: compile of ' "../external/ldl/src/ldl.c"' failed.

Turns out this has nothing to do with ecos, rather I had upgraded my OS since installing matlab. I need to replace 10.7 with 10.9 in my /Applications/MATLAB_R2013b.app/bin/mexopts.sh file. Then everything compiled fine.

The offending flags were:

-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/ -mmacosx-version-min=10.7

And the correct versions were:

-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/ -mmacosx-version-min=10.9

Mysterious gcc compile error near Eigen `cast`

Saturday, December 14th, 2013

I run into this error often and it always takes me a bit to remember the problem. The line usually looks like:

MatrixXd B = A.cast<float>();

and the error gcc spits out is:

XXX.cpp:719:34: error: expected primary-expression before 'float'
XXX.cpp:719:34: error: expected ',' or ';' before 'float'

The problem happens when A is some templated Eigen object. The solution is to add the word template in front of cast:

MatrixXd B = A.template cast<float>();

Thanks for nothing gcc error messages.

ALUT error resulting from bad link order

Tuesday, December 3rd, 2013

Link order dependency is one of my least favorite issues when writing C/C++. I ran into it again with the alut and OpenAL sound libraries. Trying to compile the alut example playfile.c, linking to alut after OpenAL like this:

gcc -I/usr/local/include/ -o playfile playfile.c -framework OpenAL -lalut

results in the following error when running:

Error loading file: 'The operation was invalid in the current ALUT state'

The “correct” order is fist alut then OpenAL, like this:

gcc -I/usr/local/include/ -o playfile playfile.c -lalut -framework OpenAL

Then the resulting binary executes properly.