Linking to statically compiled z3 needs additional libraries on Linux - z3

I used CMake to compile a static version of (a fairly recent of) z3 using:
cmake -DBUILD_LIBZ3_SHARED=false -DCMAKE_INSTALL_PREFIX=/opt/z3-devel -G "Unix Makefiles" ../
Now when I statically link the library against a C++ program, say this small variation of a z3 example:
#include"z3++.h"
using namespace z3;
int main(int argc, char** argv) {
config conf;
context c(conf);
expr x = c.int_const("x");
expr y = c.int_const("y");
expr z = c.int_const("z");
goal g(c);
g.add( ((2*x)+y)+z == 4);
g.add( (x+(2*y))+z == 4);
g.add( x+y == 4);
std::cout << g << "\n";
tactic t(c, "fm");
apply_result r = t(g);
std::cout << r << "\n";
return 0;
}
via
g++ -c -I /opt/z3-devel/include -static -o main.o main.cc
g++ -static -L /opt/z3-devel/lib64 -o main main.o -lz3
I receive a long list of undefined reference linking errors. What solves the issue is to add -lgomp -pthread -lrt -ldl as additional libraries. The linker outputs the following warning:
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/8/libgomp.a(target.o): in function `gomp_target_init':
(.text+0x32c): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
Nevertheless, the program runs fine on my own machine and on Starexec.
Is this combination of static and dynamic linking the best I can do? Shouldn't those libraries be already statically linked into libz3.a? I have static versions of gomp, pthread and rt available on the system.

Related

llvm-link error when using memcpy in C code and compiling with wasm target

I am trying to compile two *.c files to LLVM bitcode via clang, link them together using llvm-link, and make a single *.wasm file out of it. I built LLVM on my machine via the Makefile provided by https://github.com/yurydelendik/wasmception
This works fine until I use memcpy in the C code. Then llvm-link stops with error:
Intrinsic has incorrect argument type!
void (i8*, i8*, i32, i1)* #llvm.memcpy.p0i8.p0i8.i32
The following is a minimal example to reproduce the issue:
one.c
#define EXPORT __attribute__((visibility("default")))
#include <string.h>
char* some_str();
EXPORT void do_something() {
char* cpy_src = some_str();
char other_str[15];
memcpy(other_str, cpy_src, strlen(cpy_src));
}
two.c
char* some_str() {
return "Hello World";
}
Execute the following commands:
$ clang --target=wasm32-unknown-unknown-wasm --sysroot=../wasmception/sysroot -S -emit-llvm -nostartfiles -fvisibility=hidden one.c -o one.bc
[...]
$ clang --target=wasm32-unknown-unknown-wasm --sysroot=../wasmception/sysroot -S -emit-llvm -nostartfiles -fvisibility=hidden two.c -o two.bc
[...]
Note that no optimization is done because that would eliminate the unnecessary memcpy call here. As I said, this is a minimal example out of context to show the error.
$ llvm-link one.bc two.bc -o res.bc -v
Loading 'one.bc'
Linking in 'one.bc'
Loading 'two.bc'
Linking in 'two.bc'
Intrinsic has incorrect argument type!
void (i8*, i8*, i32, i1)* #llvm.memcpy.p0i8.p0i8.i32
llvm-link: error: linked module is broken!
When I comment out the memcpy call in the example file, the error is gone. Of course this is not an option in the real project I am working at.
Am I doing something wrong? Is it a bad idea in general to use memcpy in a WebAssembly context? Can this be a bug in LLVM/Clang?
Reading through these github issues, it seems the memcpy intrinsic is not currently supported by the WASM backend:
https://github.com/WebAssembly/design/issues/236
https://github.com/WebAssembly/design/issues/1003
As a workaround, you could instruct clang to disable intrinsic expansion using -fno-builtin, so that the generated code will call the actual memcpy function.

Error in compiling using gsoap

I am trying to compile the files after generating from these steps:-
(1) wsdl2h -o calc.h http://www.genivia.com/calc.wsdl
(2) soapcpp2 -j -CL calc.h
(3) Creating a main.cpp with the following code:-
#include "calc.nsmap" // XML namespace mapping table (only needed once at the global level)
#include "soapcalcProxy.h" // the proxy class, also #includes "soapH.h" and "soapStub.h"
int main()
{
calcProxy calc;
double sum;
if (calc.add(1.23, 4.56, sum) == SOAP_OK)
std::cout << "Sum = " << sum << std::endl;
else
calc.soap_stream_fault(std::cerr);
calc.destroy(); // same as: soap_destroy(calc.soap); soap_end(calc.soap);
}
After it I compile issuing the command:-
g++ -o calcclient main.cpp soapcalcProxy.cpp soapC.cpp -lgsoap++
I get the following errors:-
/tmp/ccA5Ergj.o: In function `soap_ignore_element(soap*)':
soapC.cpp:(.text+0x112d): undefined reference to `soap_ignore'
/tmp/ccA5Ergj.o: In function `soap_putelement':
soapC.cpp:(.text+0x149b): undefined reference to `soap_element_empty'
collect2: error: ld returned 1 exit status
Please help in compiling.
I solved this. I was thinking the lib is in /usr/lib but it was in /usr/local/lib. I included -L/usr/local/lib while compiling, and it worked.

AM_PROG_LEX and undefined yywrap

My program uses the documented autoconf macro AM_PROG_LEX. It builds fine on RHEL 6.5 and other distros, but fails on RHEL 6.6 and later.
The configure script cannot compile its tests. When it tries gcc with -ll, -lfl, linking fails with:
/usr/bin/ld: cannot find -lfl
When it tries gcc without extra libraries, linking fails with:
undefined reference to `yywrap'
libfl.a or libfl.so is missing from official repos of those systems. On RHEL 6.5 it's part of flex package.
RHEL 6.5
configure:5334: checking whether yytext is a pointer
configure:5351: gcc -o conftest -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O0 conftest.c -lfl >&5
configure:5351: $? = 0
configure:5359: result: yes
RHEL 6.8
configure:5196: checking whether yytext is a pointer
configure:5217: gcc -o conftest -g -O2 conftest.c >&5
/tmp/ccNJtVgv.o: In function `input':
/home/git/rpmbuild/BUILD/snacc-1.3.1_16_g23ba7a6/lex.yy.c:1168: undefined reference to `yywrap'
/tmp/ccNJtVgv.o: In function `yylex':
/home/git/rpmbuild/BUILD/snacc-1.3.1_16_g23ba7a6/lex.yy.c:867: undefined reference to `yywrap'
/tmp/ccNJtVgv.o: In function `main':
/home/git/rpmbuild/BUILD/snacc-1.3.1_16_g23ba7a6/conftest.l:17: undefined reference to `yywrap'
collect2: ld returned 1 exit status
configure:5224: $? = 1
configure: failed program was:
...
configure:5246: result: no
libfl contains two and only two functions, both of which are normally unnecessary in production use of flex:
int main() { extern int yylex(void); while (yylex()) ; return 0; }
int yywrap(void) { return 1; }
The yywrap implementation (which essentially disables the yywrap functionality) is not necessary if you use the option
%option noyywrap
in your flex definition, or if you pass the command-line option --noyywrap to flex.
For quick-and-dirty flex scanners, or for debugging, it is sometimes handy to be able to use libfl to fill in the above functions. But it also can create problems on systems which provide both 32- and 64-bit environments. For this reason, libfl was removed from the RHEL flex rpm in 2014. See this RedHat bug fix advisory for details.
So you could install the appropriate flex-devel rpm in order to have libfl available. Or you could compile it yourself using the above code (which is not precisely the source code you'll find in the flex source bundle, but should produce precisely the same library).
Or you could try to fix autoconf so that it doesn't depend on libfl. It didn't used to have any such dependency; if it couldn't find libfl, it would just assume that it wasn't required for the program being compiled.
Workaround is to install flex-devel package containing libfl.a. RHEL version available to subscribers ony. Alternative is CentOS package or recompiling from source.

LLVM/Clang use opt to show linked ll file

I had two c files and want show IR for its linked bit code
link1.c
#include "link2.h"
int main() {
int a;
int b;
foo(a,b);
return 0;
}
link2.h
#include<stdio.h>
link2.c
#include "link2.h"
void foo(int a, int b) {
printf("%d\n", a);
printf("%d\n", b);
}
I did the following command to get bc file.
clang -o0 -emit-llvm file1.c -c -o file1.bc
clang -o0 -emit-llvm file2.c -c -o file2.bc
llvm-link -o link.bc link1.bc link2.bc
When I tried lli link.bc and llvm-dis link.bc it run correctly and showed linked ll file, but when I use opt link.bc -S -o link.ll to get ll file it just reported segmentation error. Can anyone let me know what to do with opt?
It seems like it is because version compatible issue of opt. I should use a 3.5 version but turns out I was using 3.4.2.

How / is it possible to build C "Hello world" program entirely static (OS X, Clang)?

Is it possible to compile C "Hello world" program to have final executable entirely static?
#include <stdio.h>
int main() {
printf("hello world!\n");
return 0;
}
I've tried the following:
clang -static main.c
But it gives:
ld: library not found for -lcrt0.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've seen staticly linked libc? but I want to get additional information on this topic.
P.S. I am asking this for education purposes rather than for real practice.

Resources