c++cross-compilingfirebreath

Cross compiling firebreath targeting windows


Since NPAPI uses compiled binaries virtually 100% it is desirable to be building plugins that contain code for all platforms simultaneously, so it makes sense for cross compilation to be a priority feature for the build system of an NPAPI framework. However when I try to cross compile firebreath targeting windows from mac os x I get:

$ bash firebreath/prepmake.sh Codebendercc/ build.win  -DCMAKE_TOOLCHAIN_FILE=$HOME/Toolchain-mingw32.cmake
Using projects in: /path/to/project/root/Codebendercc
Generating build files in: /path/to/project/root/build.win
NOTE: The build files in /path/to/project/root/build.win should *NEVER* be modified directly. Make changes in cmake and re-run this script.
/path/to/root/build.win /path/to/root
-- The C compiler identification is GNU 4.9.3
-- The CXX compiler identification is GNU 4.9.3
-- Check for working C compiler: /usr/local/mingw/bin/i686-w64-mingw32-gcc
-- Check for working C compiler: /usr/local/mingw/bin/i686-w64-mingw32-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/local/mingw/bin/i686-w64-mingw32-g++
-- Check for working CXX compiler: /usr/local/mingw/bin/i686-w64-mingw32-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
!! Could not find VS DIR!
-- Visual Studio dir: 
CMake Error at cmake/Win.cmake:126 (message):
  FireBreath on windows requires ATL/MFC libs to be installed.  Please
  download the Microsoft DDK and install the build environments in \WinDDK
Call Stack (most recent call first):
  cmake/common.cmake:31 (include)
  CMakeLists.txt:41 (include)


-- Configuring incomplete, errors occurred!
See also "/path/to/project/root/build.win/CMakeFiles/CMakeOutput.log".

The $HOME/Toolchain-mingw32.cmake file contains:

# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Windows)

# which compilers to use for C and C++
SET(CMAKE_C_COMPILER /usr/local/mingw/bin/i686-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER /usr/local/mingw/bin/i686-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER /usr/local/mingw/bin/i686-w64-mingw32-windres)
SET(CMAKE_AR /usr/local/mingw/bin/i686-w64-mingw32-ar CACHE FILEPATH "Archiver")

# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH  /usr/local/mingw)

# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Is there a way to circumvent that?


Solution

  • There is no way to cross-compile windows libs for the simple reason that the ActiveX code currently requires ATL, which will only build (to the best of my knowledge) with Visual Studio. I recommend having a build machine running windows and use Visual Studio (ideally Professional, but it's probably doable with Express) for your windows builds.

    The problem is likely solvable, but it would be an enormous amount of work -- so far nobody has taken the time to do that work.

    Cross-compilation would be nice, but it's certainly not a priority to the FireBreath team (I'm the main dev) because it's a simple matter to build on windows; personally, I use jenkins to run simultaneous build jobs on all platforms and collect the artifacts. Cost-wise this is far cheaper than what would be required to eliminate the ATL dependency.

    That said, I certainly wouldn't complain if someone else wanted to rewrite that part of the framework for me to remove the dependency =]

    As a side note, I've never added the capability to build just the NPAPI version on windows, which theoretically doesn't require ATL, because there are still several pieces such as the DllRegisterServer functionality which lean on ATL. Adding that capability would be easier, though, and would just require you to come up with a decent abstraction to replace all of that functionality and then conditionally exclude the activex portions of the file; not a simple task, but orders of magnitude easier than re-implementing the entire COM stack without ATL.