I'm new to c++ rest sdk Casablanca and using it in Codelite ide.
Operating System : Arch Linux
gcc version : 6.1.1
While building the code I get the following error in debug mode:
/bin/sh -c '/usr/bin/make -j4 -e -f Makefile'
----------Building project:[ Casa - Debug ]----------
make[1]: Entering directory '/home/vinci/Documents/CPP_Projects_Programs/Casa'
/usr/bin/g++ -c "/home/vinci/Documents/CPP_Projects_Programs/Casa/main.cpp" -g -O0 -fopenmp -std=c++14 -std=c++11 -Wall -o ./Debug/main.cpp.o -I. -I/usr/local/include/cpprest -I/usr/local/include/pplx -I/home/vinci/casablanca/Release/src -I. -I/usr/local/include/cpprest -I/usr/local/include/pplx
/usr/bin/g++ -o ./Debug/Casa #"Casa.txt" -L. -L/usr/local/lib -L/usr/lib64 -L/usr/lib -lcpprest
/usr/bin/ld: ./Debug/main.cpp.o: undefined reference to symbol '_ZN5boost6system15system_categoryEv'
/usr/lib/libboost_system.so.1.60.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[1]: *** [Casa.mk:79: Debug/Casa] Error 1
make[1]: Leaving directory '/home/vinci/Documents/CPP_Projects_Programs/Casa'
make: *** [Makefile:5: All] Error 2
====1 errors, 0 warnings, total time: 00:00:14 seconds====
I searched this on Stackoverflow before asking and most of the answers just pointed to linking the libraries properly in project settings and I have done that as one can see in the code above but still keeps giving the error and I don't know what am i missing??
A little Help would be appreciated...
Thank You
/usr/lib/libboost_system.so.1.60.0: error adding symbols: DSO missing from command line
This DSO error means that libboost_system is missing from the command line.
You should also add:
-lboost_system
to your command line just like -lcpprest
This can happen if you reference libraries in the wrong order. I have a personal library that depends on -lboost_system, but I had listed my own library after the boost library and was getting this error. I moved my personal library to the front of the list, and the error went away.
Related
I'm trying to upgrade xml-security-c-2.0.2. I extracted the tar file on my linux environment. I exported the following xerces environment variables below before the ./configure command:
Env variables:
export xerces_LIBS=/opt/shibboleth-sp/lib
export xerces_CFLAGS=/opt/shibboleth-sp/include
configure command:
./configure --without-xalan --disable-static --prefix=/opt/shibboleth-sp
Once I run make, I get the following error:
make[2]: Entering directory `/opt/build/xml-security-c-2.0.2/xsec'
g++ -DHAVE_CONFIG_H -I.. -I.. -DXSEC_BUILDING_TOOLS /opt/shibboleth-sp/include -Wall -O2 -DNDEBUG -pthread -MT tools/xtest/xsec_xtest-xtest.o -MD -MP -MF tools/xtest/.deps/xsec_xtest-xtest.Tpo -c -o tools/xtest/xsec_xtest-xtest.o `test -f 'tools/xtest/xtest.cpp' || echo './'`tools/xtest/xtest.cpp
In file included from tools/xtest/xtest.cpp:32:0:
**../xsec/framework/XSECDefs.hpp:63:39: fatal error: xercesc/util/XercesDefs.hpp: No such file or directory
#include <xercesc/util/XercesDefs.hpp>''**'
For whatever reason it cannot find the source file XercesDefs.hpp. This has been an issue for a month or so where we cannot figure out why it isn't finding that source file. When I run a find on this particular file, I get the following path showing it is indeed in multiple locations:
/opt/build/xerces-c-3.2.3/src/xercesc/util/XercesDefs.hpp
/opt/shibboleth-sp/include/xercesc/util/XercesDefs.hpp
Is there something in the compile process that is making this not work or not pick this up? Should I be exporting something else in order to pick up this file?
We currently have version xml-security-c-1.7.3 installed on the machine. Would it be easier to use this version? Is there some sort of bug with 2.0.2 or something that needs to be configured from going from version 1.x to 2.x?
This is all to upgrade shibboleth idp, and installing all the needed dependencies prior to Shibboleth build.
> current OS version Linux version 4.14.214-118.339.amzn1.x86_64
> (gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC)) #1 SMP
Any help is very much appreciated!
EDIT:
I've exported my CXXFLAGS to point at include however I'm still getting the following error when I issue the make command:
make all-recursive
make[1]: Entering directory `/opt/build/xml-security-c-2.0.2'
Making all in xsec
make[2]: Entering directory `/opt/build/xml-security-c-2.0.2/xsec'
/bin/sh ../libtool --tag=CXX --mode=link g++ /opt/shibboleth-sp/include -Wall /opt/shibboleth-sp/include -O2 -DNDEBUG -pthread -o xsec-xtest tools/xtest/xsec_xtest-xtest.o libxml-security-c.la /opt/shibboleth-sp/lib /opt/apache2_4_46/bin
libtool: link: g++ /opt/shibboleth-sp/include -Wall /opt/shibboleth-sp/include -O2 -DNDEBUG -pthread -o .libs/xsec-xtest tools/xtest/xsec_xtest-xtest.o /opt/shibboleth-sp/lib /opt/apache2_4_46/bin ./.libs/libxml-security-c.so -pthread -Wl,-rpath -Wl,/opt/shibboleth-sp/lib
/opt/shibboleth-sp/include: file not recognized: Is a directory
collect2: error: ld returned 1 exit status
make[2]: *** [xsec-xtest] Error 1
make[2]: Leaving directory `/opt/build/xml-security-c-2.0.2/xsec'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/build/xml-security-c-2.0.2'
make: *** [all] Error 2
What is going on with this?
RHEL 7.2 is the year 2015 update. Current is 7.8 (yum update).
XercesDefs.hpp: No such file
xml-security-c-2.0.2 configure will look in /usr/include, /usr/local/include ! When you have a "hide away" location, the INCLUDE path must be specified : See $ ./configure --help
Example : CXXFLAGS=-I/opt/shibboleth-sp/include , I.e. →
$ ./configure --prefix=/opt/shibboleth-sp CXXFLAGS=-I/opt/shibboleth-sp/include
Bugs : There are no bugs in xml-security-c-2.0.2 . Will compile without errors in EL 7 ( 3 minutes, g++73 (or with the default g++ ver. 4.8 )).
Ref your comment »» I need the .tar.gz files «« : Please follow the link https://ftp.gwdg.de/pub/opensuse/repositories/home%3A/Scott_Cantor/CentOS_7/ → src/
Example $ bash unPack_rpm.sh xml-security-c-2.0.2-4.2.src.rpm and you get xml-security-c-2.0.2-4.2.src/{xml-security-c-2.0.2.tar.bz2 , xml-security-c.spec}
Script unPack_rpm.sh https://drive.google.com/file/d/1q3d9QqrRhEThYByPDgWEaoxHnqWFWqfE/view?usp=sharing
Get build-deps : # yum-builddep xml-security-c.spec
I'm trying to compile a program with make, but I get stuck on a error raised (see below) :
gcc -Wall -g -O2 -I. -I../include -I/usr/include/libxml2/ -I/usr/include/x86_64-linux-gnu/ -I/usr/include/geotiff/ -I/usr/local/hdf4/hdf-4.2.11/hdf4/include/ -I/usr/local/hdf-eos/hdfeos/include/ -I -I -o convert_lpgs_to_espa convert_lpgs_to_espa.o -L../lib -l_espa_format_conversion -l_espa_raw_binary -l_espa_common -L/usr/lib/x86_64-linux-gnu/ -lxml2 -L/usr/lib/ -lgeotiff -L/usr/lib/x86_64-linux-gnu/ -ltiff -L/usr/lib/x86_64-linux-gnu/ -ljpeg -L -ljbig -L/usr/local/hdf-eos/hdfeos/hdfeos2/lib -lgctp -L -lz -lm
/usr/lib/x86_64-linux-gnu/libicuuc.so.52: référence indéfinie vers « __cxa_throw_bad_array_new_length#CXXABI_1.3.8 »
collect2: error: ld returned 1 exit status
Makefile:95: recipe for target 'convert_lpgs_to_espa' failed
make[1]: *** [convert_lpgs_to_espa] Error 1
make[1]: Leaving directory '/project/$folders$/tools'
Makefile:6: recipe for target 'all' failed
make: *** [all] Error 2
Following this close question : program linking fails when using custom built gcc, I purge and reinstall libstdc++-4.9-dev.
I'm running
Ubuntu 15.04 with gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2
How can I resolve this issue ?
It's because you link using gcc instead of g++. The difference is that the g++ command adds the C++ runtime library when linking.
You can either change from using gcc to g++, or manually link with the C++ runtme library by adding -lstdc++.
while building Lua on windows by mingw491 it gives an undefined reference error. Following is the output:
C:\Users\Alizadeh\Desktop\lua-5.3.0>mingw32-make PLAT=mingw
cd src && mingw32-make mingw
mingw32-make[1]: Entering directory 'C:/Users/Alizadeh/Desktop/lua-5.3.0/src'
mingw32-make "LUA_A=lua53.dll" "LUA_T=lua.exe" \
"AR=gcc -std=gnu99 -shared -o" "RANLIB=strip --strip-unneeded" \
"SYSCFLAGS=-DLUA_BUILD_AS_DLL" "SYSLIBS=" "SYSLDFLAGS=-s" lua.exe
mingw32-make[2]: Entering directory 'C:/Users/Alizadeh/Desktop/lua-5.3.0/src'
g++ -c -o lua.o lua.c
g++ -c -o lapi.o lapi.c
g++ -c -o lcode.o lcode.c
.
.
.
g++ -c -o loadlib.o loadlib.c
g++ -c -o linit.o linit.c
gcc -std=gnu99 -shared -o lua53.dll lapi.o lcode.o lctype.o ldebug.o ldo.o ldump
.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o
ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o lbitlib.o lcorolib.o
ldblib.o liolib.o lmathlib.o loslib.o lstrlib.o ltablib.o lutf8lib.o loadlib.o
linit.o
ldo.o:ldo.c:(.text+0xe5): undefined reference to `__cxa_allocate_exception'
ldo.o:ldo.c:(.text+0x105): undefined reference to `__cxa_throw'
ldo.o:ldo.c:(.text+0x234): undefined reference to `__cxa_begin_catch'
ldo.o:ldo.c:(.text+0x24c): undefined reference to `__cxa_end_catch'
ldo.o:ldo.c:(.rdata$_ZTIP11lua_longjmp[__ZTIP11lua_longjmp]+0xffff3fb8): undefin
ed reference to `vtable for __cxxabiv1::__pointer_type_info'
C:/Qt/Qt5.4.0/Tools/mingw491_32/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../.
./i686-w64-mingw32/bin/ld.exe: ldo.o: bad reloc address 0x0 in section `.rdata$_
ZTIP11lua_longjmp[__ZTIP11lua_longjmp]'
collect2.exe: error: ld returned 1 exit status
makefile:59: recipe for target 'lua53.dll' failed
mingw32-make[2]: *** [lua53.dll] Error 1
mingw32-make[2]: Leaving directory 'C:/Users/Alizadeh/Desktop/lua-5.3.0/src'
makefile:116: recipe for target 'mingw' failed
mingw32-make[1]: *** [mingw] Error 2
mingw32-make[1]: Leaving directory 'C:/Users/Alizadeh/Desktop/lua-5.3.0/src'
makefile:55: recipe for target 'mingw' failed
mingw32-make: *** [mingw] Error 2
I'm using mingw (491) on windows7 and I want to link it with Qt.
I found the answer. I've just used g++ instead of gcc and it fixed :)
The solution is to add the following line in src/Makefile:
CXX= gcc -std=gnu99
Or more generally to set CXX to whichever value CC is set.
This problem occurs because the Lua make files rely on the implicit rules and variables of GNU make (source). Which means that make should call $(CC) -c $(CFLAGS) $(CPPFLAGS) to build .o files from .c files.
However mingw make calls $(CXX) -c $(CFLAGS) $(CPPFLAGS). This means that Lua C code is compiled as C++. The issue reveals itself at linktime as here gcc is used and it fails to find C++ related dependencies. So from here you have 2 solutions:
Replace gcc by g++ at link time (Mosi's solution). Which you should NOT do!
As you will end up with C++ symbols with mangled names and you will not be able to use your DLL in anything else than C++ projects. Although your code will not be portable as any other Lua DLL will not have C++ symbols.
Replace g++ by gcc during compilation (see above). You will end up with valid C symbols in your DLL.
I am getting the following error:
../../../external/boost-1.55.0-x86_64-linux-gcc-4.8.2/lib/libboost_system.so: file not recognized: File truncated
If I swap the order of boost_filesystem and boost_system I get the following error:
../../../external/boost-1.55.0-x86_64-linux-gcc-4.8.2/lib/libboost_filesystem.so: file not recognized: File truncated
Boost built correctly to my knowledge. There were no errors during the build. The makefile that is doing the linking is as follows:
libtool: link: g++ -g -O2 -pthread -Wl,-rpath=../../../external/boost-1.55.0-x86_64-linux-gcc-4.8.2/lib -o xml_wrapper_tester xml_wrapper_tester-runner.o - L../../../external/boost-1.55.0-x86_64-linux-gcc-4.8.2/lib -lboost_wserialization -lboost_timer -lboost_date_time -lboost_iostreams -lboost_chrono -lboost_atomic -lboost_serialization -lboost_locale -lboost_log -lboost_thread -lboost_regex -lboost_log_setup -lboost_system -lboost_filesystem ../xml_wrapper/.libs/libxml_wrapper.a-pthread
../../../external/boost-1.55.0-x86_64-linux-gcc-4.8.2/lib/libboost_system.so: file not recognized: File truncated
collect2: error: ld returned 1 exit status
make[2]: *** [xml_wrapper_tester] Error 1
make[2]: Leaving directory /home/mehoggan/Devel/RuleSimulator/src/xml/xml_wrapper_tester'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/mehoggan/Devel/RuleSimulator/src/xml'
make: *** [all] Error 2
It sounds like your libboost* files are corrupt.
Q: Did you build them yourself? If so, I'd suggest "make clean" (or "rm -rf" from your build root), and rebuild from scratch.
Check carefully for any build errors when you do so.
I would very carefully follow these instructions:
http://www.boost.org/doc/libs/1_55_0/more/getting_started/unix-variants.html
'Hope that helps
I am trying to install gdb-7.2 on Solaris 11 for debugging a c++ script that is issuing a segmentation fault alert.
Once configured (./configure),
checking whether -fkeep-inline-functions is supported... yes
configure: creating ./config.status
config.status: creating Makefile
I move on make (make) however this fails with the following errors:
ar: creating libgdb.a ranlib libgdb.a
rm -f gdb
gcc -g -O2 -rdynamic \
-o gdb gdb.o libgdb.a \
../readline/libreadline.a ../opcodes/libopcodes.a ../bfd/libbfd.a \
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a \
-ldl -lcurses -lz -lsocket -lnsl -lm -lsocket -lnsl -ldl -lm \
-lpython2.6 -lexpat ../libiberty/libiberty.a gnulib/libgnu.a
Undefined first referenced symbol in file
wattr_on libgdb.a(tui-wingeneral.o)
wattr_off libgdb.a(tui-wingeneral.o)
ld: fatal: symbol referencing errors. No output written to gdb collect2: ld returned 1 exit status
*** Error code 1 make: Fatal error: Command failed for target `gdb'
What could be the possible issue and is there any solution for this?
It looks like some bug linking against the Solaris curses library. Offhand I can't diagnose it. It's worth digging into and patching upstream...
Meanwhile, you can probably work around it by configuring with --disable-tui.