Can't build static boost-filesystem - boost

I've this example code.
#include <iostream>
#include <boost/filesystem.hpp>
using namespace std;
int main()
{
return 0;
}
It can be correctly build with: g++ -lboost_system-mt -lboost_filesystem-mt 1.cpp
But if I add -static, then it complains:
/tmp/cc1JEbRQ.o: In function `__static_initialization_and_destruction_0(int, int)':
1.cpp:(.text+0xb0): undefined reference to `boost::system::get_system_category()'
1.cpp:(.text+0xba): undefined reference to `boost::system::get_generic_category()'
1.cpp:(.text+0xc4): undefined reference to `boost::system::get_generic_category()'
1.cpp:(.text+0xce): undefined reference to `boost::system::get_generic_category()'
1.cpp:(.text+0xd8): undefined reference to `boost::system::get_system_category()'
collect2: ld returned 1 exit status
How do I fix that? Thanks

You probably need to reverse the order of your libraries for static linking to succeed, because boost_filesystem depends on boost_system:
g++ 1.cpp -static -lboost_filesystem-mt -lboost_system-mt
This is because the run-time linker does a topological dependency sort to load shared libraries in correct order, whereas static linking doesn't do that.
Alternatively, you can force static linking to do several passes over the list of libraries to try to resolve remaining undefined symbols:
man ld:
-( archives -)
--start-group archives --end-group
The archives should be a list of archive files. They may be either
explicit file names, or -l options.
The specified archives are searched repeatedly until no new
undefined references are created. Normally, an archive is searched
only once in the order that it is specified on the command line.
If a symbol in that archive is needed to resolve an undefined
symbol referred to by an object in an archive that appears later on
the command line, the linker would not be able to resolve that
reference. By grouping the archives, they all be searched
repeatedly until all possible references are resolved.
Using this option has a significant performance cost. It is best
to use it only when there are unavoidable circular references
between two or more archives.
e.g:
g++ 1.cpp -static -Wl,--start-group -lboost_system-mt -lboost_filesystem-mt -Wl,--end-group

Related

X11 linking issue potentially musl libc related

I am running Alpine Linux with musl libc attempting to install-
https://github.com/patrickhaller/no-wm/
with-
make install
I have musl-dev and libx11-dev installed.
libx11-dev puts libs in /usr/lib not /usr/X11/lib. see-
https://pkgs.alpinelinux.org/contents?branch=edge&name=libx11-dev&arch=x86&repo=main
So I changed the Makefile line to-
X11LIB = -lX11 -L/usr/lib/
I confirmed libX11.so is at that directory location.
Yet my install still fails with this output-
$ make install
gcc -O2 -Wall -std=c99 -pedantic -lX11 -L/usr/lib/ x-alt-tab-mru.c -o x-alt-tab-mru
/usr/lib/gcc/aarch64-alpine-linux-musl/10.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: /tmp/cckobJdo.o: in function `x_alt_tab':
x-alt-tab-mru.c:(.text+0x70): undefined reference to `XGetWMHints'
/usr/lib/gcc/aarch64-alpine-linux-musl/10.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: x-alt-tab-mru.c:(.text+0x84): undefined reference to `XGetWindowAttributes'
/usr/lib/gcc/aarch64-alpine-linux-musl/10.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: x-alt-tab-mru.c:(.text+0xec): undefined reference to `XLowerWindow'
/usr/lib/gcc/aarch64-alpine-linux-musl/10.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: x-alt-tab-mru.c:(.text+0xf8): undefined reference to `XRaiseWindow'
/usr/lib/gcc/aarch64-alpine-linux-musl/10.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: x-alt-tab-mru.c:(.text+0x10c): undefined reference to `XSetInputFocus'
/usr/lib/gcc/aarch64-alpine-linux-musl/10.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: x-alt-tab-mru.c:(.text+0x11c): undefined reference to `XRestackWindows'
/usr/lib/gcc/aarch64-alpine-linux-musl/10.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: x-alt-tab-mru.c:(.text+0x128): undefined reference to `XSync'
/usr/lib/gcc/aarch64-alpine-linux-musl/10.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: /tmp/cckobJdo.o: in function `main':
x-alt-tab-mru.c:(.text.startup+0x34): undefined reference to `XOpenDisplay'
/usr/lib/gcc/aarch64-alpine-linux-musl/10.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: x-alt-tab-mru.c:(.text.startup+0x44): undefined reference to `XSync'
/usr/lib/gcc/aarch64-alpine-linux-musl/10.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: x-alt-tab-mru.c:(.text.startup+0x70): undefined reference to `XQueryTree'
collect2: error: ld returned 1 exit status
make: *** [Makefile:19: x-alt-tab-mru] Error 1
I've confirmed the headers in that x-alt-tab-mru.c file are present in the correct location and were included with libx11-dev.
What can I do next to troubleshoot this and get it to compile? I've chased down everything I could think of..
The order of arguments on the link command line is significant. -L options apply only to searching for libraries designated later on the command line, and, at least for static linking, undefined symbols in one object among those being linked are resolved only against other objects designated later on the command line. Behavior may (or may not) vary a bit when linking shared libraries, but to be safe, you should always order the objects to be linked (source files, object files, and libraries) according to their dependencies.
In particular, then,
in the unlikely event that you need -L/usr/lib at all, it should come before -lX11, and
the -lX11 option should appear after x-alt-tab-mru.c in the link command.

