Linking/compiling a program that uses boost/filesystem.hpp - c++

I'm trying to use the boost/filesystem library in some code that I am writing. I seem to be having a hard time getting it to compile. I'm running Debian Wheezy, and have boost version 1.49(which is what comes if you install using apt-get). I'm trying to compile an example that is available with the documentation
#include <iostream>
#include <boost/filesystem.hpp>
using namespace boost::filesystem;
int main(int argc, char* argv[])
{
if (argc < 2)
{
std::cout << "Usage: tut1 path\n";
return 1;
}
std::cout << argv[1] << " " << file_size(argv[1]) << '\n';
return 0;
}
I use the following command:
g++ temp.cc -o temp /usr/lib/libboost_filesystem.a
I get a number of errors such as:
/usr/lib/libboost_filesystem.a(operations.o): In function `boost::filesystem3::detail::dir_itr_close(void*&, void*&)':
(.text+0x4d): undefined reference to `boost::system::system_category()'
/usr/lib/libboost_filesystem.a(operations.o): In function `boost::filesystem3::detail::directory_iterator_increment(boost::filesystem3::directory_iterator&, boost::system::error_code*)':
(.text+0xe3): undefined reference to `boost::system::system_category()'
This is probably some linking error right? Any ideas on how I could solve it?
UPDATE #1:
I tried running it with the -lboost_filesyste and -L /usr/lib. It gives me the following error:
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'

You are not linking the library properly. Also, as others mentioned, boost_filesystem needs also boost_system library. Use:
g++ temp.cc -o temp -lboost_system -lboost_filesystem
Command line param -l foo links libfoo.a library. If the static library is not in default library location, use command -L /custom/library/dir. But I believe /usr/lib is automatically taken into consideration by GCC.
Edit
According to your comment below it looks like you are not compiling the file with main() function, or you have a typo in main() name. Make sure that temp.cc contains one and only one of these functions:
int main();
int main(int argc, char** argv);
Of course you do remember that upper/lower case matters. :)

Boost.Filesystem uses things in Boost.System. You have to link against that, too.
The error messages that you are seeing:
/usr/lib/libboost_filesystem.a(operations.o): In function
`boost::filesystem3::detail::dir_itr_close(void*&, void*&)':
(.text+0x4d): undefined reference to `boost::system::system_category()'
that's a reference to Boost.System
Add -lboost_system and you should be good to go (or, at least better off).

Compile with -lboost_filesystem

Related

g++ failing when trying to use GDAL library [duplicate]

