compiling Suitesparse 4.4.4 with Openblas on linux - c++

I downloaded and compiled Openblas, and now I am trying to compile and link openblas to Suitesparse 4.4.4. After compiling all lib files, I get the following error when the compiler tries to compile umfpack_di_demo.c:
../Lib/libumfpack.a(umf_di_local_search.o): In function `umfdi_local_search':
umf_local_search.c:(.text+0x4c0): undefined reference to `dtrsv_'
umf_local_search.c:(.text+0x634): undefined reference to `dgemv_'
../Lib/libumfpack.a(umf_di_blas3_update.o): In function `umfdi_blas3_update':
umf_blas3_update.c:(.text+0x11d): undefined reference to `dtrsm_'
umf_blas3_update.c:(.text+0x1de): undefined reference to `dgemm_'
umf_blas3_update.c:(.text+0x2ae): undefined reference to `dger_'
which I took to mean that the linking is not proper. But, as directed in SuiteSparse_config.mk, I gave the absolute location of libopenblas.a on my system. Also, I also gcc-nm to see if the symbol dtrsv_ is defined in libopenblas.a, and I got the following output which shows that the symbol is defined in the library:
0000000000000000 T dtrsv_
U dtrsv_NLN
U dtrsv_NLU
U dtrsv_NUN
U dtrsv_NUU
U dtrsv_TLN
U dtrsv_TLU
U dtrsv_TUN
U dtrsv_TUU
U dtrsv_NLN
U dtrsv_NLU
U dtrsv_NUN
U dtrsv_NUU
U dtrsv_TLN
U dtrsv_TLU
U dtrsv_TUN
U dtrsv_TUU
dtrsv_NUU.o:
0000000000000000 T dtrsv_NUU
dtrsv_NUN.o:
0000000000000000 T dtrsv_NUN
dtrsv_NLU.o:
0000000000000000 T dtrsv_NLU
dtrsv_NLN.o:
0000000000000000 T dtrsv_NLN
dtrsv_TUU.o:
0000000000000000 T dtrsv_TUU
dtrsv_TUN.o:
0000000000000000 T dtrsv_TUN
dtrsv_TLU.o:
0000000000000000 T dtrsv_TLU
dtrsv_TLN.o:
0000000000000000 T dtrsv_TLN
U dtrsv_NLU
U dtrsv_NUN
U dtrsv_TLU
U dtrsv_TUN
U dtrsv_NLU
U dtrsv_NUN
U dtrsv_TLU
U dtrsv_TUN
U dtrsv_
U dtrsv_
U dtrsv_
I am not sure whats going wrong here. Should I include lapack with openblas in the suitesparse_config.mk file? Any help is appreciated. Thanks.
Note: if it helps, I used gcc 4.4.7 for all compilation and my system details are:
Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux
== EDIT 1: the steps i followed ==
For Openblas:
Downloaded openblas from
http://github.com/xianyi/OpenBLAS/zipball/v0.2.14.
Unzipped and compiled it on my system using gcc-4.4.7 and the following command
make FC=/usr/bin/lgfortran-4.4
I had to provide 'FC' as my system is not having libgfortran.* present in /usr/lib/.
After compilation is done, I type
make install
to install to a custom directory in my home folder.
For suitesparse:
Downloaded suitesparse from http://faculty.cse.tamu.edu/davis/SuiteSparse/SuiteSparse-4.4.4.tar.gz
Unzipped it, and edited the suitsparse_config.mk file to do the following modifications: A) enabled GPU configuration for CHOLMOD and SPQR, B) Not using metis, so commented "METIS_PATH = ../../metis-4.0" and "METIS = ../../metis-4.0/libmetis.a". Also, uncommitted "CHOLMOD_CONFIG = -DNPARTITION". C) gave path to custom installation of openblas: BLAS = -L//OpenBLAS/local/lib/libopenblas.a -lpthread -L/usr/lib/gcc/x86_64-linux-gnu/4.4.7/libgfortran.so
type make in srcdir.

Related

Where is the source code for `cout` defined? [duplicate]

When I try to see definition of cout, I land to iostream file where it is declared as,
extern _CRTDATA2 ostream cout;
So where it is defined? Because extern is just declaration and not definition.
Global symbols are defined in a run-time library that you link with your applications. For example, in gcc you pass the compiler option -lstdc++ that will link your application with the libstdc++.a library. That is where all such symbols reside.
Though, this is specific to your compiler/run-time library version and will vary. Microsoft Visual C++ may behave differently but the idea is the same: the symbols are inside the precompiled libraries that are delivered with your C++ compiler.
With GNU you can type:
nm -g libstdc++.a
to see the symbols inside the library. The output may look like this (among lots of other lines):
ios_init.o:
U _ZSt3cin
globals_io.o:
0000000000000000 D _ZSt3cin
0000000000000000 D _ZSt4cerr
0000000000000000 D _ZSt4clog
0000000000000000 D _ZSt4cout
0000000000000000 D _ZSt4wcin
0000000000000000 D _ZSt5wcerr
0000000000000000 D _ZSt5wclog
0000000000000000 D _ZSt5wcout

Extract and link a 64bit gnu c++ lib from a 64bit mscv++ lib

I have built SpiderMonkey on Windows. They provide MSVC++ toolchain and I couldn't build it for mingw. I've built it for 64bit.
It is a DLL, I need to convert its lib to gnu C++ format (.lib to .a).
After looking on the web, I've found here how to do this, roughly:
gendef mozjs-45.dll
dlltool --as-flags=--64 -m i386:x86-64 -k --output-lib mozjs-45.a --input-def mozjs-45.def
I use TDM-GCC-64 under Code::Blocks. At link time it throws errors like:
undefined reference to `__imp__Z13JS_GetPrivateP8JSObject'
I have checked the lib content using:
nm libmozjs-45.a > libmozjs-45.nm
I see there are the same entries as in the def file exported, but that looks different than linker expects (I presume):
?JS_GetPrivate##YAPEAXPEAVJSObject###Z
Edit 1
I have managed to build SpiderMonkey with mingw-w64. Now, at linking time I get the following error:
undefined reference to `__imp__ZN17JSAutoCompartmentC1EP9JSContextP8JSObject'
Looking with nm at the lib, I have:
d000536.o:
0000000000000000 i .idata$4
0000000000000000 i .idata$5
0000000000000000 i .idata$6
0000000000000000 i .idata$7
0000000000000000 t .text
0000000000000000 I __imp__ZN17JSAutoCompartmentC1EP9JSContextP8JSObjectON7mozilla6detail19GuardObjectNotifierE
U _head_mozjs_45_dll
0000000000000000 T _ZN17JSAutoCompartmentC1EP9JSContextP8JSObjectON7mozilla6detail19GuardObjectNotifierE
Indeed, the definition of the class is:
class MOZ_RAII JS_PUBLIC_API(JSAutoCompartment)
{
JSContext* cx_;
JSCompartment* oldCompartment_;
public:
JSAutoCompartment(JSContext* cx, JSObject* target
MOZ_GUARD_OBJECT_NOTIFIER_PARAM);
JSAutoCompartment(JSContext* cx, JSScript* target
MOZ_GUARD_OBJECT_NOTIFIER_PARAM);
~JSAutoCompartment();
MOZ_DECL_USE_GUARD_OBJECT_NOTIFIER
};
Why the same compiler exports this as __imp__ZN17JSAutoCompartmentC1EP9JSContextP8JSObjectON7mozilla6detail19GuardObjectNotifierE, but, when referencing it, expects it as __imp__ZN17JSAutoCompartmentC1EP9JSContextP8JSObject?
Answer: missed a symbol definition that exclude MOZ_GUARD_OBJECT_NOTIFIER_PARAM from build.

building the ta-lib library fails with undefined references from libm.so

Trying to make the ta-lib library (ta-lib-0.4.0-src.tar.gz) I get the following error:
/home/me/ta-lib/src/.libs/libta_lib.so: undefined reference to `sinh'
/home/me/ta-lib/src/.libs/libta_lib.so: undefined reference to `sincos'
/home/me/ta-lib/src/.libs/libta_lib.so: undefined reference to `ceil'
...
for a large number of maths functions.
The failing command looks like this:
gcc -g -O2 -o .libs/ta_regtest (... .o files) -L/home/me/ta-lib/src \
/home/me/ta-lib/src/.libs/libta_lib.so -lm -lpthread -ldl
The offending library (ta_lib) looks like this:
objdump -TC libta_lib.so | grep " D \*UND\*"
0000000000000000 D *UND* 0000000000000000 sinh
0000000000000000 D *UND* 0000000000000000 sincos
0000000000000000 D *UND* 0000000000000000 ceil
...
For the same maths functions (the grep excludes defined functions and those that have a "w" (presumably weak) flag)
A map lists the libraries included, among them:
LOAD /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libm.so
and a list of the symbols (objdump -TC) defined in libm.so includes:
000000000001a320 w iD .text 0000000000000020 GLIBC_2.2.5 ceil
which was one of the undefined references (they are all there). I cannot determine the meaning of GLIBC_2.2.5.
Why is the loader not finding these functions?
My system looks like this:
$ uname -a
Linux mynode 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Gcc - Undefined reference but library contains matching symbol

