omp.cpp
#include <iostream>
#include <omp.h>
int main() {
std::cout << "Start" << std::endl;
#pragma omp parallel
{
std::cout << "Hello ";
std::cout << "World! " << std::endl;
}
std::cout << "End" << std::endl;
}
I've tried to compile the above code with g++ omp.cpp -fopenmp but I get the error:
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lpthread
collect2.exe: error: ld returned 1 exit status
I've tried googling what -lpthread is but I couldn't find anything. The closest thing I found was another thread in which someone compiled his/her code like this: g++ omp.cpp -fopenmp -lpthread ... but the result is the same for me.
Am I missing something? Much appreciated in advance.
pthread is the POSIX thread library.
-lpthread is a linker argument, meaning you are trying to link your binary with pthread.
The error means that this library is not available on your OS.
It looks like you are using mingw on Windows.
No surprise pthread isn't available on Windows, as it's a POSIX library.
But you may find some ways to have it on the MinGW website:
http://www.mingw.org/wiki/pthreads_library
Looks like you'll have to install a third-party library called pthreads-win32:
https://sourceware.org/pthreads-win32/
Related
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.
I am writing a personal project in c++ which needs to access to files in some directories, hence I decided to use the filesystem library. I encountered some problems when I try to compile my project on MacOS and on Linux.
The code snippet is the following
#include <iostream>
#include <fstream>
int main(){
std::string path = "Inner";
std::cout << "Files in " << path << " directory :" << std::endl;
for (const auto & entry : std::filesystem::directory_iterator(path))
std::cout << entry.path() << std::endl;
return 0;
}
When I compile it on my MacBook Pro (clang version 11.0.3 (clang-1103.0.32.62)) with
g++ -o test test.cpp -std=c++17 -Wall
everything works fine. But as soon as I move to Linux (Ubuntu 19.04, g++ 8.3.0) I get the following error:
test.cpp: In function ‘int main()’:
test.cpp:8:33: error: ‘std::filesystem’ has not been declared
for (const auto & entry : std::filesystem::directory_iterator(path)){
I include then the filesystem library with #include <filesystem>:
#include <iostream>
#include <fstream>
#include <filesystem>
int main(){
std::string path = "Inner";
std::cout << "Files in " << path << " directory :" << std::endl;
for (const auto & entry : std::filesystem::directory_iterator(path))
std::cout << entry.path() << std::endl;
return 0;
}
compile it via g++ -o test test.cpp -std=c++17 -Wall -lstdc++fs and everything works fine on Linux too (note that I had to add -lstdc++fs).
Why is there this different behaviour on MacOS and on Linux? Does it depends on the compiler? What happens with Windows OS (I do not have any Windows PC at home)?
I found a related question and its answer here, but it does not seem to explain why in the first case (with clang) everything works fine also without including filesystem library.
Using 'g++' is not using clang you should use 'clang++'
Gcc should not be platform dependent but it might be different version
At any case, you should explicitly include header files needed, and std::filesystem is defined in "<filesystem>"
regarding the need to add "lstdc++fs' - this is a hint that actually g++ version is different and uses different llvm versions. As described in https://en.cppreference.com/w/cpp/filesystem
Notes:
Using this library may require additional compiler/linker options. GNU implementation prior to 9.1 requires linking with -lstdc++fs and LLVM implementation prior to LLVM 9.0 requires linking with -lc++fs
this is my code:
#include <boost/thread.hpp>
#include <iostream>
using namespace boost;
void task1()
{std::cout << "This is task1!" << std::endl;}
void task2()
{std::cout << "This is task2!" << std::endl;}
int main ()
{
thread thread_1 = thread(task1);
thread thread_2 = thread(task2);
thread_2.join();
thread_1.join();
return 0;
}
and I compile with:
g++ test.cc -o test -lboost_thread -lpthread -lboost_system
compile failed:
/tmp/ccN9cPiI.o: In function `boost::system::generic_category()':test.cc(.text._ZN5boost6system16generic_categoryEv[_ZN5boost6system16generic_categoryEv]+0x7):
undefined reference to `boost::system::detail::generic_category_instance'
collect2: error: ld returned 1 exit status
What's wrong with that?
My system is Ubuntu 18.04,boost is 1_68.0.
I just tried your example and it works. I tried with boost_1_66_0 and boost_1_65_1 on Ubuntu.
The actual problem is boost itself, not your installation. You can check open bug here:
https://github.com/boostorg/system/issues/24
I have two .cpp files, main.cpp and secondFile.cpp:
#include <iostream>
int main()
{
std::cout << "Hello, World!\n" << std::endl;
std::cout << "I was also able to add this line!" << std::endl;
return 0;
}
And
#include <iostream>
int main()
{
std::cout << "This was from the second file!" << std::endl;
return 0;
}
I have successfully run g++ -o main.cpp main and g++ -o secondFile.cpp secondFile, as well as run each of their corresponding executables. However when I attempt to compile them simultaneously into a single executable g++ -o main.cpp secondFile.cpp bothScripts or clang++ main.cpp secondFile.cpp -o bothScripts I receive the following error:
"duplicate symbol _main in:
/var/folders/49/38grlkzs44zcth3v_dw9m9dm0000gn/T/main-d43536.o
/var/folders/49/38grlkzs44zcth3v_dw9m9dm0000gn/T/secondfile-2bee63.o
ld: 1 duplicate symbol for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)"
Clearly something is being loaded twice, but I am unsure whether this is a library (iostream), that I've named both sections 'main', or something else entirely. There are certainly questions similar to this already, but many are convoluted and not as fundamental for new C++ members (hence my question here).
Context: My rationale is to practice building executables from multiple .cpp files. Is there a better way to go about this? (New to C++ but not to programming/code as a whole.)
The reason for your error is simple. You have 2 main() functions. As you should know, in a C++ program, the function main() generally defines the entry point of a program. When each of the files are compiled together, and have their own main() function, the compiler gets confused and throws an error. To solve this, simply change the name of the main() function in one file, and call it from the other file, if you are planning to run them together.
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.