<filesystem> gcc 8.1.0



  • Weil ich mich gerade etwas ärgere habe ich den Start mal aufgenommen.

    https://youtu.be/NqgJ3JQbE9s

    Wenn mir jetzt jemand sagt, was ich dort falsch gemacht habe, werde ich in Demut eine Weile in mich gehen.



  • @lemon03 sagte in <filesystem> gcc 8.1.0:

    Weil ich mich gerade etwas ärgere habe ich den Start mal aufgenommen.

    https://youtu.be/NqgJ3JQbE9s

    Wenn mir jetzt jemand sagt, was ich dort falsch gemacht habe, werde ich in Demut eine Weile in mich gehen.

    Du hast im Menü "Start Debugging" (F5) ausgewählt. In diesem Fall wird die Konsole nicht automatisch offen gehalten. Im Debug-Modus kannst du einen Breakpoint ans Programmende setzen wenn du die Konsole offen halten willst.

    Wenn du stattdessen "Start without Debugging" (Ctrl+F5) wählst, wartet er automatisch auf einen Tastendruck nach Programmende.

    Ctrl+F5 startet das Programm auch ein klein wenig flotter und ist bei mir zumindest der Standard, wenn ich das, was ich gerade eben programmiert habe testen will.

    Ich finde es auch etwas ungünstig, dass der grosse, einladende "Play-Button" für den Debugger steht, der die Konsole direkt zumacht. Man kann da schnell den Eindruck bekommen, dass VS nichts anderes kennt. Daher sieht man wohl auch so oft die system("PAUSE")-Krücke in Anfängercode 😉



  • @Finnegan

    Du hast im Menü "Start Debugging" (F5) ausgewählt. In diesem Fall wird die Konsole nicht automatisch offen gehalten. Im Debug-Modus kannst du einen Breakpoint ans Programmende setzen wenn du die Konsole offen halten willst.

    Das stimmt so nicht mehr. In VS 2017 wird auch im Debugger die Konsole nicht geschlossen. Das kann in den Einstellungen auch anders konfiguriert werden. Allerdings war das Verhalten nach dem Einspielen von Patches auch mal anders. Seit 17.9 ist es bei mir bisher immer aktiv.



  • @spiri sagte in <filesystem> gcc 8.1.0:

    Hast du stdc++fs verlinkt?

    Versuchs mal mit dem Experimental-Header (#include <experimental/filesystem>)

    Ich habe des starken Verdacht, dass die <filesystem>-Unterstützung der libstdc++ unter Windows immer noch unvollständig ist. Ich verwende einen selbst kompilierten GCC 8.2.0 mit Backport-Patches für <filesystem> sowie einen ein paar Tage alten GCC 9 aus dem Entwicklungs-Branch, welche auf der C-Standardbibliothek von MinGW aufbauen. Beide haben zwar beim Kompilieren eine libstdc++fs.a erzeugt und laufen bei einem #include <filesystem> auch nicht auf irgendwelche Fehler, allerdings beschwert sich der Linker, dass anscheinend einige Implementationen diverser Funktionen fehlen (mit -lstdc++fs (!)):

    #include <iostream>
    #include <filesystem>
    
    namespace fs = std::filesystem;
    
    auto main() -> int
    {
        for (auto& entry : fs::directory_iterator("C:\\"))
            std::cout << entry.path() << std::endl;
        return 0;
    }
    
    undefined reference to `std::filesystem::__cxx11::directory_iterator::operator*() const'
    undefined reference to `std::filesystem::__cxx11::directory_iterator::operator++()'
    undefined reference to `std::filesystem::__cxx11::filesystem_error::_M_gen_what()'
    undefined reference to `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&, std::filesystem::directory_options, std::error_code*)'
    undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
    undefined reference to `std::filesystem::__cxx11::filesystem_error::~filesystem_error()'
    undefined reference to `vtable for std::filesystem::__cxx11::filesystem_error'
    

    Schade. Das sieht so aus als bräuchte die libstdc++ noch etwas Arbeit. Möglicherweise sind auch nur ein paar #defines nicht ganz so wie sie sein sollen. Soweit ich das beurteilen kann ist das kein MinGW-Problem (nur eine C-Standardbibliothek und Import-Bibliotheken für die Windows-API), sondern eine fehlende Unterstützung seitens der libstdc++.

    Es scheint als müsse man sich mit MinGW-basierten Compilern noch weiter gedulden oder eben boost::filesystem verwenden. Zum Trost kann man dann stattdessen mit dem MinGW-GCC schon mit Concepts arbeiten 😉



  • @manni66 sagte in <filesystem> gcc 8.1.0:

    Das stimmt so nicht mehr. In VS 2017 wird auch im Debugger die Konsole nicht geschlossen. Das kann in den Einstellungen auch anders konfiguriert werden. Allerdings war das Verhalten nach dem Einspielen von Patches auch mal anders. Seit 17.9 ist es bei mir bisher immer aktiv.

    Oha, da bin ich tatsächlich nicht mehr auf dem neuesten Stand - zuviel unter Linux gearbeitet in letzter Zeit. Ja, ich habe das gerade nochmal mit VS2017 ausprobiert und bei einer neu erstellten "Console Application" wartet er beim Ausführen wie auch beim Debuggen auf eine Eingabe. Danke für den Hinweis 😉



  • @Finnegan sagte in <filesystem> gcc 8.1.0:

    Wenn du stattdessen "Start without Debugging" (Ctrl+F5) wählst, wartet er automatisch auf einen Tastendruck nach Programmende.

    Ich habe sowohl 'start debugging' als auch 'start without debugging' gewählt, wie im Video zu sehen.

    @Finnegan sagte in <filesystem> gcc 8.1.0:

    Ja, ich habe das gerade nochmal mit VS2017 ausprobiert und bei einer neu erstellten "Console Application" wartet er beim Ausführen wie auch beim Debuggen auf eine Eingabe. Danke für den Hinweis 😉

    Ja, das tut er. Nur kennt er dann wieder kein <filestream>. Sorry, <filesystem>



  • @lemon03 sagte in <filesystem> gcc 8.1.0:

    @Finnegan sagte in <filesystem> gcc 8.1.0:

    Wenn du stattdessen "Start without Debugging" (Ctrl+F5) wählst, wartet er automatisch auf einen Tastendruck nach Programmende.

    Ich habe sowohl 'start debugging' als auch 'start without debugging' gewählt, wie im Video zu sehen.

    Jo, Sorry! Da hab ich tatsächlich zu oberflächlich geschaut, sah auf den ersten Blick so naheliegend aus 😉 ...

    @Finnegan sagte in <filesystem> gcc 8.1.0:

    Ja, ich habe das gerade nochmal mit VS2017 ausprobiert und bei einer neu erstellten "Console Application" wartet er beim Ausführen wie auch beim Debuggen auf eine Eingabe. Danke für den Hinweis 😉

    Ja, das tut er. Nur kennt er dann wieder kein <filestream>.

    ... allerdings sind hier auch ein paar gelöschte Beiträge, so dass ich jetzt nicht nachvollziehen kann, was du geändert hast, so dass er nicht mehr auf eine Eingabe wartet (?). Meinst du mit <filestream> hier jetzt <filesystem> oder etwas anderes?

    Mit einem simplen <filesystem>-Test habe ich unter VS2017 jedenfalls keine Probleme, und auf eine Eingabe nach dem Ausführen/Debuggen wartet er auch:

    #include "pch.h"
    #include <iostream>
    #include <filesystem>
    
    // Siehe: https://docs.microsoft.com/en-us/cpp/standard-library/filesystem?view=vs-2017
    // "As of the release of Visual Studio 2017, the <filesystem> header was not yet a C++ 
    // standard. Visual C++ 2017 implements the final draft standard, found in ISO/IEC 
    // JTC 1/SC 22/WG 21 N4100."
    namespace fs = std::experimental::filesystem::v1; 
    
    auto main() -> int
    {
    	for (auto& entry : fs::directory_iterator("C:\\"))
    		std::cout << entry.path() << std::endl;
    	return 0;
    }
    

    Ausgabe:

    C:\$Recycle.Bin
    C:\Config.Msi
    C:\Documents and Settings
    C:\hiberfil.sys
    C:\pagefile.sys
    C:\swapfile.sys
    C:\Users
    C:\Windows
    ...
    

    Ist jetzt natürlich ein doofes "Works for me". Was hast du denn konkret anders gemacht? Meins ist einfach nur ein neues Konsolen-Projekt mit obigem Code (nichts am Projekt verändert, nur den Default-Code mit dem Code oben ausgetauscht).

    Finnegan



  • Erstens sorry wegen den gelöschten Beträgen, war etwas angefressen und hatte gar nicht mehr damit gerechnet, das das noch jemanden interessiert. Zweitens sorry, das ich jetzt nicht zitiere, Dein Beitrag ist mir im Moment zu groß.

    Was gewesen ist: Hatte in Visual Studio als erstes eine Windows Console Application erstellt, schien mir für mein Projekt naheliegend. Die Konsole blieb ähnlich wie bei CodeBlocks offen. War für mich selbstverständlich. Kannte ja nichts anderes. Dort wurde aber kein <filesystem> erkannt. Also nachgefragt, nachdem es in gcc nicht geht, über boost nur mit eigenartigen Warnungen, und nun auch in Visual Studio nicht.

    Dann festgestellt, das man ein leeres Projekt erstellen muss, damit <filesystem> bekannt ist, nur gab es das "beliebte Anfängerproblem", das die Konsole nicht offen blieb. In der Hoffnung, das man die Ironie dieser Umschreibung erkennt und mir einfach verrät, warum die Konsole nicht offen bleibt, habe ich ganz naiv danach gefragt.

    Und dann nahm das Übel seinen Anfang...

    Wenn bei Dir auch in einer Console Application <filestream> bekannt ist, muss es an den vorkompilierten Headern liegen, die ich als erstes abgeschaltet habe.



  • @lemon03 sagte in <filesystem> gcc 8.1.0:

    Wenn bei Dir auch in einer Console Application <filestream> bekannt ist, muss es an den vorkompilierten Headern liegen, die ich als erstes abgeschaltet habe.

    Nein, auch mit ausgeschalteten PCH und ohne #include "pch.h" läuft das obige Beispiel bei mir genau so wie beschrieben.

    Bezüglich <filestream>: Bist du sicher, dass du nicht <fstream> meinst? Möglich, dass da was an mir vorbei gegangen ist, aber soweit ich weiss gibt es keinen <filestream>-Header.

    Bezüglich des Namespace std::experimental::filesystem::v1: Ohne Änderung am neu erstellten Projekt muss ich diesen experimental-Namespace verwenden. Wenn ich den Sprachstandard unter Project->Properties->C/C++->Language->C++ Language Standard auf /std:c++17 oder /std:c++latest stelle, dann funktioniert es auch mit std::filesystem.

    Getestet mit Microsoft Visual Studio Community 2017, Version 15.8.7 und cl.exe Version 19.15.26730 for x64.



  • Verdammt, eigentlich ist <filestream> ein Schreibfehler von mir, den ich hier schon öfters gemacht habe wie mir scheint. Es soll sich natürlich immer um <filesystem> handeln. Diesen Schreibfehler habe ich wohl auch in Visual Studio gemacht. Keine Ahnung, wie dies geschehen ist.

    Jedenfalls habe ich mir dort das "fehlgeschlagene" Projekt angeschaut, in welchen ich <filesystem> verwenden wollte und dort stand tatsächlich <filestream>.

    Tja, ist etwas peinlich. In einem meiner gelöschten Beiträge habe ich geschrieben ... dann werde ich in Demut eine Weile in mich gehen... Das werde ich nun mal machen.

    Nochmal zusammengefasst:
    In einer Windows Console Application ohne precompiled header ist <filesystem> bekannt und es bleibt die Konsole offen.
    Punkt.

    Danke für das Zurückschieben in die richtige Spur.



  • Ich hatte mit GCC 8.1.0 und <filesystem> auch mal Probleme ... Ich glaube unter Windows zumindest ist/war das broken. Würde GCC 8.2.0 empfehlen. Damit geht's auf jeden Fall.



  • @HarteWare sagte in <filesystem> gcc 8.1.0:

    Ich hatte mit GCC 8.1.0 und <filesystem> auch mal Probleme ... Ich glaube unter Windows zumindest ist/war das broken. Würde GCC 8.2.0 empfehlen. Damit geht's auf jeden Fall.

    Sicher? Dann ist bei meiner selbst gebauten Version wohl was schief gelaufen, oder es fehlte mir ein weiterer Patch, der noch nicht im offziellen GCC9-Branch integriert ist. Werde mir das die Tage nochmal ansehen. "GCC Version soundso für Windows/MinGW" ist ja nicht immer so klar definiert, da gibt es ja etliche Varianten mit teilweise sehr unterschiedlichen Patches - kann mich jedenfalls an kein offizielles GCC-Quellcode-Release erinnern, das sich ungepatcht auf Anhieb überhaupt für Windows bauen ließ 🙂



  • @Finnegan
    MSYS2:

    MINGW64 ~
    $ g++ -v
    Using built-in specs.
    COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe
    COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper.exe
    Target: x86_64-w64-mingw32
    Configured with: ../gcc-8.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
    Thread model: posix
    gcc version 8.2.0 (Rev1, Built by MSYS2 project)
    
    


  • @HarteWare Danke, das scheint der Compiler des MSYS2-Projekts zu sein, bei denen schau ich auch immer gerne vorbei um zu sehen, ob ich vielleicht irgendwelche windows-spezifischen Patches vergessen habe. Mein GCC 8.2.0 sollte eigentlich auf dem selben Patch-Stand sein. Dort habe ich auch <filesystem> und die libstdc++fs. Bei obigem Code-Beispiel führt das aber bei meinem GCC wie erwähnt zu Linker-Fehlermeldungen. Ich werde deren GCC mal ausprobieren und schauen, ob es da läuft. Möglich, dass bei meinem Build irgendwas schiefgelaufen ist, oder es sich um Nebenwirkungen anderer Patches handelt.

    Update: Habe jetzt mal den aktuellen GCC des MSYS2-Projekts getestet, leider läuft dieser auf die selben Linker-Fehler wie meine Version:

    $ pacman -S mingw-w64-x86_64-gcc
    ...
    
    $ g++ -v
    Using built-in specs.
    COLLECT_GCC=C:\msys64\mingw64\bin\g++.exe
    COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.1/lto-wrapper.exe
    Target: x86_64-w64-mingw32
    Configured with: ../gcc-8-20181123/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
    Thread model: posix
    gcc version 8.2.1 20181123 (Rev1, Built by MSYS2 project)
    
    $ cat test.cpp
    #include <iostream>
    #include <filesystem>
    
    namespace fs = std::filesystem;
    
    auto main() -> int
    {
        for (auto& entry : fs::directory_iterator("C:\\"))
            std::cout << entry.path() << std::endl;
        return 0;
    }
    
    $ g++ -std=c++17 -lstdc++fs -otest.exe test.cpp
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.text+0x1d9): undefined reference to `std::filesystem::__cxx11::directory_iterator::operator*() const'
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.text+0x213): undefined reference to `std::filesystem::__cxx11::directory_iterator::operator++()'
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.text$_ZNSt10filesystem7__cxx1116filesystem_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10error_code[_ZNSt10filesystem7__cxx1116filesystem_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10error_code]+0x93): undefined reference to `std::filesystem::__cxx11::filesystem_error::_M_gen_what()'
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.text$_ZNSt10filesystem7__cxx1118directory_iteratorC1ERKNS0_4pathE[_ZNSt10filesystem7__cxx1118directory_iteratorC1ERKNS0_4pathE]+0x28): undefined reference to `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&, std::filesystem::directory_options, std::error_code*)'
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.text$_ZNSt10filesystem7__cxx114pathC1IA4_cS1_EERKT_NS1_6formatE[_ZNSt10filesystem7__cxx114pathC1IA4_cS1_EERKT_NS1_6formatE]+0x61): undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.rdata$.refptr._ZNSt10filesystem7__cxx1116filesystem_errorD1Ev[.refptr._ZNSt10filesystem7__cxx1116filesystem_errorD1Ev]+0x0): undefined reference to `std::filesystem::__cxx11::filesystem_error::~filesystem_error()'
    C:\msys64\tmp\ccvfBIcq.o:test.cpp:(.rdata$.refptr._ZTVNSt10filesystem7__cxx1116filesystem_errorE[.refptr._ZTVNSt10filesystem7__cxx1116filesystem_errorE]+0x0): undefined reference to `vtable for std::filesystem::__cxx11::filesystem_error'
    collect2.exe: error: ld returned 1 exit status
    

    Da scheint also nochwas im argen zu liegen. Ich würde mich sogar zu der Einschätzung hinreißen lassen, dass <filesystem> unter Windows von der libstdc++ derzeit noch nicht vollständg unterstützt wird ... selbst der aktuelle GCC-9-Entwicklungs-Branch hat dasselbe Problem. Es liegt also wahrscheinlich nicht daran, dass nur bei diesem Backport etwas nicht stimmt.

    Update 2: Was mich jetzt wirklich stutzig macht, ist dass selbst mein Windows-zu-Linux-GCC ebenfalls diese Fehler ausspuckt:

    $ x86_64-linux-musl-g++ -std=c++17 -lstdc++fs -otest.exe test.cpp
    C:\Users\XXX~1\AppData\Local\Temp\ccT7c1r7.o: In function `main':
    test.cpp:(.text+0xec): undefined reference to `std::filesystem::__cxx11::directory_iterator::operator*() const'
    test.cpp:(.text+0x125): undefined reference to `std::filesystem::__cxx11::directory_iterator::operator++()'
    C:\Users\XXX~1\AppData\Local\Temp\ccT7c1r7.o: In function `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&)':
    test.cpp:(.text._ZNSt10filesystem7__cxx1118directory_iteratorC2ERKNS0_4pathE[_ZNSt10filesystem7__cxx1118directory_iteratorC5ERKNS0_4pathE]+0x26): undefined reference to`std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&, std::filesystem::directory_options, std::error_code*)'
    C:\Users\XXX~1\AppData\Local\Temp\ccT7c1r7.o: In function `std::filesystem::__cxx11::path::path<char [4], std::filesystem::__cxx11::path>(char const (&) [4], std::filesystem::__cxx11::path::format)':
    test.cpp:(.text._ZNSt10filesystem7__cxx114pathC2IA4_cS1_EERKT_NS1_6formatE[_ZNSt10filesystem7__cxx114pathC5IA4_cS1_EERKT_NS1_6formatE]+0x5e): undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
    collect2.exe: error: ld returned 1 exit status
    

    ...muss nochmal weiter unter Linux testen. -lstdc++fs sollte doch eigentlich ausreichen, oder fehlt da noch irgendeine Compiler-Option?

    Update 3: Lustig. Selbes Problem unter einer VM mit Alpine Linux (Edge):

    alpine-vm:~$ g++ -v
    Using built-in specs.
    COLLECT_GCC=g++
    COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-musl/8.2.0/lto-wrapper
    Target: x86_64-alpine-linux-musl
    Configured with: /home/buildozer/aports/main/gcc/src/gcc-8.2.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --build=x86_64-alpine-linux-musl --host=x86_64-alpine-linux-musl --target=x86_64-alpine-linux-musl --with-pkgversion='Alpine 8.2.0' --enable-checking=release --disable-fixed-point --disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror --disable-symvers --enable-__cxa_atexit --enable-default-pie --enable-default-ssp --enable-cloog-backend --enable-languages=c,c++,objc,fortran,ada --disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer --enable-shared --enable-threads --enable-tls --with-system-zlib --with-linker-hash-style=gnu
    Thread model: posix
    gcc version 8.2.0 (Alpine 8.2.0)
    
    alpine-vm:~$ cat test.cpp
    #include <iostream>
    #include <filesystem>
    
    namespace fs = std::filesystem;
    
    auto main() -> int
    {
        for (auto& entry : fs::directory_iterator("/"))
            std::cout << entry.path() << std::endl;
        return 0;
    }
    
    alpine-vm:~$ g++ -std=c++17 -lstdc++fs -otest test.cpp
    /usr/lib/gcc/x86_64-alpine-linux-musl/8.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/ccCcOCBM.o: in function `main':
    test.cpp:(.text+0x100): undefined reference to `std::filesystem::__cxx11::directory_iterator::operator*() const'
    /usr/lib/gcc/x86_64-alpine-linux-musl/8.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: test.cpp:(.text+0x146): undefined reference to `std::filesystem::__cxx11::directory_iterator::operator++()'
    /usr/lib/gcc/x86_64-alpine-linux-musl/8.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/ccCcOCBM.o: in function `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&)':
    test.cpp:(.text._ZNSt10filesystem7__cxx1118directory_iteratorC2ERKNS0_4pathE[_ZNSt10filesystem7__cxx1118directory_iteratorC5ERKNS0_4pathE]+0x26): undefined reference to `std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path const&, std::filesystem::directory_options, std::error_code*)'
    /usr/lib/gcc/x86_64-alpine-linux-musl/8.2.0/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/ccCcOCBM.o: in function `std::filesystem::__cxx11::path::path<char [4], std::filesystem::__cxx11::path>(char const (&) [4], std::filesystem::__cxx11::path::format)':
    test.cpp:(.text._ZNSt10filesystem7__cxx114pathC2IA4_cS1_EERKT_NS1_6formatE[_ZNSt10filesystem7__cxx114pathC5IA4_cS1_EERKT_NS1_6formatE]+0x6d): undefined reference to `std::filesystem::__cxx11::path::_M_split_cmpts()'
    collect2: error: ld returned 1 exit status
    

    So langsam glaube ich, dass ich etwas sehr triviales übersehe. GCC sollte doch eigentlich <filesystem> schon länger unterstützen, oder? Hat irgendjemand vielleicht eine Idee was hier schief läuft?

    Update 4: Final facepalm! ... -lstdc++fs natürlich als letzte Compiler-Option. Link-Reihenfolge... zuerst die Libs/Objekte die eine Bibliotheksfunktion benötigen und danach die Bibliotheken linken, welche die Funktionen zur Verfügung stellen. Sorry Leute! So viel Text für so etwas triviales produziert. Jetzt funktionierts auch überall 🙂


Log in to reply