I'd like to learn how to use lapack together with C/C++ code in Windows. I am a C/C++ programming newbie, so I know how to code in C, how to organize the code in h/c files, and how to compile them with gcc under cygwin / MinWG / VS. What I'm totally new to is the use of external libraries, such as lapack.
To learn how to use it with Cygwin (64bit), I followed the procedure indicated here
(http://matrixprogramming.rudnyi.ru/2011/04/using-lapack-from-c/)
which seemed to be successful and created the built version of lapack in the folder $HOME\lapack-3.3.0
Now I want to re-run this example: main.cc
What I did was to try to compile it by calling
$ g++ -O3 main.cc -L$HOME/lapack-3.3.0 -llapack -lblas -lgfortran -I ./include -o main
and what I get is
main.cc: In function ‘int main(int, char**)’:
main.cc:39:23: error: ‘dgetf2’ was not declared in this scope
info = dgetf2(A, ipvt);
^
main.cc:45:23: error: ‘dgetrf’ was not declared in this scope
info = dgetrf(A, ipvt);
^
main.cc:55:26: error: ‘dgetrs’ was not declared in this scope
info = dgetrs(A, B, ipvt);
^
where the "include" folder only contains the
Matrix.h
matrix class required in main.cc
To me it seems that some header files are missing. What I do not understand is how this is possible if the building process of the libraries was successful. Do I have to give further "-I options"? I looked for "dgetf2", "dgetrf" and "dgetrs" in the lapack-3.3.0 folder, so I found the object files in $HOME\lapack-3.3.0\SRC but if I include them as well as
$ g++ -O3 main.cc -L$HOME/lapack-3.3.0 -llapack -lblas -lgfortran -I ./include -I $HOME/lapack-3.3.0/SRC -o main
I get exactly the same error which makes somehow sense as they are object files and not header files. What am I doing wrong? How does one manage declarations of functions implemented in external libraries?
Thanks!
Related
Good Day Everyone,
N.B - This problem has been solved - I have provided my own solution in the answer section however the solution provided by Jonathan is much shorter. Nevertheless, this was the following question I originally posted:
I am basically trying to compile a serial library (for UART communication) on Linux however I am not really sure how to correctly compile (I have mentioned what I have done so far below), any suggestions would be highly valuable. I am using the serialib library - which is composed of 2 main files (serialib.h and serialib.cpp) , you may directly view the source code of these files here (scroll all the way to the bottom and view the files in new tabs): http://serialib.free.fr/html/classserialib.html
I transferred these files (serialib.h and serialib.cpp) to my BeagleBone Black micro-controller which is running Debian (Wheezy) , g++/gcc (Debian 4.6.3-14) 4.6.3. I wrote my own program (uart.cpp is my file name) to access the functions provided by this library, this is what I wrote:
#include <iostream>
#include "serialib.h"
#ifdef __linux__
#define DEVICE_PORT "/dev/ttyO1"
#endif
int main()
{
serialib LS;
return 0;
}
So as you can see I am trying to access the 'seriallib' class. serialib.h, serialib.cpp and uart.cpp are all in the home directory. I also manually added the iostream library in serialib.cpp as I did not see it being declared in the original source code.
Now I am really unsure of how to compile such external libraries but so far I tried the following steps:
g++ -c -Wall -Werror -fPIC serialib.c to convert to PIC which gives the following error:
distcc[3142] (dcc_parse_hosts) Warning: /home/debian/.distcc/zeroconf/hosts contained no hosts; can't distribute work
distcc[3142] (dcc_zeroconf_add_hosts) CRITICAL! failed to parse host file.
distcc[3142] (dcc_build_somewhere) Warning: failed to distribute, running locally instead
g++ serialib.cpp -L /home/debian/serialib.h which gives the following error:
/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crt1.o: In function _start':
(.text+0x30): undefined reference tomain'
collect2: ld returned 1 exit status
distcc[3210] ERROR: compile serialib.cpp on localhost failed
As of now I am still finding out how to compile this and if I manage to work this out then I'll post my solution here too. Once again any suggestion will be highly valuable. Thank you all :) .
g++ -c -Wall -Werror -fPIC serialib.c to convert to PIC which gives the following error:
The "error" is not an error, it's a warning, telling you that your distcc setup is broken, but that it compiled locally.
That command doesn't "convert to PIC", it compiles the file serialib.c and produces a compiled object file, serialib.o
g++ serialib.cpp -L /home/debian/serialib.h
This is just nonsense. It tries to build a program from serialib.cpp and use the directory /home/debian/serialib.h (which isn't a directory!) to find libraries.
You don't need to "compile a library" you can just compile both the source files and link them together into a program. Either:
g++ -c serialib.cpp
g++ -c uart.cpp
g++ serialib.o uart.o -o uart
Or all in one command:
g++ serialib.cpp uart.cpp -o uart
You should read An Introduction to GCC to understand the commands, not just enter bogus commands without understanding them.
I have found a solution to this problem, hope this helps for all the future readers with similar problems. I have my own source code uart.cpp (Given in the question) which I want to compile, the external library is serialib that contains two main files (serialib.h and serialib.cpp), you will want to replace the following commands with respect to the files you have
Step 1: Compiling with position independent code
g++ -c -Wall -Werror -fpic serialib.cpp
Step 2: Creating a shared library
g++ -shared -o libserialib.so serialib.o , here the library is libserialib.so.
Step 3: Linking your source code with library
g++ -L /home/debian -lserialib uart.cpp -o uart
g++ -L /home/debian -Wall -o test uart.cpp -lserialib
You may save the library at a different path and you may have a different name of course. Suppose you have a library called libabc.so at the directory /home/user/myDir then the commands will be like:
g++ -L /home/user/myDir -labc your_code.cpp -o your_code
g++ -L /home/user/myDir -Wall -o test your_code.cpp -labc
test is out own program, lserialib is actually looking for libserialib.so and not serialib.o as gcc/g++ assumes all libraries start with lib and end with .so or .a and you can see the same goes for labc as it will look for libabc.so thus it is important to make sure your library name begins with lib and ends with .so or .a
Step 4: Making library available at run time
Here we provide the path where the library is actually stored, I saved it in the directory /home/debian which is why my command looks like:
export LD_LIBRARY_PATH=/home/debian:$LD_LIBRARY_PATH
if your library is saved at /path/to/file then the command will look like:
export LD_LIBRARY_PATH=/path/to/file:$LD_LIBRARY_PATH
This is to help the loader find the shared library and to view this path: echo $LD_LIBRARY_PATH and to unset this: unset LD_LIBRARY_PATH
To execute the program type either ./test or ./uart and in case of any modification to the main source code (uart.cpp in this case) , simply repeat step 3. I found the following link very useful: http://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html . Thank you to all of you who took time to read this question and especially those who gave me suggestions. If anyone has more or better solutions, feel free to post them here to assist future readers :).
I have written a few programs and while trying to compile them using g++,as thus,
$ g++ minIni.c device_datum.cpp fanuc_axis.cpp fanuc_path.cpp service.cpp condition.cpp cutting_tool.cpp string_buffer.cpp logger.cpp client.cpp server.cpp adapter.cpp fanuc_adapter.cpp FanucAdapter.cpp -L/usr/local/lib/ -lfwlib32 -lpthread -o adapter
I keep getting the following error:
/usr/bin/ld: cannot find -lfwlib32
collect2: error: ld returned 1 exit status
fwlib32.h is the library I am trying to include. The shared object file libfwlib32.so is present in /usr/local/lib as well as /usr/lib. But I am unable link to it. I have tried all the solutions offered by similar questions including
$ export LIBRARY_PATH=/usr/local/lib/
$ export LD_LIBRARY_PATH=/usr/local/lib
I have done the above for /usr/lib as well, but still the same error.
I have tried using the -L option in the command line but I still get the error.
I even created a new folder called lib, pasted libfwlib32.so.1.0.1 into it and ran
$ ln -s ~/lib/libfwlib32.so.1.0.1 ~/lib/libfwlib32.so
on the console to create a new .so file and gave ~/lib as argument to -L option on the command line. It made no difference. I am at the point of tearing my hair out so any help will be appreciated.
Thanks alot!
You should put -l option in the very last as:
$ g++ minIni.c device_datum.cpp fanuc_axis.cpp fanuc_path.cpp service.cpp condition.cpp cutting_tool.cpp string_buffer.cpp logger.cpp client.cpp server.cpp adapter.cpp fanuc_adapter.cpp FanucAdapter.cpp -L/usr/local/lib/ -o adapter -lfwlib32 -lpthread
Note: Please make sure that all the header and source file are in the same folder.
Note that specifying -L~/lib won't work as the ~ will not be expanded by the shell. Also you can't add a space between -L and ~/lib. Instead you must specify it as a relative or absolute path.
Have you checked that the libfwlib32.so symlink exists in /usr/local/lib (or /usr/lib) in addition to the libfwlib32.so.1.0.1 file?
Another possibility is that the library is the wrong architecture (ie. 32-bit while your system is 64-bit), but then ld should print a message about skipping incompatible library. You can check the architecture of the library by running 'file libfwlib32.so.1.0.1'.
The error message suggests that -lfwlib32 is being interpreted as a filename not as a -l parameter. Put all the parameters before the files to be compiled
g++ -m32 -L/usr/local/lib/ -lfwlib32 -lpthread -o adapter minIni.c device_datum.cpp fanuc_axis.cpp fanuc_path.cpp service.cpp condition.cpp cutting_tool.cpp string_buffer.cpp logger.cpp client.cpp server.cpp adapter.cpp fanuc_adapter.cpp FanucAdapter.cpp
As has been pointed out by #Erik Johannessen, libfwlib32.so is a 32bit library, so you need to add -m32 to build a 32bit executable.
I am trying to do a "clean" build of a c++ program on my mac. By clean, I mean, do not include anything that I do not explicitly specify.
My gcc installation is located at:
/Applications/gcc471/
So far, I can compile using
-nostdinc++
by including
GPP-INCLUDES += -I/Applications/gcc471/include/c++/4.7.1/
GPP-INCLUDES += -I/Applications/gcc471/include/c++/4.7.1/x86_64-apple-darwin12.0.0
and doing
g++ -c *.cpp $(GPP-INCLUDES) -nostdinc++
I am pretty happy with that. However, I am trying to make the leap into compiling with
-nostdinc
And it seems that, no matter how many paths I include like
/usr/local/include
/usr/include
....
I get a crapton of errors like this:
/Applications/gcc471/include/c++/4.7.1/tr1/cmath: At global scope:
/Applications/gcc471/include/c++/4.7.1/tr1/cmath:156:11: error: ‘::double_t’ has not been declared
/Applications/gcc471/include/c++/4.7.1/tr1/cmath:157:11: error: ‘::float_t’ has not been declared
/Applications/gcc471/include/c++/4.7.1/tr1/cmath:160:11: error: ‘::acosh’ has not been declared
...
Does anyone know how to completely build a cpp program from scratch on the mac using -nostdinc?
I was able to compile using -nostdinc, but not without -I/usr/include/ as I had hoped. I do not trust Xcodes llvm/clang/gcc4.2 (Really old)/not real GCC nonsense. So I downloaded GCC from scratch and built it from source using the guide here: http://staticimport.blogspot.ca/2012/02/building-gcc-462-on-os-x-lion.html
The problem is that libstdc does not appear to ship with gcc anymore, only libstdc++. So all .hpp files are in my GCC directory, but really old headers, such as locale.h (From 1993), only appears to come with the libstdc XCode installs to /usr/include. I will keep looking for a vanilla libstdc to install, but for now, these are the most minimal and most "GNU" directories I can include to compile:
...
#FOR -nostdinc++
GPP-INCLUDES += -I/Applications/gcc471/include/c++/4.7.1/
GPP-INCLUDES += -I/Applications/gcc471/include/c++/4.7.1/x86_64-apple-darwin12.0.0
#for -nostdinc
GPP-INCLUDES += -I/Applications/gcc471/lib/gcc/x86_64-apple-darwin12.0.0/4.7.1/include/
GPP-INCLUDES += -I/usr/local/include
GPP-INCLUDES += -I/usr/include/ #bahhhhh cant get away
g++ -c *.cpp $(GPP-INCLUDES) -nostdinc++ -nostdinc -std=c++11
I recently cross compiled Boost library for PowerPC and generated the thread and system library. Then to test the library on my target, tried one of the sample code in Boost library and tried to build the binary using the previously built boost library but got the below compilation errors
.
.
GNU C++ version 4.2.2 (powerpc-linux)
compiled by GNU C version 2.96 20000731 (Red Hat Linux 7.3 2.96-113).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128176
Compiler executable checksum: dd5a9a41381fa3b9978b2738b80f5a75
In file included from /shared/deps/powerpc/include/boost/config/platform/linux.hpp:15,
from /shared/deps/powerpc/include/boost/config.hpp:53,
from /shared/deps/powerpc/include/boost/thread/detail/platform.hpp:14,
from /shared/deps/powerpc/include/boost/thread/thread.hpp:12,
from helloworld.cpp:7:
4.2.2/cstdlib:106: error: '::div_t' has not been declared
4.2.2/cstdlib:107: error: '::ldiv_t' has not been declared
4.2.2/cstdlib:109: error: '::abort' has not been declared
4.2.2/cstdlib:110: error: '::abs' has not been declared
4.2.2/cstdlib:111: error: '::atexit' has not been declared
4.2.2/cstdlib:112: error: '::atof' has not been declared
4.2.2/cstdlib:113: error: '::atoi' has not been declared
.
.
Below is the sample program given with Boost library
#include <boost/thread/thread.hpp>
#include <iostream>
void helloworld()
{
std::cout << "Hello World!" << std::endl;
}
int main()
{
boost::thread thrd(&helloworld);
thrd.join();
}
Make file:
CC=ppc_4xx-gcc
CPP=ppc_4xx-g++
CFLAGS=-c -g -Wall -static -v
LDFLAGS_TARGET=-$(LDFLAGS_PowerPC)
LIBS_TARGET=$(LIBS_PowerPC)
CPPFLAGS=$(CPPFLAGS_COMMON) $(CPPFLAGS_PowerPC)
INCLUDES=-I/opt/ELDK/4.2/ppc_4xx/usr/include/ -I. -I/opt/ELDK/4.2/ppc_4xx/usr/src/u-boot-1.3.1/board/xilinx/common/ -I/opt/ELDK/4.2/ppc_4xx/usr/src/linux-2.6.24/arch/powerpc/boot/ -I4.2.2/
DEPSROOT=/shared/deps
COMMON_INCLUDES = $(DEPSROOT)/common/include
PowerPC_INCLUDES=$(DEPSROOT)/powerpc/include
CPPFLAGS_PowerPC=-I$(PowerPC_INCLUDES)
CPPFLAGS_COMMON = -I$(COMMON_INCLUDES)
PowerPC_LIBS=$(DEPSROOT)/powerpc/lib
LDFLAGS_PowerPC=-L$(PowerPC_LIBS)
LIBS_PowerPC=-lboost_thread -lboost_system
all: helloworld
helloworld: helloworld.o
$(CPP) -g helloWorld.o -o helloworld -static
helloworld.o: helloworld.cpp
$(CPP) $(CFLAGS) $(CPPFLAGS) $(INCLUDES) $(MODS) helloworld.cpp
clean:
rm -rf *.o helloWorld
The error is in the file cstdlib in the below location
.
.
_GLIBCXX_BEGIN_NAMESPACE(std)
using ::div_t;
using ::ldiv_t;
using ::abort;
.
.
The macro _GLIBCXX_BEGIN_NAMESPACE is setting the namespace as std with certain visibility. I am new to this so couldn't follow it completely.
Has anyone faced similar problem ? I read in some posts that the namespace is missing causing this error but I am not sure if that's the issue in my case.
EDIT
I got more information on the problem. First I thought the problem was with the namespace, so I manually changed the namespace to std but it didn't help. Then I added the definition of the structure div_t just before the statement using ::div_t; and one of the errors decreased (i.e the statement was compiled). So the problem was with the missing definition of div_t structure.
Now the structure div_t is defined in the file stdlib.h which is included in the current file cstdlib. When I did a locate on the file name stdlib.h, I found the below references
/opt/ELDK/4.2/ppc_4xx/usr/include/stdlib.h
/opt/ELDK/4.2/ppc_4xx/usr/include/bits/stdlib.h
/opt/ELDK/4.2/ppc_4xx/usr/include/c++/4.2.2/tr1/stdlib.h
/opt/ELDK/4.2/ppc_4xx/usr/include/freetype2/freetype/config/ftstdlib.h
/opt/ELDK/4.2/ppc_4xx/usr/src/linux-2.6.24/arch/powerpc/boot/stdlib.h
/opt/ELDK/4.2/ppc_4xx/usr/src/linux-2.6.24-xenomai/arch/powerpc/boot/stdlib.h
Only the first file has the definition of div_t and not the others. The file under discussion cstdlib is in the folder ../include/c++/4.2.2/, now if the file stdlib.h is included here which one of the multiple stdlib.h is included ? The location /opt/ELDK/4.2/ppc_4xx/usr/include is present in my include path.
BTW how do I know which file is being included ?
The problem was the same as Cross Compile Boost library for PowerPC architecture. The include path which had the definition of dev_t was omitted and the next include path was used. Unfortunately it also had a file stdlib.h which didn't have the definition of dev_t structure. I created soft links and made sure the compiler picked up the correct stdlib.h file.
On OSX 10.6.4 with i686-apple-darwin10-g++-4.2.1 compiling using TextMate and a Makefile which in the first place has been made für a Linux and I am trying to translate for OSX.
When compiling a c++ project I get the "can't link with a main executable" error:
g++ -Wall -g -I ~/svnX-Repository/axp-Projekte/xrlfupa/trunk/src/ -I ~/svnX-Repository/boost_1_44_0 -I /opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -I /opt/local/var/macports/software/gsl/1.14_0/opt/local/include/ -o xrfLibTest xrfLibTest.o excitFunctions.o xrfFunctions.o filterFunctions.o detectorFunctions.o -L/opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -L/opt/local/var/macports/software/gsl/1.14_0/opt/local/lib/ -lm -lxrlTUB -lboost_serialization -lgsl -lgslcblas # Debug 1
ld: in /usr/local/lib/libxrlTUB.so, can't link with a main executable
collect2: ld returned 1 exit status
make: *** [prog] Error 1
The library that is mentioned (libxrlTUB.so) is in its place (/usr/local/lib/libxrlTUB.so) but, possibly that is where the problem came from, the libxrlTUB.so has been compiled by myself beforehand as well.
The compile process went through, it was generated by swig, though there was a warning:
g++ -arch x86_64 -m32 -g -fpic -I /usr/include/python2.6 -c PyXrl_wrap.cxx
In function 'void SWIG_Python_AddErrorMsg(const char*)':
warning: format not a string literal and no format arguments
which, as far as I could find out, shouldnt be a problem. (Or is it?)
Unfortunately this whole thing is part of a project from the university. Actually I am supposed to write an X-ray-analysis script in python, which would be fine, if... well if I wouldn't be expected to use the librarys that are meant to result from this c++ project.
(Afterwards they should be used via import in python.)
I am not really experienced with c++, neither with compiling on OSX systems. So far I have been bothering with scipting (python, bash, etc). So Maybe I am just missing something simple. Hopefully someone can give me an hint where I can continue reading in order to deal with the above "can't link with a main executable" error...
Thanx in advance,
Liam
The error message is telling you the problem—it is that /usr/local/lib/libxrlTUB.so is not a shared library; it's an executable. You can't link against an executable. Probably whatever build process you used for libxrlTUB.so didn't understand how to build shared libraries on the Mac (it's more suspect because .dylib is the correct extension to use.)
Take a look at Apple's documentation on compiling dynamic libraries. You can use file to make sure your output is of the correct type, for example:
% gcc -c foo.c
% gcc -dynamiclib foo.o -o foo.dylib
% file foo.dylib
foo.dylib: Mach-O 64-bit dynamically linked shared library x86_64
Without -dynamiclib you end up with an executable, which may be the problem you've run into.