mongorover icon indicating copy to clipboard operation
mongorover copied to clipboard

Compilation fails when building with CMake on a 64-bit Linux

Open neoxic opened this issue 7 years ago • 4 comments

Please consider the following output:

$ cmake /mnt/seny/Downloads/mongorover-master
-- The C compiler identification is GNU 6.1.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Lua: /usr/lib64/liblua5.1.so;/usr/lib64/libm.so (found version "5.1.5")
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'libmongoc-1.0'
--   Found libmongoc-1.0, version 1.4.0
/usr/lib64/liblua5.1.so/usr/lib64/libm.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/seny/build/mongorover

$ make
Scanning dependencies of target mongo_module
[ 11%] Building C object CMakeFiles/mongo_module.dir/c_wrapper/mongo-module.c.o
In file included from /usr/include/features.h:392:0,
                 from /usr/include/stdlib.h:24,
                 from /mnt/seny/Downloads/mongorover-master/c_wrapper/lua-bson.h:20,
                 from /mnt/seny/Downloads/mongorover-master/c_wrapper/mongo-module.h:19,
                 from /mnt/seny/Downloads/mongorover-master/c_wrapper/mongo-module.c:17:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
 # include <gnu/stubs-32.h>
                           ^
compilation terminated.

What's the purpose behind forcing a 32-bit build in CMakeLists.txt with -m32 flags?

neoxic avatar Sep 18 '16 22:09 neoxic

Please also note that the following directives in CMakeLists.txt complicate matters when one wants to build in a directory separate from the source which happens a lot when using CMake.

# creates library in the parent directory
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/../)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/../)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/../)

neoxic avatar Sep 18 '16 22:09 neoxic

Hey @neoxic,

Sorry for a late reply. We're only really supporting Lua 5.2 and 5.1 (as stated in README). Lua 5.3 was added as a request, but I'm afraid I'm not fully committed to supporting it yet. It looks like your stdout shows: Found Lua: /usr/lib64/liblua5.1.so. If you have Lua 5.1, as far as I'm concerned that can't be 64 bit. I'll be on the lookout for the Lua community to move towards 64 bit, but as far as I'm concerned 32 bit is here to stay. I'm forcing a 32-bit build in the CMake build system in attempts to move forward with #47, since Corona Labs uses 5.1. CMake is a secondary build system here. LuaRocks is the one we've decided to be the main and true build system.

christopherjwang avatar Oct 04 '16 07:10 christopherjwang

Changing the directory output for CMake is to emulate that of LuaRocks. I'm afraid it isn't ideal in your case, but when someone really wants to compile mongorover with some other stuff I'll be happy to address that. If you're trying to do just that, let's talk.

christopherjwang avatar Oct 04 '16 07:10 christopherjwang

Chris, I personally fail to see how you connect two unrelated issues together and "solve" them by enforcing a 32-bit build.

First, it seems that Corona (I'm not familiar with that thing) might be 32-bit itself and therefore it fails to load the module compiled in a 64-bit system by default. There's no problem to externally compile your module into a 32-bit library. Using CMake one can achieve that by running:

cmake -D CMAKE_C_FLAGS=-m32 /path/to/source

With luarocks, one can do the same by running a 32-bit chroot or building in a 32-bit system.

I don't see why this should be your problem how one tries to fit your library into their environment. I also fail to see why you should prevent everybody else to build your module into a 64-bit library. Lua 5.1 as well as all higher versions can be 64-bit without any restrictions.

Second, that's fine if you use CMake to emulate luarocks. My point was that it can be done without artificial complexities. For instance, in order to install the library, you can use:

install(TARGETS mongo_module DESTINATION lib/lua/5.1)

and then run on Linux:

cmake -D CMAKE_INSTALL_PREFIX=/usr /path/to/source
make install

to install it into Lua 5.1 (just as an example).

Please see my project (https://github.com/neoxic/lua-amf3) which is a Lua 5.1 library as an example.

neoxic avatar Oct 04 '16 09:10 neoxic