Make your own executable shared library on Linux

Hello there, it’s been a long time since my last post 🙂

Since I’m on vacation, and kinda frustrated about my playbook experience, I decided to  statisfy something that always tickled my fancy about shared libraries.

As you may know, under GNU/Linux is it possible to make shared libraries also executable: prominent examples are libc and Qt libraries, as shown in the screenshot below.

libc and libQtCore output

Those libraries, when executed from the command line, print useful information about the library version itself, the compiler used, processor features, author, copyright and so on .

But how they achieved that? Libraries don’t have an entry point .. or they do?

LD manual to the rescue

Of course the answer is yes, they do .. sort of. If you look at the options you can issue to ld, you will notice that there is the following option:

-e entry

--entry=entry  Use entry as the explicit symbol for beginning execution of your program, rather than the default entry point. […]

Bingo!

So what you will actually do is to define a function, from whithin your library, that will be used as entry point when executed. From there, you can execute your arbitrary piece of code.

The Code

We will start by defining a sample library composed of just one class (I kept everything as simple as possible to improve readabilty), which will do nothing but print “hello lib!”  upon construction:

/* lib/mysamplelib.h */
#ifndef SAMPLELIB_H
#define SAMPLELIB_H
namespace MySampleLib
{

class SampleLib
{

public:
    SampleLib();
};

} // namespace MySampleLib

#endif // SAMPLELIB_H

/* lib/mysamplelib.cpp */
#include "samplelib.h"
#include

namespace MySampleLib
{

SampleLib::SampleLib()
{
    std::cout << "hello lib!" << std::endl;
}

} // namespace MySampleLib

Then, we will define our custom entry point function in a separate file: this will print “Hello from custom entry point lib!”.

/* lib/dump_function.cpp */

#include
#include

extern "C" void my_dump_function() {
    printf("Hello from custom entry point lib!\n");
    exit(0);
}

We also need a very basic main.cpp file, which prints the usual “Hello World!” and then instantiate a SampleLib object:

/* main.cpp */

#include
#include "lib/samplelib.h"

int main()
{
    std::cout << "Hello World!" << std::endl;
    SampleLib lib = SampleLib();
    return 0;
}

For completeness, I will also include the two CMakeLists.txt files used in the project.

/* CMakeLists.txt */
project(executable_library)
cmake_minimum_required(VERSION 2.8)

add_subdirectory(lib)

set(SRC_LIST
    main.cpp
)

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

/* lib/CMakeLists.txt */
set(LIB_SRC
    samplelib.cpp
    dump_function.cpp
)

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -e my_dump_function")

add_library(SampleLib SHARED ${LIB_SRC})

And now we can finally build and run our app and our library and see the results 🙂

First Attempt

Urg .. What’s going on here?

Compilation and linkage were successful, the executable ran perfectly, but executing the library directly produced a segfault.

The Fix

Let’s try to find out what’s wrong here. We will run readelf to see the if there are some parts in common between the executable, our library, and some other executable library – i.e. libc – . These are the output:

readelf exec

readelf libc

And now, our libSampleLib

readelf samplelib

Nice, now we have much more infos about the issue. As you can see the executable, libc, and our SampleLib, all have  an entry point defined. That means that ld processed our command option as we intended.

But, as opposed to the executable and libc, our SampleLib does not have an interpreter section defined. This is normally good when a library gets executed through a regular application, because every application has an interpreter defined. In our case anyway, that missing definition is the reason of our segfault.

So we need to tell the compiler to add an interpreter header. From a quick search on google, all you need is to add the following line inside dump_funcion.c (outside the function body of course)

extern const char elf_interpreter[] __attribute__((section(".interp"))) = "/lib64/ld-linux-x86-64.so.2";

Recompile all, and now …

Second Attempt

Awesome, we did it!

But we are serious programmer, aren’t we? Hardcoding the interpreter absolute path is always a Bad Thing™; if you work in a team where everyone may potentially have different setup and machines, that’s even worse.

CMake to the rescue!

With a little help of CMake, we can automate the interpeter path retrival.

Firs we execute readelf on a command that is present in every linux distro, which is “ls” ; then, with a little cmake regexp magic, we extract the path, and finally add a new cmake definition whose value will be assigned to the elf_interpreter[] var inside dump_function.cpp .

The updated CMake file and main.cpp look now like this:

/* lib/CMakeLists.txt */
set(INTERPRETER_DESCRIPTION "Requesting program interpreter:")

execute_process(COMMAND readelf -l /bin/ls
    RESULT_VARIABLE return_value
    OUTPUT_VARIABLE result
)

if(return_value)
    message(STATUS "Cannot find a valid ELF interpreter")
else()
    string(REGEX REPLACE
        ".*[[]${INTERPRETER_DESCRIPTION} ([/][^ ].+)[]].*" "\\1"
        _ELF_INTERPRETER_PATH "${result}"
    )

    add_definitions( -DELF_INTERPRETER_PATH="${_ELF_INTERPRETER_PATH}" )
    message(STATUS "ELF interpreter is ${_ELF_INTERPRETER_PATH}")
endif()
set(LIB_SRC
   samplelib.cpp
   dump_function.cpp
)

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -e my_dump_function")
add_library(SampleLib SHARED ${LIB_SRC})

/* lib/dump_function.cpp */
/* showing only the relevant line here, too lazy to copy everythin again! */
extern const char elf_interpreter[] __attribute__((section(".interp"))) = ELF_INTERPRETER_PATH;

That’s better 🙂

Further improvements and how to get the code

You can find an improved version of the code shown here on my gitorious repository . I made some modifications to make it prettier and more reusable, such as define a FindELFInterpreter script for that purpose, added a simple macro to retrieve the hash commit/current branch of your source tree (in this case, mine), and embed that info within my_dump_function(). I’ve also added some debug compiler options, and added to the dump function, just to show some other interesting output you may be interested in seeing. Pretty neat, isn’t it? 🙂

Last Attempt

An other interesting thing to implement could be use cmake feature to create header files through its configure_file() command, and put all of those definitions inside it and include that file whenever you need it, but I leave this as an exercise to the reader, cheers 😉