This question already has answers here:
What is an undefined reference/unresolved external symbol error and how do I fix it?
(39 answers)
Closed 3 months ago.
I just want to compile this easy example of the GDAL library in my Ubuntu 22.04 system using the system-packed g++, version 11.3.0:
#include <iostream>
#include "gdal_priv.h"
#include "cpl_conv.h"
#include "gdal.h"
using namespace std;
int main(int argc, char* argv[])
{
GDALDataset *poDataset;
GDALAllRegister();
poDataset = (GDALDataset *) GDALOpen(argv[1], GA_ReadOnly);
if (poDataset == NULL)
{
cout << "No dataset loaded for file " << argv[1] << ". Exiting." << endl;
return 1;
}
cout << "Driver: "
<< poDataset->GetDriver()->GetDescription()
<< "/"
<< poDataset->GetDriver()->GetMetadataItem(GDAL_DMD_LONGNAME)
<< endl;
cout << "Size: "
<< poDataset->GetRasterXSize() << "x"
<< poDataset->GetRasterYSize() << "x"
<< poDataset->GetRasterCount()
<< endl;
if (poDataset->GetProjectionRef() != NULL)
{
cout << "Projection: " << poDataset->GetProjectionRef() << endl;
}
}
Of course I installed the GDAL libraries, as it can be seen here:
~$ dpkg -l | grep gdal
ii gdal-bin 3.4.1+dfsg-1build4 amd64 Geospatial Data Abstraction Library - Utility programs
ii gdal-data 3.4.1+dfsg-1build4 all Geospatial Data Abstraction Library - Data files
ii libgdal-dev 3.4.1+dfsg-1build4 amd64 Geospatial Data Abstraction Library - Development files
ii libgdal30 3.4.1+dfsg-1build4 amd64 Geospatial Data Abstraction Library
ii python3-gdal 3.4.1+dfsg-1build4 amd64 Python 3 bindings to the Geospatial Data Abstraction Library
Everything seems to be settled and ready to go, but then, when I trigger this g++ command to compile my little program
g++ -I/usr/include/gdal -L/usr/lib -lgdal open_file.cpp -o open_file -g
it fails with this output:
/usr/bin/ld: /tmp/ccU6PwuP.o: in function `main':
/home/jose/Code/concepts/gdal/open_file.cpp:13: undefined reference to `GDALAllRegister'
/usr/bin/ld: /home/jose/Code/concepts/gdal/open_file.cpp:14: undefined reference to `GDALOpen'
/usr/bin/ld: /home/jose/Code/concepts/gdal/open_file.cpp:29: undefined reference to `GDALDataset::GetRasterXSize()'
/usr/bin/ld: /home/jose/Code/concepts/gdal/open_file.cpp:30: undefined reference to `GDALDataset::GetRasterYSize()'
/usr/bin/ld: /home/jose/Code/concepts/gdal/open_file.cpp:31: undefined reference to `GDALDataset::GetRasterCount()'
/usr/bin/ld: /home/jose/Code/concepts/gdal/open_file.cpp:34: undefined reference to `GDALDataset::GetProjectionRef() const'
/usr/bin/ld: /home/jose/Code/concepts/gdal/open_file.cpp:36: undefined reference to `GDALDataset::GetProjectionRef() const'
collect2: error: ld returned 1 exit status
Which doesn't make any sense, because I am indeed passing the GDAL libraries in -I/usr/include/gdal and the definition of the "undefined" references do exist in the multiple .h files there.
Moreover, this works using clang++:
clang++ -I/usr/include/gdal -L/usr/lib -lgdal open_file.cpp -o open_file -g
Did anyone have a similar issue, or can give some hint on where the problem might be? Thank you.
Include paths have nothing to do with the symbols.
-I/usr/include/gdal -L/usr/lib both are not necessary as they are set by default. But you should use #include <gdal/gdal.h>, not just <gdal.h> and certainly not "gdal.h".
Move -lgdal after all other cpp/object files.
In general, it should be g++ <OPTIONS> <OBJECTS> <LIBRARIES> where library A which uses symbols from lib B should appear after B i.e. -lB -lA, the order matters for ld. Because it will use the library to resolve just the currently missing symbols and then will promptly forget the library ever existed. So any newly found unresolved symbols will not be resolved, hence shifting the library arguments "right". One can resolve circular dependencies by repeating libraries more than once.

LLVM-5.0 Makefile undefined reference fail

Including the following statement in my code
main_module->dump(); // main_module is of type llvm::Module*
causes the following linker error:
undefined reference to 'llvm::Module::dump() const'
The dump method resides in /usr/lib/llvm-5.0/include/llvm/IR/Module.h
I checked stack overflow (Using llvm::Function::dump(), linker gives "undefined reference to `llvm::Value::dump() const'"), and it seems we get this error when the linker isn't fed the libraries in correct order. However, I clearly have the libraries in the end in my compilation command:
clang++-5.0 -g -O3 main.cpp -o main llvm-config-5.0 --cxxflags --ldflags --system-libs --libs core mcjit native
Any help is appreciated.
The weird thing is, the linker figured out that the type of the dump method. It clearly went in the include file. So why would it call it an undefined reference?
Code I am trying to run:
`
# include "llvm/IR/LLVMContext.h"
# include "llvm/IR/Module.h"
# include "llvm/IR/IRBuilder.h"
# include <iostream>
using namespace llvm;
static LLVMContext ctxt;
static IRBuilder<> builder(ctxt);
int main(int argc, char** argv) {
Module* main_module = new Module("main_module", ctxt);
std::cout << main_module->getModuleIdentifier() << "\n";
FunctionType* func_type = FunctionType::get(builder.getInt32Ty(), false);
Function* main_func = Function::Create(func_type,Function::ExternalLinkage, "main", main_module);
if (main_module->getFunction("main")) {
std::cout << "Found function!\n";
}
main_module->dump(); // need this for debugging and testing reasons with LLVM
return 0;
}
In addition to the solution that Subrat provided, you can adjust your code to avoid calling dump. You can achieve the same thing by calling:
main_module->print(llvm::outs(), nullptr);
Similarly, if you want to dump a LLVM function, you can write:
main_func->print(llvm::outs());
Actually, as of LLVM 5.0.0, this is how the dump() function is implemented.
Seems like the definition for dump is in ASMWriter.cpp, which seems to be depracated.
Also, ASMWrite.cpp's debug method refers to dbgs() which is in debug.cpp
I fixed the problem by copying over debug.cpp and the Module::dump() (from ASMWriter.cpp--since I don't need the whole code, only a specific subroutine from this file) routine and putting it in my cpp file.

Fixing undefined reference to dlopen() and dlcose()

I have created a simple C++ application. I can compile it, and it works fine. But now I need to load the library dynamically, and I have added dlfnc.h to my project and added some more code:
#include <iostream>
#include <dlfcn.h>
void *mylib;
int eret;
using namespace std;
int main() {
mylib = dlopen("mylib.so", RTLD_LOCAL | RTLD_LAZY);
eret = dlclose(mylib);
cout << "!!!Hello, World!!!" << endl; // Prints !!!Hello, World!!!
return 0;
}
Compiling:
cd ~/workspace/LinuxGcc/src
g++ LinuxGcc.cpp
And I got a compilation error:
/tmp/ccxTLiGY.o: In function `main':
LinuxGcc.cpp:(.text+0xf): undefined reference to `dlopen'
LinuxGcc.cpp:(.text+0x25): undefined reference to `dlclose'
collect2: error: ld returned 1 exit status
dlfcn.h exist in /usr/include/.
Where is the problem?
From dlopen(3):
Link with -ldl.
so
g++ LinuxGcc.cpp -ldl
will be OK.
The solution is very simple. Add the -ldl flag for linking.
In case of the Bazel build system, linkopts = ['-ldl'].

