Output of 'make' is a shared object and not an executable

Question

Edit: It appears to be a g++ issue, as compiling with clang++ does output an executable file.

I've written a C++ application that has a main function, creates an application window, loads a 3D fbx file and draws that using opengl. To create the Makefile for compiling i'm using a CMakeLists.txt file:

cmake_minimum_required(VERSION 2.8)
project(solight)
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++14")
INCLUDE_DIRECTORIES(lib/include)

###########################################
#SET THIS TO X32 IN CASE OF A 32 BIT SYSTEM
###########################################
set (ARCH x64)

set (SRC_LIST
    src/assetmanager.cpp src/assetmanager.h
    src/mesh.cpp src/mesh.h
    src/model.cpp src/model.h
    src/modelloader.h
    src/main.cpp
    src/math.h
    src/fbxmodelloader.cpp src/fbxmodelloader.h
    src/rendermodule.h
    src/openglrendermodule.cpp src/openglrendermodule.h
    src/textureloader.h
    src/engine.cpp src/enginemodules.cpp src/engine.h
)


##########################
#EXTERNAL LIBRARY HANDLING
##########################

set (LINUX_DEPS
    libfbxsdk.a
    pthread
    libSDL2.a
    GL
    libGLEW.a
    dl
)

set (WIN32_DEPS
)

set (APPLE_DEPS
)

if (UNIX AND NOT APPLE)
    set (DEPS ${LINUX_DEPS})
    set (OS Linux)
endif()

if (APPLE)
    set (DEPS ${APPLE_DEPS})
    set (OS Apple)
endif()

if (WIN32)
    set (DEPS ${WIN32_DEPS})
    set (OS WIN32)
endif()


LINK_DIRECTORIES(${CMAKE_SOURCE_DIR}/lib/${OS}/${ARCH})

####################
#EXECUTBALE CREATION
####################

add_executable(${PROJECT_NAME} ${SRC_LIST})
target_link_libraries(${PROJECT_NAME} ${DEPS})

So after running the makefile that cmake created, the output is not an executable as expected, but a shared object file. If i run the file command on it this is the output:

solight: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=f20c07c8743a70bca20d4a0d9f50fcb108b8140e, not stripped

When executing

 /lib64/ld-linux-x86-64.so.2 ./solight --verify

the program executes as it should.

But when i execute the file through the terminal it runs just fine, creates the window and renders the model.

Any explantion as to why this is a shared object file? Thanks in advance.

Edit: When running

make VERBOSE=1

the output is:

    /usr/bin/cmake -H/home/wouter/Documents/Solight -B/home/wouter/Documents/Solight/build --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/wouter/Documents/Solight/build/CMakeFiles /home/wouter/Documents/Solight/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory '/home/wouter/Documents/Solight/build'
