I am trying to compile apache2 with LLVM, to generate final binaries in LLVM IR.
I used flto option in compiling and linking and passed "also-emit-llvm" to the linker through clang.
It seems to work for most steps, however I had two concerns
1) Earlier I used LLVM 3.6, whose gold plugin doesn't accept also-emit-llvm, but has emit-llvm only, basically it will emit only elf or llvm. Which the Autotools build system doesn't like. The configure and make script want binaries, while I want llvm. Any solutions to this?
2) So I shifted to LLVM 3.5.2, the build process goes well, I can generate both httpd.bc and httpd elf binaries, but the linker doesn't want to link for modules (it was able to link for binaries)
Specifically, I get this error
`
/usr/share/apr-1.0/build/libtool --silent --mode=link /home/rbhatia/Desktop/llvm-newbuild/bin/clang -pthread -flto -o mod_authn_file.la -rpath /home/rbhatia/Desktop/httpd-2.4.12/llvm/modules -module -avoid-version mod_authn_file.lo
/usr/bin/ld: error: .libs/mod_authn_file.o:1:3: invalid chaenter code hereracter
/usr/bin/ld: error: .libs/mod_authn_file.o:1:3: syntax error, unexpected $end
/usr/bin/ld: error: .libs/mod_authn_file.o: not an object or archive
collect2: error: ld returned 1 exit status
`
I can see that mod_authn_file.o is a valid LLVM IR file which I can disassemble with llvm-dis.
Also, just before this step, the linker is able to link httpd and httpd.bc
Any help on what the error is?
Take a look at
https://github.com/SRI-CSL/whole-program-llvm
we use this tool to build quite large projects into bitcode. Our
biggest so far was FreeBSD 10.0, so size is not usually an issue.
Our travis build check is actually
apache, as is our tutorial. Hope that helps.
Related
I recently added libcurl dependency to my c++ library. I statically compiled libcurl with-nss for https support. I use Debian 7 for compilation.
I create two builds for my library - static and shared
Shared version is linking fine with binaries built on any Linux distro, but the static build only links with binaries when compiled on Debian 7.
I tried static linking on Ubuntu 16.04, Debian Stretch but all are reporting following error during compilation:
g++ -Wall -o Sample Sample.cpp -Wl,-Bstatic -L. -lMyLibrary -Wl,-Bdynamic -lssl3
/usr/bin/ld: ./libMyLibrary.a(libcurl_la-nss.o): undefined reference to symbol 'CERT_GetDefaultCertDB##NSS_3.2'
//usr/lib/x86_64-linux-gnu/libnss3.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:22: recipe for target 'Sample' failed
make: *** [Sample] Error 1
Static compilation now only works on Debian 7 which is a big problem.
Static libraries are just archives of object files. As one consequences, they don't carry any dependency information. So, if you link a static library which depends on some other libraries, you have to add these explicitly in your linking command.
In your case, this means:
find whoever defines CERT_GetDefaultCertDB##NSS_3.2 -- some answers to this FAQ could help here
add this library to your linker command (with -l, after your static library)
I'm trying different C linear algebra libraries for my projects and now I want to learn BLAS (CBLAS). I am trying to follow the tutorial here. I realised that cblas is already built in the xcode and by adding the flag
gcc foo.c -framework Accelerate
or
gcc foo.c -lcblas
I can remove most of the errors I had before. however there is a final error which I can not find anywhere on the internet.
Undefined symbols for architecture x86_64:
"_printVector", referenced from:
_main in blas1C-63e43d.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I'm not sure where I'm making the mistake but there are a number of possibilities:
I need to instal BLAS/CBLAS from the netlib website. I actually tried to do this but I could manage to build the library from the source code! it would be great if somebody could make a Homebrew formula. then if the original CBLAS library installed then I need to learn about the gcc flags for compiling and how to link the libraries.
or there are syntax differences between the original CBLAS from netlib and the one built in the xcode and I need to change the code.
thanks for your help in advance.
P.S. I'm trying to compile the codes blas1C.c, blaio.c, blaio.h from the page I mentioned.
edit 1: oh my! I just realised that I have made a horrible mistake. the printVector function missing is not part of CBLAS but a function made by the author of the blog. the only thing I had to do was just to compile the blaio.c file as well. so the correct gcc command should be
gcc blas1C.c blaio.c -lcblas
or
gcc blac1C.c blaio.c -framework Accelerate
That function comes from the blasio.c in the website and declared in blasio.h
You need to build blasio and link to it
I have been trying to run this model, written some decades ago by someone else. I've built the libraries, but when I try to actually run the program, I get the following error:
f77 -o mimics1.5 ../source/*.o trunk_hght_f.f
trunk_hght_f.f:
trunk_hght_func:
Undefined symbols for architecture x86_64:
"MAIN__", referenced from:
-u command line option
(maybe you meant: _MAIN__)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I am on MacOSX 10.11, and which f77 gives /usr/local/bin/f77 and f77 -v gives back:
Cynthias-MacBook-Pro-2:input_dir cynthiag$ f77 -v
/usr/local/bin/f77 script based on f2c:
f2c (Fortran to C Translator) version 20100827.
Should f77 be in /usr/bin/instead?
ld seems to be the problem, so I followed instruction from HERE to try to solve it, but it looks like my XCode is up to date, that my libraries are built and linked (as far as I can tell), and I even reinstalled binutils to make sure ld was in teh right place, but no success.
which ld gives : /usr/bin/ld and ld -v gives:
Cynthias-MacBook-Pro-2:input_dir cynthiag$ ld -v
#(#)PROGRAM:ld PROJECT:ld64-264.3.102
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
LTO support using: LLVM version 7.3.0
I am new to fortran, so I probably messed up when setting up f77, but I've been stuck on this problem for a few days now, so any help would be greatly appreciated!
In the end, it seem like the solution for me was just to use gfortran instead of f77. This involved carefully switching all the mentions to f77 in the model (i.e. in all the Makefiles) and replacing them by gfortran.
A clean install of the libraries was then necessary, since apparently a library compiled in f77 will not be compatible with gfortran.
Finally, the model was calling on some executable without ./ which caused the model to failed.
Unfortunately, I can't give an explanation as to why f77 was failing, but gfortran was a lot easier to set up than f77/f2c and worked great, so it's probably the way to go.
I'm currently trying to compile Clang/LLVM for a bare metal aarch64 target. Compiling Clang was straightforward - in fact I have compiled to target multiple architectures including arm and aarch64. For the backend I'm using binutils. Since binutils can only target one architecture I've built both aarch64 and arm versions of this. Again building seemed to be straightforward. I built binutils for aarch64 using:
mkdir build
cd build
../configure --target=aarch64-none-elf
make
from an unpacked source package of binutils 2.24.
The problem I'm having is that I can't get my custom build of ld to handle archive files properly. It seems to find and open archive files without a problem but fails to search it for undefined symbols when compiling the final binary. Here's some more concrete details via an example:
Create a simple main.s file by compiling:
int foo();
int main() { return foo(); }
with Clang and using --target=aarch64 -S, i.e. to emit an architecture specific assembly file.
Do the same to create foo.s by compiling:
int foo() { return 0; }
Assemble both .s files to .o files using custom gas build from binutils.
Create an archive libfoo.a by running custom ar and ranlib builds from binutils using ar cr foo.a foo.s and ranlib libfoo.a.
Try to link the two files together using ld -L. -lfoo -o main.elf main.o.
The output shows an undefined reference to foo.
bar.cpp:(.text+0x14): undefined reference to `foo()'
I can run readelf on foo.a and it seems perfectly well formed. In particular I can see the public symbol for foo. If I run ld with --verbose then I see
attempt to open ./libfoo.a succeeded
but no indication that it's found any symbols.
If I link directly with the object files, i.e. using ld -o main.elf foo.o main.o then I get a well formed elf file. Furthermore, if I extract foo.o back out of libfoo.a then I can also link succesfully with the extracted foo.o.
Does anyone have any ideas why this might be happening? I'm pretty sure my clang build is okay as the emitted assembly files effectively decouple the problem from clang. I'd guess also that the assembled .o files are fine. So this only leaves ar/ranlib or ld as the culprit.
To try to eliminate ar/ranlib as the culprits I rebuilt binutils for arm (same steps but using --target=arm-none-eabi). If I integrate the built ar/ranlib binaries into a known good arm-eabi-none GCC toolchain then they seem to work correctly. My suspicions thus point to ld at the moment. Note that I get the same problem with the main/foo example as above if I use my Clang build with the arm build of binutils.
I also tried integrating the arm version of ld into the existing known good GCC toolchain, but got:
this linker was not configured to use sysroots
Need to figure that out. That's still a bit cryptic for me right now. It prevents me from sanity checking the arm ld build.
It might well be that I'm doing something obviously wrong, but right now I don't see it.
Notes:
I had to hack the make script for binutils to add a couple of -Wno-xxx flags. I need to do this the "correct" way, but I don't think this hack should affect the output.
I'm building/hosting all tools on OSX 10.9.4 64-bit.
UPDATE:
The error about sysroots is simple. The pre-existing toolchain was configured with flags:
--with-prefix $SOME_INSTALL_DIR
--with-sysroot $SOME_INSTALL_DIR/arm-none-eabi
If I rebuild with these then I can slot in my ld version without a problem and it works. I got excited thinking that this might have been my mistake. Previously I wasn't running make install as I didn't really care about installing at this stage. I thought perhaps my new build of ld was referencing OSX system libs/exes somehow (although I'm not sure exactly what it could reference, other than perhaps ar, i.e. if it runs ar to handle archives). However I still have the same problem with both the arm and arrach64 versions of binutils even when configured like this.
Looks like I was dramatically overthinking the problem and also missing something I'd never quite realised about ld. The issue was with the line:
ld -L. -lfoo -o main.elf main.o
I hadn't realise that ld is sensitive to object file/library ordering. The undefined reference to foo() was in main.o. I specified the library libfoo.a as input before main.o is parsed. This means that the linker doesn't bother searching libfoo.a for the symbol as it's already processed this library. main.o must be specified before, e.g.
ld -L. main.o -lfoo -o main.elf
Even wrapping -lfoo with --start-group ... --end-group doesn't fix this.
I'm still feeling somewhat surprised by this. And I've yet to convince myself it's a good feature of ld. Seems like the only use case I can think of right now is to sneakily allow duplicate symbols.
Time for a cup of tea!
I;m trying to compile GnuTLS. When I thy to configure the package I get this error:
configure:8820: gcc -std=gnu99 -o conftest -g -O2 conftest.c -lnettle -lhogweed -lgmp >&5
/usr/bin/ld: cannot find -lhogweed
collect2: ld returned 1 exit status
I searched google for hogweed but there is no such a package? How I can fix this problem?
When linking with libraries you remove the lib from their name and append it to -l
ie for example libcrypto library will be linked by passing option -lcrypto
in your case its is -lhogweed that is missing. That means libhogweed library is missing.
A simple Google search of 'libhogweed' shows that its a part of 'GNU Nettle cryptographic library'. So you can install this and fix your problem.
I think you need to install the Nettle cryptographic library. As you didn't post your OS, I can't give more details.
More information on Nettle and Hogweed: http://www.lysator.liu.se/~nisse/nettle/nettle.html#Linking
According to this message, you need to build Nettle after you install GMP. Try to rebuild Nettle and see if it gets built.