test.c:(.text+0x36): undefined reference to `md5_file'

I installed polarssl:
make
sudo make install
tried to compile very simple file, named test.c:
#include <stdio.h>
#include "polarssl/md5.h"
int main(int argc, char * argv[])
{
int i;
for (i=1;i<1;i++)
{
char res[16];
if (md5_file("file.txt",res) == 0)
{
int count;
for (count=0;count<16;count++)
printf("%02x",res[count]);
printf("n");
}
}
return 0;
}
Compiled it like this:
gcc -lpolarssl test.c -I /usr/local/include/polarssl/
but it shows me:
/tmp/cczptlsk.o: In function `main':
test.c:(.text+0x36): undefined reference to `md5_file'
collect2: ld returned 1 exit status
whats the problem, how to fix it? I know for 100% that polarssl files are in /usr/local/include/polarssl/
The compiler will attempt to complete linkage in the order the objects or files are presented. In this case, since you had put -lpolarssl first, there were no unresolved symbols needed from that library, so nothing got linked in.
Putting -lpolarssl last lets the compiler resolve unresolved symbols from your source file from that library.
Includes are fine.
But linking is wrong. Try to put the -lpolarssl last in the linker command.
Then add a -L if libpolarssl.a is not found by the linker to point it to the right location.

xerces-c++ compile/linking question

After installing Xerces-C++ (XML library):
./configure --disable-shared
./make
./make-install
ldconfig
And writing the simple program (xmlval.cpp):
#include <stdio>
#include <xercesc/dom/DOM.hpp>
int main()
{
std::cout << "HI" << std::endl;
}
And compiling:
/usr/bin/g++ -L/usr/local/lib -I/usr/local/include -o xmlval xmlval.cpp /usr/local/lib/libxerces-c.a
The compile result is a bunch of lines like:
/usr/local/lib/libxerces-c.a(CurlNetAccessor.o): In function `xercesc_3_0::CurlNetAccessor::cleanupCurl()':
/home/stullbd/xerces-c-3.0.1/src/xercesc/util/NetAccessors/Curl/CurlNetAccessor.cpp:78: undefined reference to `curl_global_cleanup'
/usr/local/lib/libxerces-c.a(CurlNetAccessor.o): In function `xercesc_3_0::CurlNetAccessor::initCurl()':
/home/stullbd/xerces-c-3.0.1/src/xercesc/util/NetAccessors/Curl/CurlNetAccessor.cpp:70: undefined reference to `curl_global_init'
/usr/local/lib/libxerces-c.a(CurlURLInputStream.o): In function `~CurlURLInputStream':
/home/stullbd/xerces-c-3.0.1/src/xercesc/util/NetAccessors/Curl/CurlURLInputStream.cpp:168: undefined reference to `curl_multi_remove_handle'
Any thoughts on this?
You seem to miss linking with curl, try adding -lcurl.