Compile and Run Problems - OSX 10.10

[s-fiebig]

Compiling medusa on OSX 10.10 Yosemite took me a bit more of my time than expected. Now, I face two more problems:

1. I get "core: there is not supported loader" for every file (e.g. hello_world-vs2012.pe.x86-64). The dylibs for the accordings systems are in the same bin folder as qmedusa and the correct folder is used for the modules (according to the logs) Without further logs (last resort debugging) I assume I can't use medusa. Maybe if I get enough time time to further check the source code myself...
2. The menu works only after changing the focus to another program and back. Probably a qt problem.

In the following a description how I compiled medusa:

Compiling Dev version

First, compiling the dev branch didn't work at all.

1. Calling cmake from build folder leads to "does not appear to contain CMakeLists.txt". I'm no expert in cmake, so I don't even know how this is supposed to work. Or is cmake supposed to search in parent folders?
2. Calling cmake from the root folder gives us errors for OGDF: " Source directory is polluted"
   Deleting the CMakeFiles Directory is meaningless, as it gets created again. Removing the causing part from CMakeLists
   "# Check for polluted source tree.
   if(EXISTS ${CMAKE_SOURCE_DIR}/CMakeCache.txt OR
   ...
   "
   leads to the next error. I didn't spend further time here. If somebody can help me out here, I will try out the dev version on OSX 10.10.

Compiling 4.3

Second, compiling the last pre-release version 4.3.
I used homebrew and clang (the default usr/bin/g++ is clang) with libc++ compiler flag. OGDF suggests using libstdc++ on OSX, but this means you need to get other libraries compiled with this setting as well. Missing to do so will lead to: "Undefined symbols for architecture x86_64" Linking to libraries with different runtimes would otherwise lead to crashes.

Homebrew

brew install cmake
brew install python
brew install doxygen
brew install boost --c++11
brew install boost-python --c++11
brew install qt5

OGDF

Download the current OGDF version from http://www.ogdf.net/doku.php/tech:download and extract it.

Patch gtest because this is the only code part that isn't compatible with libc++: #20 or https://gist.github.com/pgriess/7046324
You just need to make sure that tr1/tuple is not used. For the current version 2015.5 of OGDF you can change gtest.h as follows:

547,548c547,548
< # if (defined(__GNUC__) && !defined(__CUDACC__) && (GTEST_GCC_VER_ >= 40000)) \
<     || _MSC_VER >= 1600

---
> # if (defined(__GNUC__) && !defined(__CUDACC__) && !defined(_LIBCPP_VERSION) && (GTEST_GCC_VER_ >= 40000)) \
>      || _MSC_VER >= 1600

In makeMakefile.conf add c++11 support

compilerCommand = g++ -std=c++11

Now just:

make
make debug

Medusa

Download medusa 4.3 and compile it:
For "unknown" reasons cmake does not use the python libraries from homebrew. So with the current version of python and qt5 we get:

cmake  -DQT5_CMAKE_PATH:PATH=/usr/local/Cellar/qt5/5.5.0/lib/cmake -DOGDF_PATH:PATH=<Your OGDF path> -DCMAKE_BUILD_TYPE=Release -DPYTHON_INCLUDE_DIR:PATH=/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/Headers -DPYTHON_LIBRARY:PATH=/usr/local/Cellar/python/2.7.10_2/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib
make

I'm open for any ideas.

[wisk]

Hi s-fiebig!

Thank you for the effort you gave to build medusa on OS X.
Unfortunately, I don't own any device which can run OS X (maybe using a patched VM?). So I'm probably not the best person to help you with your issues (but I'll do my best).

Regarding the first issue: Please make sure all modules have the correct extension (should be .dylib on OS X), and they must be located in the current directory (i.e. "." is the default module directory).
I think it could help if you can share to log messages here. Otherwise you can try to run qMedusa on strace to check if it tries to load modules from the correct directory.

About the issue on qt, well I know OS X uses a specific graphic environment, where qt relies on X11. It's hard to tell for sure where the root cause comes from. But if you manage to find a workaround, I would gladly integrate it in the source code.
Maybe it's a known problem.

Now regarding the dev branch, if you cloned recursively the repository, by typing mkdir build && cd build && cmake .. it should be able to compile medusa (but neither qMedusa nor emul_llvm will be built).
Feel free to paste error messages.

Usually, it's easier to dedicate a specific folder to build source, so calling cmake from the root directory should be avoid. IIRC this behavior is enforced by OGDF which explicitly check for this case.

Concerning python, I have the same issue on Windows, cmake selects the 32-bit version of python which leads to build error. Like you did, I have to specify python path manually too.
I should probably document this problem.

Keep up the good work! :)

[kaniini]

On OS X, Qt uses Cocoa actually.

Most likely the problem is that cmake isn't looking in /usr/local/Cellar/... for python libraries. It can probably be patched somehow.

[s-fiebig]

Thanks for your answers! I greatly appreciate any help.

Regarding my first issue:
The dylibs are named and located accordingly. The full log is e.g.:

core: Medusa 0.4.3 (release) Jul 28 2015 - 13:59:39
opening "/Users/s_fiebig/Downloads/hello_world-vs2012.pe.x86-64"
core: Module directory: "/Users/s_fiebig/Github/medusa-0.4.3/bin/."
core: there is not supported loader

Regarding the compilation of the dev version:
I missed an important parameter so cmake didn't work. Nevertheless, I'm back to square one. The same problem with libstdc++ and libc++. The g++-5 compiler knows the ap_int type, clang with libc++ doesn't. The error for g++-5 (libstdc++) is the linking error. And for libc++ compiling stops with the first header file:

[  0%] Building CXX object src/core/CMakeFiles/Medusa.dir/address.cpp.o
In file included from /Users/s_fiebig/Github/medusa-dev/medusa/src/core/address.cpp:1:
In file included from /Users/s_fiebig/Github/medusa-dev/medusa/inc/medusa/address.hpp:6:
/Users/s_fiebig/Github/medusa-dev/medusa/inc/medusa/types.hpp:69:3: error: use
      of undeclared identifier 'ap_int'
  ap_int;
  ^
/Users/s_fiebig/Github/medusa-dev/medusa/inc/medusa/types.hpp:69:9: error: 
      expected a type
  ap_int;

  ...

  fatal error: too many errors emitted, stopping now [-ferror-limit=]
1 warning and 20 errors generated.
make[2]: *** [src/core/CMakeFiles/Medusa.dir/address.cpp.o] Error 1
make[1]: *** [src/core/CMakeFiles/Medusa.dir/all] Error 2
make: *** [all] Error 2

I don't know ap_int (arbitrary precision int?), so any hint is welcome how to replace this.

[wisk]

Hi s-fiebig,

• module issue:

Please, could you confirm me that you see these following lines (or something similar) on the log widget when you open an executable:

core: Medusa 0.4.4 (release) Aug  3 2015 - 22:36:30
Module directory: "C:\Users\wisk\Projects\medusa\build_vs2013_x64\bin\Release"
core: Module: ".\arch_arm.dll" is an architecture
core: Module: ".\arch_x86.dll" is an architecture
core: Module: ".\arch_z80.dll" is an architecture
core: Module: ".\bind_python.dll" is a binding
core: Module: ".\db_text.dll" is a database
core: Module: ".\emul_interpreter.dll" is an emulator
core: Module: ".\emul_llvm.dll" is an emulator
core: Module: ".\ldr_bs.dll" is a loader (unloaded)
core: Module: ".\ldr_elf.dll" is a loader (loaded)
core: Module: ".\ldr_gb.dll" is a loader (unloaded)
core: Module: ".\ldr_mach-o.dll" is a loader (unloaded)
core: Module: ".\ldr_pe.dll" is a loader (unloaded)
core: Module: ".\ldr_raw.dll" is a loader (loaded)
core: Module: ".\Medusa.dll" is unknown (ignored)
core: Module: ".\os_unix.dll" is an operating system
core: Module: ".\os_windows.dll" is an operating system
core: Module directory: "C:\Users\wisk\Projects\medusa\build_vs2013_x64\bin\Release"

• ap_int:

You're right, ap_int stands for arbitrary-precision integer, this feature is provided by boost.multiprecision.
AFAIK it was implemented in version 1.53 of boost, CMake script in Medusa looks for, at least, version 1.55. Could you confirm me you used a version >=1.55?

[s-fiebig]

I managed to compile the dev version of medusa and it works too :-).
The problem with ap_int, which is defined in types.hpp, was that the compiler (only clang with libc++) didn't like the original definition:

typedef boost::multiprecision::number<boost::multiprecision::cpp_int_backend<
  0, 0,
  boost::multiprecision::signed_magnitude,
  boost::multiprecision::unchecked>>
  ap_int;

Something like this works:

typedef boost::multiprecision::cpp_int_backend<0,0,boost::multiprecision::signed_magnitude,boost::multiprecision::unchecked> temp_ap_int;
typedef boost::multiprecision::number<temp_ap_int>  ap_int;

Nevertheless the compiler threw further errors. So thankfully I noticed that c++11 settings were missing (-DCMAKE_CXX_FLAGS:STRING='-std=c++11'). That solved "everything", for now.

I close this issue. Is there any interest to write the info from above and the c++11 setting into a wiki/paragraph of your readme.md?

[s-fiebig]

@wisk Are you interested that I write the infos about compiling on OSX 10.10 in a wiki page or in a paragraph for your readme?

[wisk]

Hi s-fiebig,

Sure! I'd gladly update the README.rst to add compile instruction for OSX. :)
Regarding your issue, this is weird that cmake didn't properly set -std=c++11 flag. Could you tell me if this test looks correct for you?

 97 # Found it in CMakeLists.txt from keepassx project
 98 if("${CMAKE_CXX_COMPILER}" MATCHES "clang(\\+\\+)?$" OR "${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
 99   set(CMAKE_COMPILER_IS_CLANGXX 1)
100 endif()
101
102 if (CMAKE_COMPILER_IS_GNUCXX OR CMAKE_COMPILER_IS_CLANGXX)
103   add_definitions("-std=c++11" "-fabi-version=6")
104 endif()

[s-fiebig]

It looks correct and works if changed a bit. The problem is that my CMAKE_CXX_COMPILER is /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++. (Seems to be the default, at least I didn't set it like this)
So to match this an additional check is needed.

[wisk]

That's interesting!
I didn't foresee this case, I'll look for something more generic. I guess now CMake includes a better way to activate C++11 feature.
Thanks for the information. :)

[wisk]

Sorry for the delay, I found a way to enable C++11 without any check on the compiler name (CMAKE_CXX_STANDARD), but it requires cmake 3.1 (see 33594b7)
Please, let me know if it fixes your issue. :)

[wisk]

I assume it's fixed now, feel free to re-open if not.

Thanks.