make -f CMakeFiles/solight.dir/build.make CMakeFiles/solight.dir/depend
make[2]: Entering directory '/home/wouter/Documents/Solight/build'
cd /home/wouter/Documents/Solight/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/wouter/Documents/Solight /home/wouter/Documents/Solight /home/wouter/Documents/Solight/build /home/wouter/Documents/Solight/build /home/wouter/Documents/Solight/build/CMakeFiles/solight.dir/DependInfo.cmake --color=
Dependee "/home/wouter/Documents/Solight/build/CMakeFiles/solight.dir/DependInfo.cmake" is newer than depender "/home/wouter/Documents/Solight/build/CMakeFiles/solight.dir/depend.internal".
Dependee "/home/wouter/Documents/Solight/build/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/home/wouter/Documents/Solight/build/CMakeFiles/solight.dir/depend.internal".
Scanning dependencies of target solight
make[2]: Leaving directory '/home/wouter/Documents/Solight/build'
make -f CMakeFiles/solight.dir/build.make CMakeFiles/solight.dir/build
make[2]: Entering directory '/home/wouter/Documents/Solight/build'
[ 11%] Building CXX object CMakeFiles/solight.dir/src/assetmanager.cpp.o
/usr/bin/c++    -I/home/wouter/Documents/Solight/lib/include  -std=c++14   -o CMakeFiles/solight.dir/src/assetmanager.cpp.o -c /home/wouter/Documents/Solight/src/assetmanager.cpp
[ 22%] Building CXX object CMakeFiles/solight.dir/src/mesh.cpp.o
/usr/bin/c++    -I/home/wouter/Documents/Solight/lib/include  -std=c++14   -o CMakeFiles/solight.dir/src/mesh.cpp.o -c /home/wouter/Documents/Solight/src/mesh.cpp
[ 33%] Building CXX object CMakeFiles/solight.dir/src/model.cpp.o
/usr/bin/c++    -I/home/wouter/Documents/Solight/lib/include  -std=c++14   -o CMakeFiles/solight.dir/src/model.cpp.o -c /home/wouter/Documents/Solight/src/model.cpp
[ 44%] Building CXX object CMakeFiles/solight.dir/src/main.cpp.o
/usr/bin/c++    -I/home/wouter/Documents/Solight/lib/include  -std=c++14   -o CMakeFiles/solight.dir/src/main.cpp.o -c /home/wouter/Documents/Solight/src/main.cpp
[ 55%] Building CXX object CMakeFiles/solight.dir/src/fbxmodelloader.cpp.o
/usr/bin/c++    -I/home/wouter/Documents/Solight/lib/include  -std=c++14   -o CMakeFiles/solight.dir/src/fbxmodelloader.cpp.o -c /home/wouter/Documents/Solight/src/fbxmodelloader.cpp
[ 66%] Building CXX object CMakeFiles/solight.dir/src/openglrendermodule.cpp.o
/usr/bin/c++    -I/home/wouter/Documents/Solight/lib/include  -std=c++14   -o CMakeFiles/solight.dir/src/openglrendermodule.cpp.o -c /home/wouter/Documents/Solight/src/openglrendermodule.cpp
[ 77%] Building CXX object CMakeFiles/solight.dir/src/engine.cpp.o
/usr/bin/c++    -I/home/wouter/Documents/Solight/lib/include  -std=c++14   -o CMakeFiles/solight.dir/src/engine.cpp.o -c /home/wouter/Documents/Solight/src/engine.cpp
[ 88%] Building CXX object CMakeFiles/solight.dir/src/enginemodules.cpp.o
/usr/bin/c++    -I/home/wouter/Documents/Solight/lib/include  -std=c++14   -o CMakeFiles/solight.dir/src/enginemodules.cpp.o -c /home/wouter/Documents/Solight/src/enginemodules.cpp
[100%] Linking CXX executable solight
/usr/bin/cmake -E cmake_link_script CMakeFiles/solight.dir/link.txt --verbose=1
/usr/bin/c++    -std=c++14   CMakeFiles/solight.dir/src/assetmanager.cpp.o CMakeFiles/solight.dir/src/mesh.cpp.o CMakeFiles/solight.dir/src/model.cpp.o CMakeFiles/solight.dir/src/main.cpp.o CMakeFiles/solight.dir/src/fbxmodelloader.cpp.o CMakeFiles/solight.dir/src/openglrendermodule.cpp.o CMakeFiles/solight.dir/src/engine.cpp.o CMakeFiles/solight.dir/src/enginemodules.cpp.o  -o solight  -L/home/wouter/Documents/Solight/lib/Linux/x64 -rdynamic -Wl,-Bstatic -lfbxsdk -Wl,-Bdynamic -lpthread -Wl,-Bstatic -lSDL2 -Wl,-Bdynamic -lGL -Wl,-Bstatic -lGLEW -Wl,-Bdynamic -ldl -Wl,-rpath,/home/wouter/Documents/Solight/lib/Linux/x64 
/home/wouter/Documents/Solight/lib/Linux/x64/libfbxsdk.a(fbxutils.o): In function `fbxsdk_2015_1::FbxPathUtils::GenerateFileName(char const*, char const*)':
(.text+0x4c8): warning: the use of `tempnam' is dangerous, better use `mkstemp'
make[2]: Leaving directory '/home/wouter/Documents/Solight/build'
[100%] Built target solight
make[1]: Leaving directory '/home/wouter/Documents/Solight/build'
/usr/bin/cmake -E cmake_progress_start /home/wouter/Documents/Solight/build/CMakeFiles 0