How to generate position independent code in Halide with ahead of time compilation

I'm trying out halide and want to build a small shared library on top of it. But the code generated by Halide's AOT compilation seems not being position independent. How do I link the objects generated by Halide into my shared library?
[Update] extracted a small example from my code.
Specifically I used a generator with c++:
class SimpleAddition : public Halide::Generator<SimpleAddition> {
public:
SimpleAddition() : vars(4) {}
Input<Halide::Buffer<>> lhs{"lhs"};
Input<Halide::Buffer<>> rhs{"rhs"};
Output<Halide::Buffer<>> out{"out"};
std::vector<Var> vars;
void generate() {
out(vars) = lhs(vars) + rhs(vars);
}
};
HALIDE_REGISTER_GENERATOR(SimpleAddition, simple_addition)
with helpers from CMake:
halide_library(ops SRCS ${CMAKE_CURRENT_LIST_DIR}/src/simple_addition.cc
GENERATOR_NAME simple_addition
GENERATOR_ARGS lhs.type=float32 lhs.dim=4 rhs.type=float32 rhs.dim=4 out.type=float32)
and got the following error:
/usr/bin/ld: ./genfiles/halide_rt_host/halide_rt_host.a(halide_rt_host.a.o): relocation R_X86_64_PC32 against symbol `_ZN6Halide7Runtime8Internal13custom_mallocE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
I also tried generating object by running the generator myself (without CMake wrapper) with -e o,h, and similarly with llvm bitcode followed by llc -relocation-model=pic, also Func::compile_to_object. similar error occurred when I try to link the generated object back to shared library:
/usr/bin/ld: halide_runtime_x86.o: relocation R_X86_64_PC32 against symbol `_ZN6Halide7Runtime8Internal13custom_mallocE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
I'm running this on Ubuntu 18.10. Both Halide and my code are compiled with gcc-8.2.0. LLVM/Clang-7 is the one shipped in their repository. Halide is built with simple cmake ../ && make && make install.
For compiler flags of my testing code, command used in CMake is add_libarary(mylib SHARED ...). Non-CMake build is with flags like -fPIC -shared, nothing special since I'm still learning.
Halide should be generating PIC by default (see Codegen_Internal.cpp, make_target_machine()). What architecture are you targeting? What compiler/linker are you using, with what options, etc?

fglut/libfglut.a(freeglut_state.o): undefined reference to symbol 'XGetWindowAttributes'

