I am trying to install NetCDF with PGI. However, to do so, I first need to install zlib and when I try to do that, I do:
export C_INCLUDE_PATH=/the/path/to/include/:$C_INCLUDE_PATH
export PATH=/the/path/to/compilers/bin/:$PATH
Then I try:
CC=pgcc CXX=pgc++ ./configure --archs="x86_64"
I get the following error:
Building shared library libz.so.1.2.11 with pgcc.
Checking for size_t... No.
Checking for long long... Yes.
Failed to find a pointer-size integer type.
** ./configure aborting.```
The **configure.log** says, among other things:
```pgcc -c -O3 x86_64 ztest212261.c
ztest212261.c:
"/usr/include/stdio.h", line 183: error: attribute "__malloc__" does not take arguments
__attribute_malloc__ __attr_dealloc_fclose __wur;
Can someone give me a hint on this?
Thank you in advance.
In order to compile netcdf-c and their dependencies, you need to not only link the include path but also lib path. So you need to do something like
export C_INCLUDE_PATH=/the/path/to/include/:$C_INCLUDE_PATH
export LD_LIBRARY_PATH=/the/path/to/lib/:$LD_LIBRARY_PATH
export PATH=/the/path/to/compilers/bin/:$PATH
And for the configuration, you also need to set CFLAGS and such.
Related
I have been using clang-3.5 to happily build bitcode versions of musl libc and
use the result to produce nice stand alone executables.
Recent attempts with clang-3.8 have not been so happy. It seems that
the bitcode clang-3.8 generates uses functions defined in
compiler-rt/lib/builtins
Typical examples of functions I find polluting the bitcode are mulxc3, mulsc3, and muldc3. I can solve this by linking against libgcc, or even the llvm alternative if I had any clear idea of what that was. Though I would rather prevent the problem from happening in the first place.
I have seen mention of flags like rtlib=compiler-rt etc, but have found precious little documentation on the subject.
So here are some simple questions.
Is it possible to prevent clang from using the compiler-rt/lib/builtins
in the emitted bitcode? Or if not
Does llvm produce a version of libgcc that I could use. Actually I would
probably build a bitcode version of it, but that is besides the point.
Love to hear some guidance on this.
Added 12/8/2016: So I will illustrate my issues with a particular workflow that
people can reproduce if they wish, or, more likely, just point out where I am being stupid.
So start by checking out:
musllv
and follow the instructions in the README.to compile (here I am using clang-3.8 on ubuntu 14.04)
WLLVM_CONFIGURE_ONLY=1 CC=wllvm ./configure --target=LLVM --build=LLVM
make
cd lib
extract-bc -b libc.a
you will also need the bitcode of a simple executable. I will use nweb.c here.
wllvm nweb.c -o nweb
extract-bc nweb
Now we can do things like:
clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
This workflow goes smoothly for clang-3.5 but for clang-3.8 we get:
clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
/tmp/libc-f734a3.o: In function `cpowl':
libc.a.bc:(.text+0xbb9a): undefined reference to `__mulxc3'
/tmp/libc-f734a3.o: In function `cpowf':
libc.a.bc:(.text+0x38f7d): undefined reference to `__mulsc3'
/tmp/libc-f734a3.o: In function `csqrt':
libc.a.bc:(.text+0x78fc3): undefined reference to `__muldc3'
/tmp/libc-f734a3.o: In function `cpow':
libc.a.bc:(.text+0xafafc): undefined reference to `__muldc3'
clang-3.8: error: linker command failed with exit code 1 (use -v to seeinvocation)
So as #paul-brannan points out we could try
clang -static -nostdlib --rtlib=compiler-rt nweb.bc libc.a.bc crt1.o libc.a -o nweb
But this is where I am probably being stupid, because I get:
clang-3.8: warning: argument unused during compilation: '--rtlib=compiler-rt'
irregardless of whether I use it as a linking or compiling flag.
OK so I finally managed to make headway on this. I built llvm-3.8.1 together with the compiler-rt project using wllvm and wllvm++.
One of the build products was libclang_rt.builtins-x86_64.a,
and from this archive I was able to extract the bitcode module
libclang_rt.builtins-x86_64.bc
using the command:
extract-bc -b libclang_rt.builtins-x86_64.a
This bitcode module has definitions for those pesky instrinsics like
__mulxc3, __mulsc3, and __muldc3.
Hallelujah!
I have been trying to enable the gold linker on FreeBSD to use the link time optimizations. I made gold from the binutils under /usr/ports. After building binutils using make -k install clean i got ld under /usr/bin and in the directory /usr/local/bin i got ld, ld.gold and ld.bfd.
Now while trying to use link time optimization for the simple example programs here http://llvm.org/docs/GoldPlugin.html (a.c and b.c under the heading 'Examples of Link Time Optimization') i entered the four commands as follows:
clang -flto a.c -c -o a.o
ar q a.a a.o
clang b.c -c -o b.o
clang -flto a.a b.o -o main
I got the following error:
usr/bin/ld: unrecogonized option '-plugin'
usr/bin/ld: use the --help option for usage information
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Is there the problem with the linker that ld.gold is not being called. Should I replace the ld with ld.gold? Does the linker looks in the right directiry for the .so plugins?
The LLVMgold.so and libLTO.so shared objects are in the directory /usr/local/llvm-devel/lib/.
I cannot find the directory where clang is installed. I am not sure where to make the bfd-plugins directory and add the symlinks to LLVMgold.so and libLTO.so.
I am using freebsd 10.1 release. How to enable the gold linker for link time optimizations?
also how can I enable it to be the default linker?
You may want to use ld.gold instead of ld. It is installed at /usr/local/bin/ld.gold. If you are using a Makefile, it would work by setting LD variable to ld.gold, either by modifying your Makefile or specifying it on command line. Example in case you are using lang/clang37:
gmake all CC=clang37 LD=ld.gold
EDIT:
It would be even more neat if you add -fuse-ld=gold to your LDFLAGS:
LDFLAGS=-fuse-ld=gold
I'm not sure ld.bfd allows plugins, but I could be wrong.
Your /usr/bin/ld should be a symlink to whatever linker you want. You can change which linker is used by using binutils-config. Check the man-page here: http://www.linuxhowtos.org/manpages/8/binutils-config.htm. I realise this is a Linux link, but it's directed at binutils itself rather than linux-specifically.
It should be something along the lines binutils-config --gold.
On my Gentoo box it is binutils --linker=gold
EDIT: As pointed out, binutils-config doesn't work on BSD it seems. You can still manually update the symlinks though, the downside is that there might be a few of them.
You can find out which ld is used by your compiler by using gcc -print-prog-name=ld or clang -print-prog-name=ld. The file printed should be a symlink you can re-create to point to ld.gold as oposed to ld.bfd.
I'm currently changing one of my projects to cmake for portably. Within the project directory I have a folder with an external library called "boclib", which is build by a regular makefile. I need to link my executable to "ProjectDir"/boclib/bin/libboc.a . My current attempt looks like this:
FIND_LIBRARY(BOCLIB boc ${PROJECT_BINARY_DIR}/boclib/bin)
Message(${BOCLIB})
TARGET_LINK_LIBRARIES(prod ${BOCLIB})
The Meassage output yields the correct library:
"AbsulutePathToProjectDir"/boclib/bin/libboc.a
Which outputs this, when linking:
g++ -lm -ldl CMakeFiles/prod.dir/src/BocData.cpp.o CMakeFiles/prod.dir/src/delay.cpp.o CMakeFiles/prod.dir/src/leoni.cpp.o CMakeFiles/prod.dir/src/main.cpp.o CMakeFiles/prod.dir/src/scope.cpp.o CMakeFiles/prod.dir/src/SerialCom.cpp.o CMakeFiles/prod.dir/src/tester.cpp.o CMakeFiles/prod.dir/src/Utils.cpp.o -o prod boclib/bin/libboc.a -lboost_program_options -lboost_system -lboost_filesystem -lboost_serialization -lboc
There is no -L option for the boclib.
What am I doing wrong?
Any help will be appreciated.
It seems there's two occurence of "boc" library in the g++ command you pasted, the first: boclib/bin/libboc.a that should comes from your target_link_libraries call and a second one: -lboc that must come from something else in your CMakeLists.txt.
You don't need that second one, if you find why it's added and remove it, it should be ok.
When I try to build Assimp by running build_ios.sh, it tells me:
CMake Error: your C compiler: "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-gcc" was not found. Please set CMAKE_C_COMPILER to a valid compiler path or name.
CMake Error: your CXX compiler: "/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-g++" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
What I need the path to be is:
/Applications/XCode.app/Contents/Developer/Platforms/...
I've tried changing DEVROOT in build_ios.sh and IPHONE_xxxx_TOOLCHAIN.cmake, because that's what CMAKE_C_COMPILER etc seem to get generated from, but it still gives me the same errors.
Option 1:
You can set CMake variables at command line like this:
cmake -D CMAKE_C_COMPILER="/path/to/your/c/compiler/executable" -D CMAKE_CXX_COMPILER "/path/to/your/cpp/compiler/executable" /path/to/directory/containing/CMakeLists.txt
See this to learn how to create a CMake cache entry.
Option 2:
In your shell script build_ios.sh you can set environment variables CC and CXX to point to your C and C++ compiler executable respectively, example:
export CC=/path/to/your/c/compiler/executable
export CXX=/path/to/your/cpp/compiler/executable
cmake /path/to/directory/containing/CMakeLists.txt
Option 3:
Edit the CMakeLists.txt file of "Assimp": Add these lines at the top (must be added before you use project() or enable_language() command)
set(CMAKE_C_COMPILER "/path/to/your/c/compiler/executable")
set(CMAKE_CXX_COMPILER "/path/to/your/cpp/compiler/executable")
See this to learn how to use set command in CMake. Also this is a useful resource for understanding use of some of the common CMake variables.
Here is the relevant entry from the official FAQ: https://gitlab.kitware.com/cmake/community/wikis/FAQ#how-do-i-use-a-different-compiler
The cc and cxx is located inside /Applications/Xcode.app. This should find the right paths
export CXX=`xcrun -find c++`
export CC=`xcrun -find cc`
SOLUTIONS
Sometimes the project is created before installing g++. So install g++ first and then recreate your project. This worked for me.
Paste the following line in CMakeCache.txt:
CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/c++
Note the path to g++ depends on OS. I have used my fedora path obtained using which g++
I am trying to configure util-linux to cross compile using arm-none-linux-gnueabi from CodeSourcery. My only problem so far is that it can't find my ncurses library which I compiled.
How can I add a directory to the ld search path? I've tried adding to my LIBRARY_PATH and LD_LIBRARY_PATH variables, but neither does anything. I know that I can add the -L flag to gcc and it will add to the linker path, but is there any way to do this globally, so that I can do it once, and not have to worry about it again?
Here is the output of arm-none-linux-gnueabi-gcc -print-search-dirs | grep libraries | sed 's/:/\n/g':
libraries
=/tools/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.1/
/tools/bin/../lib/gcc/
/tools/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.1/../../../../arm-none-linux-gnueabi/lib/arm-none-linux-gnueabi/4.6.1/
/tools/bin/../lib/gcc/arm-none-linux-gnueabi/4.6.1/../../../../arm-none-linux-gnueabi/lib/
/tools/bin/../arm-none-linux-gnueabi/libc/lib/arm-none-linux-gnueabi/4.6.1/
/tools/bin/../arm-none-linux-gnueabi/libc/lib/
/tools/bin/../arm-none-linux-gnueabi/libc/usr/lib/arm-none-linux-gnueabi/4.6.1/
/tools/bin/../arm-none-linux-gnueabi/libc/usr/lib/
I would like to add /arm/usr/lib and /arm/usr/local/lib to my ld search path.
If you need output from any other commands, just ask!
EDIT: I just found out about the CFLAGS environment variable--do all configure scripts/makefiles honor it?
Thank you!
If the ncurses library you compiled are going to be linked to the ARM binary you are cross-compiling you can not use LD_LIBRARY_PATH! LD_LIBRARY_PATH is only used by the current run-time and is in no way used by the compiler or linker when building your application.
The use of CFLAGS depends on creator of Makefile. CFLAGS are not automatically used even if they are defined as an environment variable. Only tools like the autoconf tools can pick them up from the environment and use them automagically. In the Makefiles find something like:
$(CC) $(CFLAGS) ....
if this fragment exists then the Makefile uses the CFLAGS variable. LDFLAGS is the more appropriate environment variable to use for link-time options.