Compile and Run Problems - OSX 10.10 about medusa HOT 11 CLOSED

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! :)

from medusa.

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.

from medusa.

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.

from medusa.

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?

from medusa.

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?

from medusa.

@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?

from medusa.

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()

from medusa.

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.

from medusa.

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. :)

from medusa.

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. :)

from medusa.

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

Thanks.

from medusa.