I am trying to compile my gcc code using the following make command .
OS :Redhat ,gcc - 4.1
But I am getting error as follows :
rmtrain#lintrni130 $ /usr/local/bin/make all
[ 21%] Built target GCVCore
Linking CXX executable CFE
/usr/bin/ld: warning: libicui18n.so.36, needed by ../../Generic/icu/lib/libicuio.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libxalanMsg.so.110, needed by ../../Generic/Xalan/lib/libxalan-c.so, not found (try using -rpath or -rpath-link)
CMakeFiles/CFE.dir/trnuser1/rmtrain/DevelopmentEnv/Generic/ConvUI/GCVConvUISetting.o: In function `xercesc_2_6::XMLAttDefList::~XMLAttDefList()':
GCVConvUISetting.cpp:(.text._ZN11xercesc_2_613XMLAttDefListD0Ev[xercesc_2_6::XMLAttDefList::~XMLAttDefList()]+0x2f): undefined reference to `xercesc_2_6::XMemory::operator delete(void*)'
Please Help with this .
The warnings means that some libraries you link to have dependencies on other shared libraries, and those libraries weren't found in the linker's search path. The linker manual describes how it forms that search path in the docs for the -rpath-link option
They're only warnings, so haven't caused your link to fail. It will be a problem if those required libs aren't found at run-time, but is not necessarily a problem at link-time.
If you want to silence the warnings you will need to find out which directory contains libicui18n.so.36 and libxalanMsg.so.110 and use one of the methods described in the manual to tell the linker to look in that directory.
The last line is the real problem, and indicates you are not linking to the library which defines that symbol. You'll need to find out which library it is and link to it with -lfoo, it will probably be something like -lxerces
i reinstalled icu 3.2 instead of 3.6.It worked fine then.
Related
While attempting to write a kernel in C++, I've run into a peculiar issue.
When prompting g++ to compile even a very basic C++ file statically and to binary, it simply keeps skipping over the static math library (libm.a), ultimately failing to compile.
Attempting to compile a simple C++ file:
test.cpp
int main() {
return 0;
}
using this g++ command:
g++ -static test.cpp -Wl,--oformat=binary
I receive the following error output:
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when searching for -lm
/usr/bin/ld: cannot find -lm: No such file or directory
I am running Linux Mint Cinnamon V. 21 (Vanessa) on a VirtualBox VM.
In my attempt to narrow down the issue, I have also attempted to exclude the -static flag:
g++ test.cpp -Wl,--oformat=binary
Which results in a different error entirely:
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/libstdc++.so: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status
After thorough research, I was made aware that this could be caused by an incompatibility between 32-bit libraries and 64-bit files. Everything is supposed to be in 64 bit.
I did attempt to determine bitness of libm.a using file.
When using the file command on /usr/lib/x86_64-linux-gnu/libm.a, I receive the following output:
libm.a: ASCII text
indicating neither bitness. This led me to conclude that perhaps the library is damaged and needs updating. After running sudo apt-get install libc6-dev, the issue persists, however.
I'm not sure what to do at this point.
Update:
I've opened libm.a in a text editor and the entire contents of the file are:
/* GNU ld script
*/
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /usr/lib/x86_64-linux-gnu/libm-2.35.a /usr/lib/x86_64-linux-gnu/libmvec.a )
Update 2: apparently this is a linker script. Both referenced files libm-2.35.a and libmvec.a are present in my directory and are, according to objdump, 64-bit-versions.
Based on the compiler's error output, it seems that in my case, for whatever reason, g++ (or more specifically, ld) fails to use this linker script. What could possibly cause this?
I have come to the conclusion that it is not normally possible to statically link C++ code involving object oriented features into a fully functional binary file, as libm.a can apparently be linked to ELF only.
besides: even the static version of glibc, which is also required, references other dynamic libraries, making it useless for kernel code.
there might be some sort of workaround, but it seems that g++ does not support this functionality by default.
I am attempting link an app with my compiler, however, ld is warning it cannot find specified libraries. This is the last one that I cannot handle.
I am calling the linker with:
/usr/bin/c++ -O3 -DNDEBUG XXX -o ijkmcube -lNrrdIO,-rpath,XXX:
Id warned that:
/usr/bin/ld: cannot find -lNrrdIO
Since this library seems like not that popular, I cannot find direct apt install method to handle it.
Furthermore, I could only find out .a library instead of .so library for this particular case.
locate libNrrdIO.a
/home/XXX/Desktop/NrrdIO-1.11.0-src/libNrrdIO.a
/home/XXX/Desktop/src/ijkmcube/lib/libNrrdIO.a
How do I diagnose this problem further, and what could be wrong? Thanks in advance!
I am trying to cross-compile apache-qpid for an arm system from a debian.
There is undefined reference to __dlopen error, but it seems that it is related to the previous warning:
using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking ...
Here is the detail:
[ 86%] Linking CXX shared library libqpidcommon.so
CMakeFiles/qpidcommon.dir/qpid/sys/posix/Shlib.cpp.o: In function
`qpid::sys::Shlib::load(char const*)':
/home/mert/qpid-cpp-0.34/src/qpid/sys/posix/Shlib.cpp:32: warning: Using
'dlopen' in statically linked applications requires at runtime the shared
libraries from the glibc version used for linking
/home/mert/IDE/cVEND/00.00.14/bin/../arm-feig-linux-
gnueabi/sysroot/usr/lib/libdl.a(dlopen.o): In function `dlopen':
dlopen.c:(.text+0xc): undefined reference to `__dlopen'
I do not know what is happening exactly and how to solve it.
Here there is a similiar thing, I tried to add -static -ldl -lc C_FLAGS but made no difference.
Any help appreciated.
EDIT :
EDIT :
I am not sure exactly what is solved the problem, but I think that -ldl was looking exactly for libdl.so, but in arm directory, it was libdl-2.19.so, thus, probably it was then looking for and finding in another directory. I have linked libdl.so to libdl-2.19.so and now it is compiling.
The linker needs the options, not the compiler. See LDFLAGS.
https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
Extra flags to give to compilers when they are supposed to invoke the
linker, ‘ld’, such as -L. Libraries (-lfoo) should be added to the
LDLIBS variable instead.
If this error occurs during the make step try doing
make LIBS=-ldl
And make sure the library path is present in LDFLAGS
export LDFLAGS=-L<path/to/ldl>
I am trying to build a small Qt (C++) GUI application on Linux but it fails to build with numerous linker errors, complaining about missing dependencies for the Qt library I am linking against. I used ldd on the Qt libraries to verify that the libraries are indeed there - and they are.
My problem seems to be related to the discussion in this thread:
Linking dependencies of a shared library
And while that thread helped me identify my precise problem, it seems that the conclusion of that thread was that my application should link!
The application is compiled with the following command:
g++ -m64 -Wl,-O1 -o Executable some-object.o some-other-object.o -lQtCore -lQtGui -lQtXml -L/usr/lib64 -L/usr/X11R6/lib64 -lpthread
Running this generates warnings of the following form, and linking eventually fails with undefined reference errors (to symbols defined in the 'missing' libraries):
.../ld: warning: libglib-2.0.so.0, needed by /usr/lib64/libQtGui.so, not found (try using -rpath or -rpath-link)
.../ld: warning: libpng14.so.14, needed by /usr/lib64/libQtGui.so, not found (try using -rpath or -rpath-link)
.../ld: warning: libz.so.1, needed by /usr/lib64/libQtGui.so, not found (try using -rpath or -rpath-link)
.../ld: warning: libfreetype.so.6, needed by /usr/lib64/libQtGui.so, not found (try using -rpath or -rpath-link)
and so on (in total there are 18 dependencies that could not be found.)
I can get this to compile if I go and explicitly add -lglib, -lpng14, -lz -lfreetype and so on, but as I mentioned there are 18 dependencies - and I would rather not do that. It also seems that I should not have to do it.
I have compiled the same project on my laptop computer which uses the exact same Linux Distro (openSuse 12.2) without any troubles. All libraries, including Qt, were installed from the distro repositories.
I think this might be some sort of setup problem on my openSuse install, but I have no idea where to start looking to fix this.
Cheers,
Craig
It appears that /usr/lib64/libQtGui.so have hardcoded rpaths in them to locate dependent shared libraries. On one of your hosts the needed libraries are in the expected location while on the other host they are not.
You can use something like elfdump to get the RPATH out of the QT shared library to find out where it will look. Then you can use (I believe) -R on your link command line to point it to where the libraries are actually installed on that host.
EDIT: I think you can do something like objdump -x <binary/library> | grep -i rpath
I am have been attempting to get a C++ project setup using boost file system library using eclipse. I followed these directions to install boost on my system. The directions where pretty much
download
extract
run bootstrap.sh
run ./bjam architecture=combined
That seemed to go fine, no errors. I then fired up eclipse and created a new test project called test with a single file called test.cpp. The code in it is:
#include <stdio.h>
#include <boost/filesystem.hpp>
int main() {
boost::filesystem::path path("/Users/schoen"); // random pathname
bool result = boost::filesystem::is_directory(path);
printf("Path is a directory : %d\n", result);
return 0;
}
This is just something simple to make sure it is all set up correctly. Of course I tried to compile at this point and it failed. Did some googling and found this site. It said to add the boost library to the linker by going to project properties and adding "boost_filesystem". I tried this, and well it didn't work.
Can someone point me in the right direction or give me a hint to how to set up Boost in an Eclipse project?
I am new to C++ and Eclipse, and most my experience is in Java with Netbeans. So I am pretty lost at the moment.
UPDATE
I just wanted to update on what I have tried based on the answers given.
Based on Alex's suggestion I added boost_system and boost_filesystem to the linker list. I was still getting the same compiler errors.
Following the suggestion from rve I added the path to the boost libraries to the Library search path. When this did not work. I cleared out the linker list and tried it with just the library search path. This also did not work.
I then cleared the Library search path. I then manually edited the command on the linker window to be 'g++ -L/Users/jacobschoen/Library/boost_1_45_0/stage/lib -lboost -lboost_filesystem'. This also did not work.
In all of these I tried setting the path to boost to be '/Users/jacobschoen/Library/boost_1_45_0' and '/Users/jacobschoen/Library/boost_1_45_0/stage/lib'. Neither worked.
As requested the comiler error for the above code is:
**** Build of configuration Debug for project test ****
make all
Building file: ../src/test.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/test.d" -MT"src/test.d" -o"src/test.o" "../src/test.cpp"
../src/test.cpp:10:32: warning: boost/filesystem.hpp: No such file or directory
../src/test.cpp: In function 'int main()':
../src/test.cpp:13: error: 'boost' has not been declared
../src/test.cpp:13: error: expected `;' before 'path'
../src/test.cpp:14: error: 'boost' has not been declared
../src/test.cpp:14: error: 'path' was not declared in this scope
make: *** [src/test.o] Error 1
If any one has any further suggestions I am still trying.
Second Update
On a suggestion by rholmes I added an include library along with the linker list and library search path. So now the compile error is:
**** Build of configuration Debug for project test ****
make all
Building target: test
Invoking: MacOS X C++ Linker
g++ -L/Users/jacobschoen/Library/boost_1_45_0 -o "test" ./src/test.o -lboost_system -lboost_filesystem
ld: library not found for -lboost_system
collect2: ld returned 1 exit status
make: *** [test] Error 1
Any ideas?
Just wanted to be clear on what actually worked, since it was kinda pieced together from a few answers.
Download the boost files and extract them to where you want to put them.
In your terminal navigate to the directory and run ./bootstrap.sh
When that is done run ./bjam (this takes a while so go smoke and get a cup of coffee)
Open up your eclipse Project and go to Project > Properties > C/C++ Build > Settings
Click on MacOS X C++ Linker > Libraries.
You should see a split window with the top being for 'Libraries (-l)'. In this section add both boost_system and boost_filesystem. In the bottom section it should be for 'Library Search Path (-L)'. Here you want to put the path to the stage/lib directory inside where you extracted the boost download. It should look similar to below:
Click GCC C++ Compiler > Includes. This will be a single pane where it says 'Include Paths (-I)', well I think it is an I as he font is weird and could be a lower case l also. Anyway in that section add the path to where you put boost without the stage/lib part. It should look like below:
Everything should compile now with out a problem, and if you need to use any other boost libraries it should be just a matter of adding it to the linker section where boost_filesystem and boost_system are. Enjoy.
Not sure where you do this in Eclipse these days, but under the include paths for Eclipse should be the path to the main boost directory (/Users/jacobschoen/Library/boost_1_45_0?). The compiler line should have something like the following in it, I would think:
Invoking: GCC C++ Compiler
g++ -I/Users/jacobschoen/Library/boost_1_45_0 -O0 -g3 -Wall -c -fmessage-length=0 -MMD (etc..)
Update: Looking at my system, the linker path on yours might be more appropriately:
-I/Users/jacobschoen/Library/boost_1_45_0/stage/lib
Depending, of course, upon how you've installed and built boost -- this is with my most recent attempt with a full source build. Depending upon how you obtained boost, this may or may not be different. I recently redid the boost on my Mac for 64 bit and haven't had much time to try it yet....
Add boost_system to the linker list, together with boost_filesystem.
I had recently uninstalled the boost rpm and installed Boost like how you did. I had no problems running Boost programs in Eclipse. I didn't add any extra parameters. Just installed boost and ran Boost programs. It works fine.
Tried your program in the vi editor. Commented out everything in main
#include <cstdio>
#include <boost/filesystem.hpp>
int main() {
/*boost::filesystem::path path("/Users/schoen"); // random pathname
bool result = boost::filesystem::is_directory(path);
printf("Path is a directory : %d\n", result);*/
return 0;
}
and it still gave this error:
/tmp/cc7TAIYS.o: In function `__static_initialization_and_destruction_0(int, int)':
test.cpp:(.text+0x29): undefined reference to `boost::system::get_system_category()'
test.cpp:(.text+0x35): undefined reference to `boost::system::get_generic_category()'
test.cpp:(.text+0x41): undefined reference to `boost::system::get_generic_category()'
test.cpp:(.text+0x4d): undefined reference to `boost::system::get_generic_category()'
test.cpp:(.text+0x59): undefined reference to `boost::system::get_system_category()'
collect2: ld returned 1 exit status
I'm puzzled. Boost programs work on my system, but your program's header files itself are giving a problem. I doubt it's a problem with Eclipse. It has to be something else.
I just ran into something very similar to this using eclipse and CDT... It turns out, using ubuntu and apt-get, libboost_system installs as libboost_system.1.40.0 in /usr/lib
If you try to add it via the library tab in Helios it will complain because it is looking for *.so and *.s0.1.40.0 clearly doesn't match that. However after looking closely at what the linker was trying to doo, I just typed the raw string "boost_system" into the include path adder. This resulted in the linker doing a " -lboost_system" which is a format the linker knows how to deal with in resolving version dependency... If you instead put in the full path to the .so file, the linker will just complain because it tries to do a " -l/usr/lib/libboost_system.so.1.40.0" .
So take my advice and just type in the simple " boost_system" after doing an apt-get install.. It will make it all very easy.