I try to build the example code provide by boost asio example:
http://www.boost.org/doc/libs/1_54_0/doc/html/boost_asio/example/cpp11/spawn/echo_server.cpp
I copy all the code and put it into a cpp file, compile it on linux with gcc4.7 and cmake, link with boost coroutine and boost context library, but the link is failed.
The output is list below:
Linking CXX executable ../../../output/bin/unit_test
cd /home/watson/ID_project/build/server_linux_makefile_gcc/abc/test/unit/abc_async && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/unit_test.dir/link.txt --verbose=1
/usr/bin/c++ -std=c++11 -O3 -DNDEBUG -pthread -lrt -ltcmalloc -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free CMakeFiles/unit_test.dir/TestFileChannel.cpp.o CMakeFiles/unit_test.dir/TestStreamBuffer.cpp.o CMakeFiles/unit_test.dir/TestTimer.cpp.o CMakeFiles/unit_test.dir/TestThreadPool.cpp.o CMakeFiles/unit_test.dir/TestScheduler.cpp.o CMakeFiles/unit_test.dir/PCH.cpp.o CMakeFiles/unit_test.dir/main.cpp.o CMakeFiles/unit_test.dir/TestUDPNetwork.cpp.o CMakeFiles/unit_test.dir/TestTCPNetwork.cpp.o -o ../../../output/bin/unit_test -rdynamic ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_unit_test_framework-gcc47-mt-1_54.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_context-gcc47-mt-1_54.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_coroutine-gcc47-mt-1_54.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_thread-gcc47-mt-1_54.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_filesystem-gcc47-mt-1_54.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libyaml-cpp.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libmongoc.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_system-gcc47-mt-1_54.a ../../../../../../install/thirdparty_linux_makefile_gcc/lib/libprotobuf.a
../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_coroutine-gcc47-mt-1_54.a(coroutine_context.o): In function `boost::coroutines::detail::coroutine_context::coroutine_context(void (*)(long), boost::coroutines::stack_context*)':
coroutine_context.cpp:(.text+0x103): undefined reference to `make_fcontext'
../../../../../../install/thirdparty_linux_makefile_gcc/lib/libboost_coroutine-gcc47-mt-1_54.a(coroutine_context.o): In function `boost::coroutines::detail::coroutine_context::jump(boost::coroutines::detail::coroutine_context&, long, bool)':
coroutine_context.cpp:(.text+0x1bc): undefined reference to `jump_fcontext'
collect2: error: ld returned 1 exit status
make[2]: *** [abc/output/bin/unit_test] Error 1
I print the symbol table from the .a file, and find the symbol jump_fcontext' andmake_fcontext' is existed:
nm libboost_context-gcc47-mt-1_54.a
make_x86_64_sysv_elf_gas.o:
U _GLOBAL_OFFSET_TABLE_
U _exit
000000000000002e t finish
0000000000000000 T make_fcontext
jump_x86_64_sysv_elf_gas.o:
0000000000000000 T jump_fcontext
Someone can give me any tips about it? I try google every place but without information.
Try swapping the linking order of boost_context and boost_coroutine.
The linker documentation states:
[...] the linker searches and processes libraries and object files in the order they are specified. Thus, ‘foo.o -lz bar.o’ searches library ‘z’ after file foo.o but before bar.o. If bar.o refers to functions in ‘z’, those functions may not be loaded.
In this case
Boost.Coroutine depends on Boost.Context. As such, boost_coroutine should appear before boost_context when linking. For more linker ordering details, consider reading this answer.
Just to add another possibility for this (specifically with the Boost Context library) - if building under MinGW on Windows, using an earlier version of MASM can produce static libraries that contain no linkable symbols due to the way the symbols are exported.
The solution is to rebuild Boost Context with MASM 8.
See the answer at https://stackoverflow.com/a/26874113/1678468 for more about this.
Related
Let's say we have a library libutils which implements two functions: function1 and function2. And let's say function2 uses library libanother (so libutils depends on libanother).
Now I want to build my application that uses function1 only:
g++ myapplication.cpp -o my application -lutils
Is it required to include libanother in linkage:
g++ myapplication.cpp -o my application -lutils -lanother
Is there any linker requirements concerning that? Does the answer depend on whether the libraries libutils and libanother are shared or static?
Some first principles
Three kinds of files can be input to the linkage of a program:
object files
static libraries
shared libraries
But only two of those kinds of files can actually be linked into the program:
object files and shared libraries.1
If you input any object file p.o to the linkage of a program the linker
links it into the program unconditionally.
If you input a static library libx.a to the your linkage, the linker extracts from libx.a each archive member
libx.a(q.o) that it needs to carry on the linkage and links it into
the program. An archive member libx.a(q.o) is needed if it defines at least one
symbol that has been referenced, but not yet defined, in some file (object file or
shared library) that has already been linked into the program.
If you input a shared library liby.so, the story forks:-
If the linker (ld) option --as-needed is in effect when liby.so is reached,
then liby.so will be linked into the program if it is needed in the same sense as an archive member libx.a(q.o).
If --as-needed is not in effect, then liby.so is linked unconditionally, like
an object file.
If you invoke the linker via one of your distro's GCC frontends (gcc, g++, gfortran...) in the usual
way, then you will always get the --as-needed behaviour for shared libraries by default, or always not get it, as long as your
GCC toolchain remains the same, because your distro's build of GCC will configure --as-needed
as a default linkage option, or not, according to that distro's appraisal of the pros and cons of doing so.
Debian-derived distros (Ubuntu et al.) have defaulted to --as-needed in recent years. Last time I looked,
Redhat-derived distros (Fedora et al.) did not.2
When any file file.{o|so} is linked into the program it introduces 0 or more unresolved references into the program. Those unresolved references are
references to symbols in file.{o|so} that are not defined in file.{o|so} or in any other file already linked into the program.
The linker must resolve all references by the time it has finished the linkage of the
program, or the linkage fails with unresolved reference errors. Files must be input and linked that provide definitions for
all of the symbols that are referenced in the files that are linked.
Down to your case
When you say:
my application ... uses function1 only
you mean that some file will be linked that references function1. It's simple
to assume this file is some object file that will be linked unconditionally,
say the one that defines main, e.g.
main.c
#include <stdio.h>
extern void function1(void);
void call_function1(void) {
function1();
}
int main(void)
{
puts("Hello World!");
}
which we compile to an object file:
$ gcc -Wall -c main.c
Notice that main.o references function1 despite the fact that we cannot
run a program with that main function in any way that will call
function1. main.o defines a function,
call_function1, that calls function1; so function1 is referenced in main.o.
call_function1 is not referenced itself, but function1 is. If we look at
the symbol table of main.o:
$ nm main.o
0000000000000000 T call_function1
U function1
U _GLOBAL_OFFSET_TABLE_
000000000000000c T main
U puts
the symbols annotated T are defined. The ones annotated U are referenced
but not defined. So when we try to link main.o into a program:
$ gcc -o prog main.o
/usr/bin/ld: main.o: in function `call_function1':
main.c:(.text+0x5): undefined reference to `function1'
collect2: error: ld returned 1 exit status
we need to input a file that defines function1, even though a program linked
with this main.o cannot possibly call function1.
Your function1 is defined, somehow, within a library libutils, which also
defines function2. Your program does not reference function2, but
the definition of function2 references one or more symbols, say function3, that are defined,
somehow, within another library libanother.
Do you need to add libanother, as well as libutils to the linkage of your
program?
From first principles, we know you must add libanother to your linkage if you link a file that references function3.
function3 is referenced in the definition of function2. So you must link with libanother
if you link a file that contains the definition of function2.
Do you need to link such a file?
That depends on the implementation of libutils itself.
Case 1
Suppose you have implemented libutils as a static library in which you have
archived an object file that defines function1 and another object file that
defines function2. Like so:
function1.c
#include <stdio.h>
void function1(void)
{
puts(__func__);
}
function2.c
extern void function3();
void function2(void)
{
function3();
}
Compile the source files:
$ gcc -Wall -c function1.c function2.c
Archive the object files:
$ ar rcs libutils.a function1.o function2.o
Link prog like:
$ gcc -o prog main.o libutils.a
No problem. Run:
$ ./prog
Hello World!
Let's do the linkage again, this time with diagnostics to show what
object files and shared libraries were actually linked:
$ gcc -o prog main.o libutils.a -Wl,-trace
/usr/bin/ld: mode elf_x86_64
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o
main.o
(libutils.a)function1.o
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1)
/lib/x86_64-linux-gnu/libc.so.6 (//lib/x86_64-linux-gnu/libc.so.6)
(//usr/lib/x86_64-linux-gnu/libc_nonshared.a)elf-init.oS
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1)
/usr/lib/gcc/x86_64-linux-gnu/8/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o
Most of those inputs are boilerplate object files and shared libraries that
gcc adds to program linkage by default. The files that we built are just:
main.o
(libutils.a)function1.o
The archive member libutils.a(function2.o) wasn't linked at all, because
no file was linked that references function2. So it doesn't matter that
libutils.a(function2.o) makes an undefined reference to function3. libutils.a(function2.o)
might as well not exist. The linkage:
$ gcc -o prog main.o libutils.a
is exactly the same linkage as:
gcc -o prog main.o function1.o
Case 2
Suppose you've implemented libutils as a static library that contains
one object file that defines both function1 and function2:
function12.c
#include <stdio.h>
void function1(void)
{
puts(__func__);
}
extern void function3(void);
void function2(void)
{
function3();
}
Compile that file:
$ gcc -Wall -c function12.c
Recreate libutils.a:
$ rm libutils.a
$ ar rcs libutils.a function12.o
Relink prog:
$ gcc -o prog main.o libutils.a -Wl,-trace
/usr/bin/ld: mode elf_x86_64
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o
main.o
(libutils.a)function12.o
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1)
/lib/x86_64-linux-gnu/libc.so.6 (//lib/x86_64-linux-gnu/libc.so.6)
(//usr/lib/x86_64-linux-gnu/libc_nonshared.a)elf-init.oS
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1)
/usr/lib/gcc/x86_64-linux-gnu/8/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld: libutils.a(function12.o): in function `function2':
function12.c:(.text+0x32): undefined reference to `function3'
/usr/bin/ld: link errors found, deleting executable `prog'
collect2: error: ld returned 1 exit status
This time, as the -trace output shows, our object files:
main.o
(libutils.a)function12.o
were linked. main.o referenced function1, so the linker searched libutils.a
for an object file that defines function1. It found function12.o and linked
it, including the definition of function2 as well as the definition of function1.
The definition of function2 introduced an unresolved reference to function3,
into the program. No file was linked that resolved that reference, so the
linkage failed:
function12.c:(.text+0x32): undefined reference to `function3'
It doesn't matter that function2 cannot be called by the program -
just like it doesn't matter that function1 cannot be called.3
Case 3
You have implemented libutils as a shared library, by linking position-independent
object files function1.o and function2.o compiled from function1.c and function2.c
respectively:
$ gcc -Wall -fPIC -c function1.c function2.c
$ gcc -shared -o libutils.so function1.o function2.o
Notice here that although the shared library libutils.so is an ELF file produced
by linkage (not an ar archive of object files), we are able to link it successfully
despite the fact that function2.o contains an undefined reference to function3.
It is fine to link a shared library with undefined references. See its symbol table:
$ nm libutils.so
0000000000004030 b completed.7930
w __cxa_finalize##GLIBC_2.2.5
0000000000001060 t deregister_tm_clones
00000000000010d0 t __do_global_dtors_aux
0000000000003e18 t __do_global_dtors_aux_fini_array_entry
0000000000004028 d __dso_handle
0000000000003e20 d _DYNAMIC
0000000000001150 t _fini
0000000000001110 t frame_dummy
0000000000003e10 t __frame_dummy_init_array_entry
00000000000020f0 r __FRAME_END__
0000000000002020 r __func__.2361
0000000000001115 T function1
0000000000001142 T function2
U function3
0000000000004000 d _GLOBAL_OFFSET_TABLE_
w __gmon_start__
000000000000202c r __GNU_EH_FRAME_HDR
0000000000001000 t _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U printf##GLIBC_2.2.5
0000000000001090 t register_tm_clones
There is U function3. But you can't link a program with undefined references:
$ gcc -o prog main.o libutils.so -Wl,-trace
/usr/bin/ld: mode elf_x86_64
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/8/crtbeginS.o
main.o
libutils.so
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1)
/lib/x86_64-linux-gnu/libc.so.6 (//lib/x86_64-linux-gnu/libc.so.6)
(//usr/lib/x86_64-linux-gnu/libc_nonshared.a)elf-init.oS
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (//lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so.1)
/usr/lib/gcc/x86_64-linux-gnu/8/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o
/usr/bin/ld: libutils.so: undefined reference to `function3'
/usr/bin/ld: link errors found, deleting executable `prog'
collect2: error: ld returned 1 exit status
When we link:
main.o
libutils.so
the linkage fails just as with:
main.o
(libutils.a)function12.o
or indeed:
$ gcc -o prog main.o function1.o function2.o
/usr/bin/ld: function2.o: in function `function2':
function2.c:(.text+0x5): undefined reference to `function3'
collect2: error: ld returned 1 exit status
So:
Is it required to link in all dependencies?
Yes, when you're linking a program. But understand what the dependencies of
a program are:
The dependencies of the program are object files and/or shared libraries
that define the symbols that are referenced in the object files and shared libraries
that are actually linked.
A static library is never one those. It is a container of object files from which
the linker will extract and link ones that are dependencies of the program and ignore
the rest.
[1] What the linker does to link an object file into a program is fundamentally
different from what it does to link a shared library.
Roughly, to link an object file, it physically merges the parts of which the object
file is composed into the corresponding parts of the output program.
Roughly, to link a shared library liby.so, the linker just writes some concise information in
a standard format into the program that will be parsed by the runtime loader,
instructing it to find and load liby.so and merge the parts of which it is
composed into the process of the executed program.
[2] You can check whether your GCC toolchain defaults to --as-needed or not
by grepping for that option in the verbose output of a default GCC linkage, e.g.
$ gcc -v -o prog main.o function1.o 2>&1 | grep '\--as-needed'
[3] We can compile object files with a non-default compilation option -ffunction-sections
and link them in programs with a non-default linker option -gc-sections, with the
effect that the linker will be able to discard definitions of functions that
cannot called, so that they cannot give rise to any references that impose useless
dependencies on the program.
If no call made from second library, it is not required. Typically linker will give error if function in linking for which library or its definition is not present during linking as undefined.
For example, consider that I wrote a Fortran program in one computer and want to run it on another computer which may not have required libraries and/or has a different compiler (or even better, no Fortran compiler at all). Is it possible to create an executable with all its dependencies?
I am using gfortran (7.2.1) in Fedora 26 and sometimes use LAPACK routines in my code.
Using -static option with the program
program main
write (*,*) 'Hello'
end
I get the output
gfortran -static a.f90
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
There is no error with gfortran -static-libgfortran a.f90
In Fedora, gcc does not ship by default with static libraries.
You need to install the package glibc-static for the -static option to work, as hinted in this related question.
Note that -static-libgfortran will only do static linking of the libgfortran library and that you must have static versions of your dependencies as well.
The best option is to use Alpine Linux that uses musl libc. I highly recommend using the docker image (only 5 Mb).
I've been programming on a 32 bit machine, until recently, I upgraded to a 64 bit one. I'm using the latest version of DMD (amd64), on xubuntu 16.04 (amd64).
Before the upgrade, I could easily compile shared libs using dmd -shared 'FILES', but now, it gives an error.
I have a file named q.d:
module q;
export extern(C) int abcd(){
return 4;
}
And now when I do dmd -shared 'q.d', I get this:
nafees#OptiPlex-755:~/Desktop/temp$ dmd -shared q.d
/usr/bin/ld: q.o: relocation R_X86_64_32 against `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC
q.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
--- errorlevel 1
and when I do dmd -shared -fPIC q.d:
nafees#OptiPlex-755:~/Desktop/temp$ dmd -shared -fPIC q.d
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(exception_224_3b4.o): relocation R_X86_64_32 against `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC
/usr/lib/x86_64-linux-gnu/libphobos2.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
--- errorlevel 1
How can I get it to compile?
EDIT: The library compiles fine if I use the -m32 flag.
Oh, I just realized I know this problem, sorry it took me so long to realize it though.
You just need to compile against the shared lib Phobos as well to make the shared lib on 64 bit.
dmd -shared q -m64 -fPIC -defaultlib=libphobos2.so
The -defaultlib switch tells it to use an alternate library. By specifying the .so (as opposed to the default static link with a .a file), it uses the shared lib - which happens to be compiled with -fPIC too, so it is all compatible.
Among other advantages here is that one runtime can be shared across all the shared objects and D executables, which means a lot of things just work when you distribute them all (though note you may also need to compile the program that loads this so with the -defaultlib switch too). On 32 bit, the library isn't built with these options regardless... but the result is you can see link errors for multiple definitions in some circumstances.
The one thing to be careful though is that libphobos2.so file is now a runtime dependency too, be sure to distribute it with your own library builds together. You might need to set the LD_LIBRARY_PATH or install it globally for the program to start up correctly, just like any other library (and you might want to version it too btw)
I have a C99 shared library that I want to link in a few statically static libraries (via --whole-archive). Note: All the static libs are built with -fPIC
I also would like to build a universal linux binary and thus have decided to use musl. When I try to link in the static libc.a from musl I get the following error:
# Building shared library tgt/Linux-x86_64/mylib/lib/mylib.so
/root/mylib/./tgt/Linux-x86_64/libmusl/bin/musl-gcc -Wl,-whole-archive -L./tgt/Linux-x86_64/libmusl/lib -L./tgt/Linux-x86_64/libz/lib -L./tgt/Linux-x86_64/libssl/lib -L./tgt/Linux-x86_64/libsasl/lib -L./tgt/Linux-x86_64/librdkafka/lib -L./tgt/Linux-x86_64/libcurl/lib -L./tgt/Linux-x86_64/libgjalloc/lib -L./tgt/Linux-x86_64/libavro/lib -L./tgt/Linux-x86_64/libunwind/lib -l:libc.a -l:libpthread.a -l:libz.a -l:libssl.a -l:libcrypto.a -l:libsasl2.a -l:libm.a -l:librt.a -l:libcrypt.a -l:libunwind-x86_64.a -l:librdkafka.a -l:libcurl.a -l:libgjalloc.a -l:libavro.a -Wl,-no-whole-archive -shared -fPIC -o tgt/Linux-x86_64/mylib/lib/mylib.so ./tgt/Linux-x86_64/mylib/obj/myfile.o ./tgt/Linux-x86_64/mylib/obj/myotherfile.o ./tgt/Linux-x86_64/mylib/obj/cJSON.o
/usr/bin/ld: ./tgt/Linux-x86_64/libmusl/lib/libc.a(exit.lo): relocation R_X86_64_PC32 against undefined hidden symbol `__fini_array_start' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make: *** [tgt/Linux-x86_64/mylib/lib/mylib.so] Error 1
My musl build looks like:
cd mystatic_libs_build_dir/musl; \
./configure CFLAGS='-fPIC' \
--enable-shared \
--enable-static \
--prefix=/root/mylib/tgt/Linux-x86_64/libmusl; \
make; make install;
# libmusl is available
exit.lo will be written in assembler which is why your CFLAGS='-fPIC' is not having the effect you intend. This is either 1. a bug in 'musl' or 2. intentional and they do not support statically linking into .so's.
I would assume that it is unintentional and file a bug against 'musl'
You could also edit the asm yourself if you need a fix quickly.
Finally you might be able to configure musl to build with no asm?
Slightly off topic, but other options for a universal binary are:
Simply linking against glibc on the oldest version of Linux that you support.
Rather than struggling with a dependency on 'musl', simply use the Linux kernel api's directly.
Recompile musl as long as your own code with CFLAGS="-fPIC -Wa,-mrelax-relocations=no" (your binutils version must be >=2.27).
I have a llvm module that i've dumped as bitcode file with llvm::WriteBitcodeToFile. I want to turn this bitcode file into an native dynamically loadable library that contains the functions in the module.
How do i do this? i tried using llc for this, but this produces code that apparently is not relocatable, since after doing the following steps:
llc -enable-pie -cppgen=functions -filetype=asm executableModule -o em.s
then, assemblying with gnu as into an object file:
as -o mylib.o em.s
finally, trying to produce a shared library with:
gcc -shared -o libmyfile.so -fPIC mylib.o
fails with the error:
/usr/bin/ld: error: mylib.o: requires dynamic R_X86_64_PC32 reloc against 'X.foo' which may overflow at runtime; recompile with -fPIC
collect2: ld returned 1 exit status
You need to setup relocation model. Something like -llc -relocation-model=pic. Do not use PIE, because it's for executables, not for libraries. Also, -cppgen does not make any sense here, it's for cpp backend only.