Undefined reference error with new filesystem library and clang++7 - c++

I was trying to out the new filesystem STL library, but for some reason am getting errors. The Clang++7 website indicates that it should support the new filesystem library – indeed clang is running ahead of g++ I believe.
I used some code from another Stack Exchange post, so it should be valid based upon the number of upvotes. This could should go to the specified directory and print all files in that directory. Here is the code.
#include <iostream>
#include <string>
#include <experimental/filesystem>
namespace fs = std::experimental::filesystem;
int main(int argc, char *argv[])
{
std::string path = "/home/.../Downloads";
for (const auto & entry : fs::directory_iterator(path))
{
std::cout << entry.path() << std::endl;
}
}
The error messages I am getting are:
CMakeFiles/filesystem_app.dir/main.cpp.o: In function `main':
/media/.../clangcpp/filesystem_app/main.cpp:13: undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::operator*() const'
/media/.../clangcpp/filesystem_app/main.cpp:13: undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::operator++()'
CMakeFiles/filesystem_app.dir/main.cpp.o: In function `path<std::__cxx11::basic_string<char>, std::experimental::filesystem::v1::__cxx11::path>':
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../../../include/c++/5.5.0/experimental/fs_path.h:198: undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
CMakeFiles/filesystem_app.dir/main.cpp.o: In function `directory_iterator':
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../../../include/c++/5.5.0/experimental/fs_dir.h:188: undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::directory_iterator(std::experimental::filesystem::v1::__cxx11::path const&, std::experimental::filesystem::v1::directory_options, std::error_code*)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I made sure to include the experimental/filesystem header instead of just filesystem which removed any red squiggles in Clion. I tried to compile from CLion as well as from the command line. The compilation string I used was:
clang++-7 -Wall -std=c++17 main.cpp -o app
Does anyone have a sense of what is wrong here? In the compile error messages I see the reference to std::experimental::filesystem::v1::__cxx11::.. and I am wondering why this does not say cxx17, but I was not sure if that was the cause of the issue. I explicitly indicated c++17 in the compilation string above.

filesystem is still experimental and requires an extra library.
If you are using libstdc++, link with -lstdc++fs (or target_link_libraries(${PROJECT_NAME} stdc++fs)).
For libc++, use -lc++fs (similar for the CMake command).

Related

How to include and use any of the stuff in the subdirectories of `C:\msys64\mingw64\include`

In my VSCode environment with working msys2 / mingW64 /gcc compilers i'm now trying to use ncurses / curses.
msys is in the default installpath, so gcc / g++ /gdb are in
C:\msys64\mingw64\bin
As i understand it, the headerfiles being used by directives are the ones in
C:\msys64\mingw64\include.
So in general i think this is a question how to properly include and use any of the stuff in the subdirectories of C:\msys64\mingw64\include
For my case with ncurses, in include directory there are two subdirectories with names ncurses and ncursesw with identical content.
To begin, i try with a very simple `helloCurses.cpp file
#include <ncurses/curses.h>
using namespace std;
int main(int argc, char ** argv)
{
// init screen and sets up screen
initscr();
// print to screen
printw("Hello World");
// refreshes the screen
refresh();
// pause the screen output
getch();
// deallocates memory and ends ncurses
endwin();
return 0;
}
obviously the compiler can find the ncurses/curses.h file.
But it still doesn't compile.
I'm getting the error messages:
Executing task: C/C++: MingW g++.exe build active file
Starting build...
C:/msys64/mingw64/bin/g++.exe -fdiagnostics-color=always -g D:\GitHub\Cpp-Code-priv\ncurses\helloCurses.cpp -o D:\GitHub\Cpp-Code-priv\ncurses\helloCurses.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\Mathias\AppData\Local\Temp\cc44BFtA.o: in function `main':
D:/GitHub/Cpp-Code-priv/ncurses/helloCurses.cpp:7: undefined reference to `__imp_initscr'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/GitHub/Cpp-Code-priv/ncurses/helloCurses.cpp:10: undefined reference to `__imp_printw'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/GitHub/Cpp-Code-priv/ncurses/helloCurses.cpp:13: undefined reference to `__imp_refresh'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/GitHub/Cpp-Code-priv/ncurses/helloCurses.cpp:16: undefined reference to `__imp_stdscr'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/GitHub/Cpp-Code-priv/ncurses/helloCurses.cpp:16: undefined reference to `__imp_wgetch'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/GitHub/Cpp-Code-priv/ncurses/helloCurses.cpp:19: undefined reference to `__imp_endwin'
collect2.exe: error: ld returned 1 exit status
Build finished with error(s).
As far as I understand the linker will not find the ncurses library. This should be libncurses.a or libncurses.dll.
These files are in the directory C:\msys64\mingw64\lib.
In the end i like to compile with VSCode tasks.json, but to begin with, the commandline
gcc -I C:\msys64\mingw64\include\ncurses -L C:\msys64\mingw64\lib -lncurses helloCurses.cpp -o helloCurses.exe
didn't work either and still gives me the same errormessage.
I have been pointed to
Why does the order in which libraries are linked sometimes cause errors in GCC?
I'm sure this will at some point become valuable information, but right now this isn't about the order of a multitude of probably codependent libraris. This is just about how to include a very first additional library not being basic enough to be includd by a simple
#include <stdio.h>, but still basic enough to be in the full toolchain being installed bypacman -S --needed base-devel mingw-w64-x86_64-toolchain

Cannot use filesystem::path when compiling with MacPorts LLVM / Clang 15.0.5 on macOS 10.13 or 10.14 [duplicate]

I was trying to out the new filesystem STL library, but for some reason am getting errors. The Clang++7 website indicates that it should support the new filesystem library – indeed clang is running ahead of g++ I believe.
I used some code from another Stack Exchange post, so it should be valid based upon the number of upvotes. This could should go to the specified directory and print all files in that directory. Here is the code.
#include <iostream>
#include <string>
#include <experimental/filesystem>
namespace fs = std::experimental::filesystem;
int main(int argc, char *argv[])
{
std::string path = "/home/.../Downloads";
for (const auto & entry : fs::directory_iterator(path))
{
std::cout << entry.path() << std::endl;
}
}
The error messages I am getting are:
CMakeFiles/filesystem_app.dir/main.cpp.o: In function `main':
/media/.../clangcpp/filesystem_app/main.cpp:13: undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::operator*() const'
/media/.../clangcpp/filesystem_app/main.cpp:13: undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::operator++()'
CMakeFiles/filesystem_app.dir/main.cpp.o: In function `path<std::__cxx11::basic_string<char>, std::experimental::filesystem::v1::__cxx11::path>':
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../../../include/c++/5.5.0/experimental/fs_path.h:198: undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
CMakeFiles/filesystem_app.dir/main.cpp.o: In function `directory_iterator':
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.5.0/../../../../include/c++/5.5.0/experimental/fs_dir.h:188: undefined reference to `std::experimental::filesystem::v1::__cxx11::directory_iterator::directory_iterator(std::experimental::filesystem::v1::__cxx11::path const&, std::experimental::filesystem::v1::directory_options, std::error_code*)'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I made sure to include the experimental/filesystem header instead of just filesystem which removed any red squiggles in Clion. I tried to compile from CLion as well as from the command line. The compilation string I used was:
clang++-7 -Wall -std=c++17 main.cpp -o app
Does anyone have a sense of what is wrong here? In the compile error messages I see the reference to std::experimental::filesystem::v1::__cxx11::.. and I am wondering why this does not say cxx17, but I was not sure if that was the cause of the issue. I explicitly indicated c++17 in the compilation string above.
filesystem is still experimental and requires an extra library.
If you are using libstdc++, link with -lstdc++fs (or target_link_libraries(${PROJECT_NAME} stdc++fs)).
For libc++, use -lc++fs (similar for the CMake command).

How do I link boost to my program?

I downloaded Boost 1.54 and ran bootstrap.bat mingw. Then I tried to run the program below. I am getting the error you see below. I have tried copying my boost folder into the mingw include folder and I have tried linking my file to the boost/stage/lib folder, but I have not been successful. I see a lot of questions similar to this question, but none of them explain how to get the link the boost folder to the file.
Do I have to copy the boost folder to a different directory? Do I have to change my path variable? How can I get the boost library to link to my code?
Code
#include <boost/filesystem.hpp>
#include <iostream>
using namespace std;
using namespace boost::filesystem;
int main()
{
boost::filesystem::directory_iterator iterator(string("."));
for(; iterator != boost::filesystem::directory_iterator(); ++iterator)
{
cout << (iterator->path().filename()) << endl;
}
boost::filesystem::path full_path( boost::filesystem::current_path() );
std::cout << "Current path is : " << full_path << std::endl;
return 0;
}
Error
C:\Users\212340~1\AppData\Local\Temp\ccZA7umT.o:playground.cc:(.text+0xa4): undefined reference to `boost::filesystem::path::filename() const'
C:\Users\212340~1\AppData\Local\Temp\ccZA7umT.o:playground.cc:(.text+0x244): undefined reference to `boost::system::generic_category()'
C:\Users\212340~1\AppData\Local\Temp\ccZA7umT.o:playground.cc:(.text+0x24e): undefined reference to `boost::system::generic_category()'
C:\Users\212340~1\AppData\Local\Temp\ccZA7umT.o:playground.cc:(.text+0x258): undefined reference to `boost::system::system_category()'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\212340~1\AppData\Local\Temp\ccZA7umT.o: bad reloc address 0x1b in section `.text$_ZNK5boost6system10error_code7messageEv[__ZNK5boost6system10error_code7messageEv]'
collect2.exe: error: ld returned 1 exit status
[Finished in 21.0s with exit code 1]
Answer
boost::system must be linked explicitly. In contrast to many other parts of boost, boost system is not header-only. Thus, you must make sure to link it when you compile. You have two options for linking.
Reference: http://www.boost.org/doc/libs/1_47_0/more/getting_started/unix-variants.html#link-your-program-to-a-boost-library
Option 1
Use -lboost_system (or the equivalent file in your /boost_####/stage/lib/ directory). Of course, you also have to set the library path using -L/file/path/to/libraries unless boost system resides in a standard lookup dir.
Example
g++ playground.cc -o playground -L~/boost/stage/lib/ -libboost_filesystem-mgw48-mt-1_54.a
Option 2
Include the full file path to the library at the end of your code.
Example
Run this from the command line. The triple quotes """ are necessary only for paths that contain spaces.
g++ playground.cc -o playground """C:\My Programs\boost_1_54_0\stage\lib\libboost_filesystem-mgw48-mt-1_54.a""" """C:\My Programs\boost_1_54_0\stage\lib\libboost_system-mgw48-mt-1_54.a"""
Note: For a list of files that are not header-only, see http://www.boost.org/doc/libs/1_47_0/more/getting_started/windows.html#header-only-libraries (Same link as in the first paragraph on "header-only").

Headers not being recognised

The Background
I have the following source code
#include <libubuntuone-1.0/u1-music-store.h>
#include <libsyncdaemon-1.0/libsyncdaemon/libsyncdaemon.h>
static void
get_credentials (U1MusicStore *music_store,
gchar **oauth_consumer_token,
gchar **oauth_consumer_secret,
gchar **oauth_token,
gchar **oauth_token_secret)
{
SyncdaemonCredentials *credentials;
*oauth_consumer_token = *oauth_consumer_secret = *oauth_token = *oauth_token_secret = NULL;
*oauth_consumer_token = g_strdup (syncdaemon_credentials_get_consumer_key (credentials));
*oauth_consumer_secret = g_strdup (syncdaemon_credentials_get_consumer_secret (credentials));
*oauth_token = g_strdup (syncdaemon_credentials_get_token (credentials));
*oauth_consumer_secret = g_strdup (syncdaemon_credentials_get_token_secret (credentials));
}
int main()
{
return 0;
}
and I am compiling it with the following makefile
main: main.o
g++ main.o -o main
main.o: main.cpp
g++ -c main.cpp `pkg-config --cflags --libs gtk+-2.0`
I need to include the pkg-config option since the u1-music-store.h header tried to included gtk/gtk.h, but the compiler isn't able to find it on it's own.
libsyncdaemon.h is a meta-header whose only purpose is to include a larger list of headers, which can be seen below
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-authentication.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-config-interface.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-credentials.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-daemon.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-events-interface.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-file-info.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-filesystem-interface.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-folder-info.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-folders-interface.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-interface.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-publicfiles-interface.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-share-info.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-status-info.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-status-interface.h>
#include <libsyncdaemon-1.0/libsyncdaemon/syncdaemon-transfer-info.h>
My problem
Whenever I try to compile my code, I get the following error:
main.o: In function `get_credentials(_U1MusicStore*, char**, char**, char**, char**)':
main.cpp:(.text+0x34): undefined reference to `syncdaemon_credentials_get_consumer_key'
main.cpp:(.text+0x3c): undefined reference to `g_strdup'
main.cpp:(.text+0x4e): undefined reference to `syncdaemon_credentials_get_consumer_secret'
main.cpp:(.text+0x56): undefined reference to `g_strdup'
main.cpp:(.text+0x68): undefined reference to `syncdaemon_credentials_get_token'
main.cpp:(.text+0x70): undefined reference to `g_strdup'
main.cpp:(.text+0x82): undefined reference to `syncdaemon_credentials_get_token_secret'
main.cpp:(.text+0x8a): undefined reference to `g_strdup'
collect2: ld returned 1 exit status
make: *** [main] Error
Using grep, I've tracked down the four syncdaemon_credentials_get_* functions to syncdaemon-credentials.h, which I would expect the compiler to be able to find since it's listed in libsyncdaemon.h, but for some reason that's not happening. I'm assuming it's for the reason that u1-music-store.h was unable to find gtk/gtk.h that compelled me to use the pkg-config option in my makefile, but I'm having trouble understanding why this is even the case to begin with. If the file's #included, I would expect it to be included by the compiler.
Using grep again I was able to track down g_strdup to a number of headers, but I also discovered that when I replaced by makefile with the single command
g++ main.cpp -o main `pkg-config --cflags --libs gtk+-2.0`
I can eliminate the g_strdup warning, and I'm just left with the function errors.
My question
There are two things I'm looking to know here:
What should my makefile look like in order to solve my specific problem
What is the general solution to my problem? I'm guessing it's something to do with daisy-chaining #include directives together, and having to use pkg-config to fix that, but I'm not sure.
You need to link against libsyncdaemon.so. Get the appropriate arguments from pkg-config ... libsyncdaemon-1.0.
You need to link against libraries that export the required symbols. If there is a .pc file then you can use it to get the appropriate arguments.
"Unresolved external symbol" (MSVC) and "undefined reference to" (GCC) mean that the compiler found the declarations but the linker couldn't find the definitions.
This either means that you forgot to compile and/or link against a .cpp or that you forgot to link against an external library (.lib (Windows) / .a (Unix/Linux)) or object file (.o) which contains said definitions.

undefined referance to LibSerial

So i'm writing a serial transmision program, and have just changed over to using C++, it been a while since I used C++
(I've been working with C recently, and before that java)
Now I need to use LibSerial,
(it seems much simpler to use than C's termios)
my code is:
//gen1.cpp
#include "string2num.h" // a custom header
#include <iostream>
#include <SerialStream.h>
using namespace LibSerial;
//using namespace std;
int main(int argc, char*argv[])
{
if (argc<2)
{
std::cout<<argv[0]<<"requires the device name eg \"dev/tty0\" as a parameter\nterminating.\n";
return 1;
}
SerialStream theSerialStream(argv[1]); //open the device
return 0;
}
When I compile the output:
g++ -Wall -o gen1 gen1.cpp string2num.o
/tmp/cchPBWgx.o: In function `main':
gen1.cpp:(.text+0x121): undefined reference to `LibSerial::SerialStream::SerialStream(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::_Ios_Openmode)'
/tmp/cchPBWgx.o:(.rodata._ZTVN9LibSerial15SerialStreamBufE[vtable for LibSerial::SerialStreamBuf]+0x24): undefined reference to `LibSerial::SerialStreamBuf::showmanyc()'
/tmp/cchPBWgx.o:(.rodata._ZTVN9LibSerial15SerialStreamBufE[vtable for LibSerial::SerialStreamBuf]+0x28): undefined reference to `LibSerial::SerialStreamBuf::xsgetn(char*, int)'
/tmp/cchPBWgx.o:(.rodata._ZTVN9LibSerial15SerialStreamBufE[vtable for LibSerial::SerialStreamBuf]+0x2c): undefined reference to `LibSerial::SerialStreamBuf::underflow()'
/tmp/cchPBWgx.o:(.rodata._ZTVN9LibSerial15SerialStreamBufE[vtable for LibSerial::SerialStreamBuf]+0x34): undefined reference to `LibSerial::SerialStreamBuf::pbackfail(int)'
/tmp/cchPBWgx.o:(.rodata._ZTVN9LibSerial15SerialStreamBufE[vtable for LibSerial::SerialStreamBuf]+0x38): undefined reference to `LibSerial::SerialStreamBuf::xsputn(char const*, int)'
/tmp/cchPBWgx.o:(.rodata._ZTVN9LibSerial15SerialStreamBufE[vtable for LibSerial::SerialStreamBuf]+0x3c): undefined reference to `LibSerial::SerialStreamBuf::overflow(int)'
collect2: ld returned 1 exit status
make: *** [gen1] Error 1
This is the linker complaining that it cannot find the functions referenced by the libserial header file.
If I look on my Linux system to see how the shared library is called:
$ dpkg -L libserial0
...
/usr/lib/libserial.so.0.0.0
/usr/lib/libserial.so.0
On my system this implies I would add -lserial as a g++ option (aka link with libserial.so) this would turn your compilation command into
g++ -Wall -lserial -o gen1 gen1.cpp string2num.o
Including the header file is not enough - you also need to link with the library that implements SerialStream. Assuming it is a static library called serstream.a (it is almost certainly actually called something else):
g++ -Wall -o gen1 gen1.cpp string2num.o serstream.a
old thread, but i still use Libserial. here the completed answer
My working setup.
Ubuntu 18.04
g++ 7.3.0
1) Install package for libserial
apt install libserial-dev
2) check for your headers(.h) and .so files
dpkg -l libserial0
dpkg -l libserial-dev
the first command give you the directory of shared library and the second gives you the headers location.
3) Your code.
I have to change a little your code, first i delete the custom header and modifing the constuctor call to this.
SerialStream theSerialStream;
4) compile with g++
Here my compiling command
g++ -o test -I/usr/include test.cpp -L/usr/lib/x86_64-linux-gnu -lserial -lpthread
check for the -lpthread linking option, beacuse Libserial uses mutex.
In Ubuntu/Debian make sure you have to libserial-dev package installed and use the '-lserial' flag for gcc.