MSYS2 Groß-und Kleinschreibung und beinhaltet auf XP?

Question

Ich versuche, ein Projekt auf XP mit MSYS2 (msys2-base-i686-20160205.tar.xz) zu kompilieren. Eine der Dateien enthalten ist, wie:

/z/path/to/libA/Include/A/B/String.h 

Diese Datei, die wiederum macht in seiner Linie 34:

#include <string.h> 

Diese Datei existiert bereits als, sagen:

Z:/msys32/mingw32/i686-w64-mingw32/include/string.h 

. .. wo das Z: Laufwerk ist auch der Ort meines Codes. Auf meiner Kompilationslinie g++ habe ich -I Z:/msys32/mingw32/i686-w64-mingw32/include zuerst, und nach einer Menge von enthält -I /z/path/to/libA/Include/A/B. Wenn ich jedoch versuche, zu kompilieren, schlägt die Kompilierung fehl, bezogen auf String.h.

So besichtigte ich ein wenig durch -v -E Zugabe (zu „nach der Vorverarbeitungsstufe zu stoppen“) und zu -o File.e am g++ Befehlszeile zu ändern, und kann dies in dem sehe resultierende File.e:

... 
# 34 "Z:/path/to/libA/Include/A/B/String.h" 2 
# 1 "Z:/path/to/libA/Include/A/B/string.h" 1 
# 35 "Z:/path/to/libA/Include/A/B/String.h" 2 
... 

Wie Ich verstehe das, der Präprozessor kommt auf Zeile 34 von Z:/path/to/libA/Include/A/B/String.h, sieht die #include <string.h>, beginnt im aktuellen Verzeichnis nach string.h zu suchen - und findet es, auch wenn es unter solch einem Namen nicht existiert !? Ja, wenn ich von der MSYS2 bash Shell tun:

$ find Z:/path/to/libA/Include/A/B/ -name 'string.h' 

... nichts zurückgegeben wird (während String.h, aktiviert, gefunden wird); aber wenn ich zwingen, eine Liste entweder mit dem nicht aktivierten oder aktivierten Name:

$ ls -la Z:/path/to/libA/Include/A/B/String.h 
-rw-r--r-- 1 User None 2885 May 31 09:45 Z:/path/to/libA/Include/A/B/String.h 

$ ls -la Z:/path/to/libA/Include/A/B/string.h 
-rw-r--r-- 1 User None 2885 May 31 09:45 Z:/path/to/libA/Include/A/B/string.h 

... dann werden sie beide als vorkommend berichtet ?!

Ich vermute, das ist was "verwirrt" g++, in dem Sinne, dass es verhindert wird, nach string.h (winzige Buchstaben) an anderer Stelle/im Systempfad zu suchen. Da habe ich Git-windows case sensitive file names not handled properly und gefunden:

• https://cygwin.com/cygwin-ug-net/using-specialnames.html

Während NTFS (und einige entfernten Dateisysteme) Support-Fall-Empfindlichkeit, der NT-Kernel ab Windows XP nicht standardmäßig nicht unterstützt . Stattdessen müssen Sie eine Registrierungseinstellung anpassen und neu starten. Aus diesem Grund kann die Groß-/Kleinschreibung von Cygwin nicht unterstützt werden, es sei denn, Sie ändern diesen Registrierungswert.
Wenn Sie wirklich Groß- und Klein in Cygwin möchten, können Sie es einschalten, indem Sie den Registrierungswert
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\obcaseinsensitive
auf 0 und starten Sie den Rechner zu setzen.

... und ich tat dies, aber ich habe immer noch das gleiche Problem; nicht sicher, ob dies daran liegt, dass ich MINGW auf MSYS2 verwende (nicht Cygwin); oder weil sich Ressourcen wie Enable case sensitive behavior with Windows XP and Interix Subsystem or SFU auf HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Kernel\ObCaseInsensitive beziehen (Anmerkung, Großschreibung); Allerdings hatte ich bereits diese Schlüssel (ich habe es einfach auf 0 gesetzt und neu gestartet), und sie waren mit winzigen Buchstaben, wie im cygwin.com-Link. Auch nach dem Neustart getestet, hat dies nicht geholfen.

Während How can I make MinGW case-sensitive for included header file names zeigt dies nicht möglich sein kann, zu lösen - gibt es alles, was ich dieses Problem zu beheben tun können, und g++ zu überzeugen, die string.h vom Systemstandort zu lesen? Ich habe versucht, die gleiche Bibliothek auf einem anderen Computer, Windows 7 oder 8 Remote-Desktop, mit der gleichen MingW-Version, wo es funktioniert - so etwas sollte möglich sein, zu tun ...

Answer 1

Hinzufügen -I Z:/msys32/mingw32/i686-w64-mingw32/include an den Anfang Ihrer Die Befehlszeile funktionierte nicht, da dieses Verzeichnis bereits in der GCC-Liste der System-Include-Verzeichnisse enthalten ist. Ich bin mir nicht sicher warum, aber das ist dokumentiertes Verhalten von GCC.

Die beste Lösung besteht darin, die Headerdatei in dieser Bibliothek umzubenennen und alle Includes umzubenennen, die versuchen, sie zu verwenden. Alternativ verwenden Sie -I /z/path/to/libA/Include/ zusammen mit #include <A/B/String.h>. Die Ordnernamen in der Direktive #include stellen sicher, dass der Bibliotheksheader anstelle des Systemheaders enthalten ist.