I am compiling a C++ program using make, this is the error i'm getting.
/usr/bin/ld: fglut/libfglut.a(freeglut_state.o): undefined reference to symbol 'XGetWindowAttributes'
//usr/lib/i386-linux-gnu/libX11.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:55: recipe for target 'morphlines' failed
make: *** [morphlines] Error 1
I'm beginner
/usr/bin/ld: fglut/libfglut.a(freeglut_state.o):
This tells me you link libfglut statically (*.a is just an archive of object files). When you do this, you must link all dependencies as well, because with the object files from the static library actually compiled into your program, your program will depend on them.
Either link libfglut dynamically (this is the default with the GNU toolchain), so your program will depend on libfglut.so which will itself depend on libX11.so -- or add -lX11 after -lfglut on the command line of your final linking step. You might need -Wl,-Bdynamic before -lX11 to switch the linker back to dynamic linking.
If this doesn't directly solve your problem, I suggest you edit your question to include the relevant parts of the Makefile you're using.

GCC ICU 57 static linking

I am trying to link ICU 57 to my binary file. That does not work even thought (I think at least) I am linking the static lib files.
Here is a blunt example:
gcc -static /usr/lib/libicui18n.a /usr/lib/libicuuc.a /usr/lib/libicudata.a /usr/lib/libicule.a /usr/lib/libiculx.a /usr/lib/libicutu.a /usr/lib/libicuuc.a /usr/lib/libicuio.a obj/ex.o obj/msg.o -o bin/ex
This is the error message that I get:
src/msg.c:5: undefined reference to `u_fopen_57'
src/msg.c:9: undefined reference to `u_fgetfile_57'
src/msg.c:10: undefined reference to `u_fgetfile_57'
src/msg.c:11: undefined reference to `u_frewind_57'
src/msg.c:18: undefined reference to `u_fgetc_57'
src/msg.c:17: undefined reference to `u_feof_57'
src/msg.c:25: undefined reference to `u_fclose_57'
Linking the dynamic libs works fine though.
If you can, I'd recommend using pkg-config as I recommended here,
specifically with pkg-config --static … as explained here

Can't find libstdc++?

I built gcc 4.9.0 from source, and was also planning on building clang 3.4.2, however something seems to have gone awry with regards to libstdc++, as the clang build baled pretty quickly with the linker complaining about various undefined references from std.
Indeed, I then tried compiling and linking the trivial program:
#include <iostream>
int main() {
std::cout << 42;
}
and again hit linker errors:
/tmp/ccrptgVW.o:temp.cpp:function main: error: undefined reference to 'std::cout'
/tmp/ccrptgVW.o:temp.cpp:function main: error: undefined reference to 'std::ostream::operator<<(int)'
/tmp/ccrptgVW.o:temp.cpp:function __static_initialization_and_destruction_0(int, int): error: undefined reference to 'std::ios_base::Init::Init()'
/tmp/ccrptgVW.o:temp.cpp:function __static_initialization_and_destruction_0(int, int): error: undefined reference to 'std::ios_base::Init::~Init()'
collect2: error: ld returned 1 exit status
(full gcc -v output), both with my freshly-minted gcc 4.9.0 and my Ubuntu's stock gcc 4.6.3.
libstdc++.so exists, in /usr/local/lib64:
ls /usr/local/lib64/libstd*
/usr/local/lib64/libstdc++.a
/usr/local/lib64/libstdc++.so
/usr/local/lib64/libstdc++.so.6.0.20
/usr/local/lib64/libstdc++.la
/usr/local/lib64/libstdc++.so.6
/usr/local/lib64/libstdc++.so.6.0.20-gdb.py
and this directory appears in LIBRARY_PATH and as an -L argument to collect2 in the verbose gcc output.
How do I restore sanity to my system and have the linker find the shared library?
As turns out from your comment, you compiled with gcc rather than g++.
Do not take it as an error, as the compilation went fine! What's showing up is a linker error. Indeed, gcc will tell ld to link against the C standard library rather than the C++ standard one.
To solve, either go for g++ directly or pass -lstdc++.

Resources