i have tried to link a programm of mine with the libmodbus opensource lib. After some trouble with automake, i finally managed to compile it.
But now I get a undefined reference error from gcc, when I use one of the functions the library provides in my own programm:
main.cpp:(.text+0x21): undefined reference to `modbus_udp_init(char*, int, __modbus_udp_handle*)'
collect2: Fehler: ld gab 1 als Ende-Status zurück
From my point of view, the arguments of gcc to compile my project are correct:
g++ -v -I ../libmodbus/modbus -o main main.cpp -L../libmodbus/modbus/.libs/ -lmodbus
I checked with nm if the function is really in that library, but everything looks fine for me (I have deleted some parts from the output, to prevent the output from getting too big):
$ nm ../libmodbus/modbus/.libs/libmodbus.a
modbus.o:
0000000000000590 T crc16
U free
U malloc
U memcpy
0000000000000b40 T modbus_diagnostics
0000000000000d90 T modbus_error_get_exception_code
0000000000000100 C modbus_error_str
0000000000000cf0 T modbus_exception
[...]
modbus-udp.o:
U bcopy
U close
U __errno_location
U gethostbyname
U modbus_error_str
U modbus_tcp_frame_pack
U modbus_tcp_frame_parse
0000000000000000 T modbus_udp_close
0000000000000030 T modbus_udp_init
0000000000000220 T modbus_udp_recv
0000000000000190 T modbus_udp_send
0000000000000010 r __PRETTY_FUNCTION__.4582
0000000000000000 r __PRETTY_FUNCTION__.4592
U recvfrom
U sendto
U setsockopt
U snprintf
U socket
U strerror
modbus-tcp.o:
[...]
modbus-serial.o:
[...]
Does someone have an idea why gcc can't resolve the symbol?
As noloader suggested, i missed adding extern "C" as libmodbus is a C-library. I edited my source:
extern "C" {
#include <modbus.h>
#include <modbus-udp.h>
}
Now it compiles fine. Thank you!

cout is declared in iostream, but where it is defined?

When I try to see definition of cout, I land to iostream file where it is declared as,
extern _CRTDATA2 ostream cout;
So where it is defined? Because extern is just declaration and not definition.
Global symbols are defined in a run-time library that you link with your applications. For example, in gcc you pass the compiler option -lstdc++ that will link your application with the libstdc++.a library. That is where all such symbols reside.
Though, this is specific to your compiler/run-time library version and will vary. Microsoft Visual C++ may behave differently but the idea is the same: the symbols are inside the precompiled libraries that are delivered with your C++ compiler.
With GNU you can type:
nm -g libstdc++.a
to see the symbols inside the library. The output may look like this (among lots of other lines):
ios_init.o:
U _ZSt3cin
globals_io.o:
0000000000000000 D _ZSt3cin
0000000000000000 D _ZSt4cerr
0000000000000000 D _ZSt4clog
0000000000000000 D _ZSt4cout
0000000000000000 D _ZSt4wcin
0000000000000000 D _ZSt5wcerr
0000000000000000 D _ZSt5wclog
0000000000000000 D _ZSt5wcout