Context: I am building some code for an embedded board. It calls for installing the Xilinx tools, the Linaro toolchain and then invoking a setup bash script in the development board build directory (let's call it setup.sh).
If I do not run setup.sh , I can then build one of the lower level libraries, which has it's own configure script (./configure) which calls the usual ./bootstrap script. In this scenario ./bootstrap , g++ in this case says it can find sstream (the C++ stream header). Ok. Fine.
When I run the setup.sh script (at the top level), g++ then says it CANNOT find sstream. So somehow the g++ environment is changed somehow, and it is this I am trying to figure out.
The output in this erroneous case is
g++ has streams in std:: namespace
g++ does not have sstream
g++ does not have strstream.h
g++ does not have strstrea.h
I am trying to debug this to find out what g++ thinks it is doing and why it cannot find the sstream header. What are some ways to look at what the g++ include and libstdc++ library paths are set to? What environment variables control the behavior of gcc/g++?
#
If I remember correctly, Xilinx ships their own gcc toolchain with their products.
Just add the -I compile file to point to the proper includes path.
Try to search for the header files inside Xilinx's /opt path, so you don't have a mismatch between the header version and the library version.
Makefile's usual env variables are:
# C Compiler: GNU C Compiler
CC = gcc
# Linker: GNU Linker
LD = ld
# C++ Compiler: GNU C++ Compiler
CPP = g++
Also check
CFLAGS
CPPFLAGS
LDFLAGS
Check if $CC is set after you execute setup.sh.
Related
I wanted to use latest g++ compiler(4.9.1) on suse linux, but suse only supports an older g++ version. So, I took a latest source code from one of the gnu mirror sites and compiled it myself. Everything went fine. But when I tried to compile my test code using the built g++, the compilation fails with error,
"/root/home/include/c++/4.9.1/x86_64-unknown-linux-gnu/bits/os_defines.h:39:22: fatal error: features.h: No such file or directory".
I can find a "features.h" in "/root/home/include/c++/4.9.1/parallel", but I feel that it should be there in "/root/home/include/c++/4.9.1/" itself.
I copied "/root/home/include/c++/4.9.1/parallel/features.h" to "/root/home/include/c++/4.9.1/" just to see what happens. Now it complains with error "whcar.h" not found.
Have I missed something.
Here are the steps I followed to build g++.
1. /root/home/gcc_build/objdir# ../gcc-4.9.1/configure --prefix=/root/home/ --disable-multilib
2. /root/home/gcc_build/objdir# make -j16
3. /root/home/gcc_build/objdir# make install
4. /root/home/gcc_build/test# /root/home/bin/g++ --sysroot /root/home -m64 test.cpp
I resolved the issue by removing sysroot option and pointing c++ include and library path to my home directory. One thing I noticed was that the g++ source does not come with libc and c header files, and libc has to be installed seperately. But with sysroot option, g++ was trying to look all the header files in my home directory.
Below is the command I used to successfully compile the code.
/root/home/bin/g++ -I /root/home/include/c++/4.9.1 -L /root/home/lib64 -Wl,--rpath=/root/home/lib64 --std=c++0x -m64 test.cpp
Take a look at the GCC Directory Options. It is important to use the correct "specifier" as well (-isystem, -L, -B, -I etc)
I have built and installed a shared library to do some profiling of my projects via code instrumentation, specifically with the -finstrument-functions switch of gcc.
It is possible to turn the instrumentation on and off with the compiler switch, and hence I'd like to be able to turn the dependency to the profiling library on and off just by reconfiguring.
I can pass -finstrument-functions to gcc via configure's CFLAGS, but when I try to pass -lmylib via LDFLAGS configure fails with
configure:2796: checking whether we are cross compiling
configure:2804: gcc -o conftest -g -Wall -Wextra -Werror -lmylib conftest.c >&5
configure:2808: $? = 0
configure:2815: ./conftest
./conftest: error while loading shared libraries: libmylib.so.0: cannot open shared object file: No such file or directory
The file exists, I have double checked and compiling and linking a dummy example works as expected.
Interestingly, when I pass the full path to the shared library instead of -lmylib, the error persists, but when I pass the full path to the corresponding static library, configure runs smoothly, and everything is built as expected.
My question in a nutshell: Is there a possibility to pass optional shared libraries to autotools-generated configure scripts, without changing configure.ac?
Thanks,
Andy
It looks like your library is not in the compiler's default library search path.
You may also pass library search path through LDFLAGS with the -L switch:
CFLAGS=-finstrument-functions LDFLAGS="-lmylib -L/path/to/mylib" ./configure ....
fixed by running sudo ldconfig
I'll leave this here in case someone else has the same problem.
I want to set up LEDA library in my system.
I have downloaded LEDA library from the following link
http://www.algorithmic-solutions.info/free/d5.php
Instruction given in read me file
2. Preparations
---------------
Unpacking the LEDA distribution file
LEDA---.tar.gz will create the LEDA root
directory "LEDA---". You might want to rename
it or move it to some different place. Let denote the final
complete path name of the LEDA root directory.
To install and use the Unix object code of LEDA you have to modify
your environment as follows:
a) LEDAROOT:
Set the environment variable LEDAROOT to the LEDA root directory:
csh/tcsh: setenv LEDAROOT
sh/bash: LEDAROOT=
export LEDAROOT
b) Command Search Path:
Include $LEDAROOT/Manual/cmd into your command search path
(environment variable path (csh) or PATH (sh)) and call rehash (if
required by your system).
c) Shared Library: (for solaris, linux, irix, osf1)
If you planning to use shared libraries include $LEDAROOT into the
LD_LIBRARY_PATH search path. Then go to $LEDAROOT and type
make shared. This will construct the shared libraries from the static
libraries.
Please note: Building the shared library is not supported on each
platform.
d) xlman and demos: Go to $LEDAROOT and type make xlman to compile
and link LEDA's interactive manual reader xlman. Now you can start
xlman for reading and printing manual pages, starting demo programs
and browsing more release notes.
3. Compiling and linking application programs
---------------------------------------------
a) Use the -I compiler flag to tell the compiler where to find the
LEDA header files.
CC (g++) -I$LEDAROOT/incl -c file.c
b) Use the -L compiler flag to tell the compiler where to find the
library (libleda.a/so)
CC (g++) -L$LEDAROOT file.o -lleda -lX11 -lm
If using windows on solaris systems you might have to link
with the system socket library and the network services library as
well:
CC (g++) ... -lleda -lX11 -lsocket -lnsl -lm
c) Compile and link simultaneously with
CC (g++) -I$LEDAROOT/incl -L$LEDAROOT file.c -lleda -lX11 -lm
You may want to ask your system adminstrator to install the header
files and library in the system's default directories.
Then you no longer have to specify header and library search paths on
the compiler command line.
I followed these instruction but I got error in command
> make xlman
error
coredump#coredump-VPCCB15FG:~/Documents/LEDA$ make xlman
make -C demo/xlman
make: *** demo/xlman: No such file or directory. Stop.
make: *** [xlman] Error 2
someone please help me to setup library.
NOTE: For the free version of the Leda library, you don't have to build the package to use the library. It simply doesn't work.
To use the library simply include it in your compile line and linker.
If you are compiling from the shell (assuming you are using Linux), do the following:
1. Set the env variable to the library folder e.g export LEDAROOT= /path/to/Leda
2. Set the LD_LIBRARY_PATH env variable e.g export LD_LIBRARY_PATH=$LEDAROOT
Verify that this variables are set then you can compile and link and run. You can simply do
CC (g++) -I$LEDAROOT/incl -L$LEDAROOT file.c -lleda -lX11 -lm
With this you should be good to go.
If you are using an IDE, simply add the include path (i.e /path/to/leda) to you project settings.
This is all you have to do. Building the library does not work. Simply include it
I am trying to build and link a C++, cmake-based project with clang (3.0). This project links to several libraries that are installed in a custom directory /my/dir/. This directory is included in the LD_LIBRARY_PATH and LIBRARY_PATH environment variables. Project builds and links fine with g++.
The link command generated and executed by cmake looks like the following:
/usr/bin/clang++ -O3 stuff.cpp.o -o stuff -rdynamic -lmylib
ld then complains with the following message:
/usr/bin/ld: cannot find -lmylib
The link command above runs fine whenever I manually add -L/my/dir/. Is there a way to link without specifying the -L flag?
The $LD_LIBRARY_PATH environment variable (and its various alternatives on other UNIX-based platforms) is used at runtime, not link time, to find libraries.
Using -L is the correct approach and cannot be avoided.
Note: A better approach under Linux (you don't specify your platform so I'm guessing) is to correctly configure a file in /etc/ld.so.conf.d/ and avoid using $LD_LIBRARY_PATH altogether.
I'm having trouble building a simple c++ program that tests out regex's from the boost library. The problem that I'm having is occurring in the linking stage and I don't know enough to fix the error on my own.
In the .cpp program that uses regexes I used the following include line.
#include <boost/regex.hpp>
I don't know enough to figure out what command I should use to build the program using g++. I tried using the following command line (and variations of it) to build the program.
g++ -I/usr/include/regex -L/usr/lib -llibboost_regex main.cpp -o regex_test
Other information that might be relevant:
Operating system: Arch linux
g++ version: 4.6.2 20120120 (prerelease)
Any help would be appreciated.
Assume you have installed Boost with the boost and boost-libs packages,
The header <boost/regex.hpp> should exist in /usr/include/boost/regex.hpp. You don't need to use any -I flags since /usr/include should be included by default.
You shouldn't need the -L flag either since /usr/lib should also be included by default when linking.
When using the -l flag to link with a library libfoo.so, the leading "lib" part should be removed.
The command line should therefore be:
g++ main.cpp -o regex_test -lboost_regex