yugr · Accepted Answer · 2016-12-24T14:29:55.943

3

This may happen when application is compiled with special CFLAGS e.g. -pie -fPIE:

$ echo 'int main() { return 0; }' | gcc -x c - -fPIE -pie
$ file a.out
a.out: ELF 64-bit LSB  shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24,

Perhaps you could run your make with VERBOSE=1 and see if that's the case? In general file may use heuristics to identify filetype so you shouldn't rely on it too heavily.

As for your error with ld.so, you are using the wrong, 32-bit, dynamic linker to run 64-bit app. Use /lib64/ld-linux-x86-64.so.2 instead (as file told you).

EDIT: Another option is that your GCC is built with --enable-default-pie which seems to be the case for modern Ubuntu. You can disable this feature by cmaking with CFLAGS=-no-pie (or -nopie, depending on GCC version) but I'd rather not do that - PIE'ed executables make your system safer by allowing ASLR to do better job.

edited Dec 24 '16 at 14:29

answered Dec 23 '16 at 15:26

yugr

19,769
3
51
96

If this is the reason (still have to test it), is there any reason why cmake would generate the makefile like that? – Wouter Standaert Dec 23 '16 at 15:35
I'd wait for results of verbose output but I'd rather expect that your system compiler is "hardened" in some way (maybe via [--enable-default-pie](https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=223796)?). – yugr Dec 23 '16 at 15:44
I've added the output to the question, and i have never used that option, or set is as default? How would i check this? – Wouter Standaert Dec 23 '16 at 15:55
I have edited my question: clang++ seems to output an executable just how i want it... – Wouter Standaert Dec 23 '16 at 16:03
Hm, `-rdynamic` is suspicious but this does not cause issues when I try to repro locally. Could you post output of `gcc -v`? – yugr Dec 23 '16 at 16:27
@WouterStandaert FYI it seems that `--enable-default-pie` is indeed [enabled by default on Ubuntu](https://wiki.ubuntu.com/SecurityTeam/PIE) nowadays. – yugr Dec 24 '16 at 09:43
@WouterStandaert Perhaps rename the question to mention GCC, rather CMake? – yugr Dec 24 '16 at 09:57
Alright i've edited the title. Anybody any idea how to turn this option off? why would they do this...? – Wouter Standaert Dec 24 '16 at 13:41
You can try cmaking with CFLAGS=-no-pie (or -nopie, depending on your compiler). Note that I'd rather file a bug against `file` (it fails to properly discriminate between libs and apps in major distro). – yugr Dec 24 '16 at 14:28
As for "why" - PIEing an executable allows ASLR to make your system more safe (one of many "hardening" features of modern distros, others being default source fortification and stack protection). – yugr Dec 24 '16 at 14:28
Thanks you guys a lot for your explanation and help! – Wouter Standaert Dec 25 '16 at 15:00

score 0 · Answer 2 · edited Aug 12 '19 at 09:10

0

I found the root cause is the -shared flag in CMAKE_EXE_LINKER_FLAGS. when I delete -shared, everything is ok.

edited Aug 12 '19 at 09:10

gehbiszumeis

3,525
4
24
41

answered Aug 12 '19 at 08:20

slone xin

1
2

Output of 'make' is a shared object and not an executable

2 Answers2

Linked

Related