Comment arrêter MinGW et MSYS de malmener les noms de chemin donnés en ligne de commande

Question

Sur Windows, je suis en train de compiler un programme pour ARM/Linux en utilisant la suite de compilateurs croisés de CodeSourcery. J'utilise MinGW MSYS comme mon interpréteur de commandes, et très souvent il va déformer mes chemins et noms de chemins. Par exemple, pour construire mon programme, j'invoque

arm-none-linux-gnueabi-gcc.exe -Wall -g \
    -Wl,--dynamic-linker=/usr/lib/myrpath/ld-linux.so.3 \
    -Wl,-rpath=/usr/lib/myrpath \
    -I../targetsysroot/usr/include \
    myprogram.c -o myprogram

Bien sûr, je veux que /usr/lib/myrpath soit inséré textuellement dans l'exécutable myprogram - la cible ARM Linux pour laquelle je compile n'utilise pas MinGW ou MSYS. Mais voici ce qui finit par y aller :

...
0x0000000f (RPATH)            Rpath de la bibliothèque: [C:/MinGW/msys/1.0/lib/myrpath]
...

Pas exactement ce que je voulais. Si j'invoque GCC sur la ligne de commande cmd.exe directement, j'obtiens le bon rpath dans l'exécutable. Si j'invoque GCC sur la ligne de commande MSYS, je reçois le rpath déformé. Si j'invoque GCC avec un Makefile qui est exécuté avec make à partir de la ligne de commande cmd.exe, je reçois toujours un rpath déformé (!)

Auriez-vous des idées sur comment je pourrais désactiver ce comportement agaçant?

Answer 1

Il existe un moyen de supprimer la traduction du chemin en définissant MSYS_NO_PATHCONV=1 dans Windows Git MSys ou MSYS2_ARG_CONV_EXCL="*" dans MSYS2.

Alternativement, vous pouvez définir la variable temporairement uniquement pour cette commande en plaçant l'affectation juste avant la commande elle-même :

MSYS_NO_PATHCONV=1 arm-none-linux-gnueabi-gcc.exe -Wall -g \
    -Wl,--dynamic-linker=/usr/lib/myrpath/ld-linux.so.3 \
    -Wl,-rpath=/usr/lib/myrpath \
    -I../targetsysroot/usr/include \
    myprogram.c -o myprogram

Answer 2

J'ai juste découvert une astuce ingénieuse pour éviter que MSYS/MinGW ne traduise les chemins pour vous.

Si vous utilisez deux barres obliques pour commencer le chemin, alors MSYS ne traduira pas le chemin en format DOS. Ainsi, dans l'exemple de l'OP, l'interrupteur -rpath devrait être spécifié comme ceci :

-Wl,-rpath=//usr/lib/myrpath

Tous les outils Unix/Linux semblent gérer de telles barres obliques superflues sans aucun problème, donc même si le rpath de votre binaire commence par //usr/... je pense que le chargeur fera ce qu'il faut.

Answer 3

Je ne pense pas qu'il y ait de moyen de désactiver cela. MSYS est un fork d'une ancienne version de Cygwin avec plusieurs ajustements visant à améliorer l'intégration avec Windows, la traduction automatique des chemins POSIX lors de l'invocation de programmes natifs Windows étant probablement la plus significative. Le problème est qu'il n'est pas toujours possible de savoir si un argument est un chemin ou autre chose, ou si, comme dans ce cas, il s'agit d'un chemin qui ne devrait pas pour autant être traduit. La traduction est guidée par un ensemble d'heuristiques.

Vous pourriez essayer d'utiliser MinGW make à la place de MSYS make (oui, ce sont deux choses différentes), qui est une version native de make pour Windows sans support ni conversion des chemins POSIX. Installez avec mingw-get install mingw32-make et invoquez avec mingw32-make.

Ou vous pourriez essayer Cygwin, de préférence avec un ensemble d'outils adapté à Cygwin.

Answer 4

En effet, dans le projet original MSYS fourni par MinGW.org, il n'y a aucun moyen de désactiver la conversion des chemins Posix.

C'est pourquoi j'ai fait une petite fork du runtime msys-core qui prend en charge le drapeau MSYS_NO_PATHCONV introduit avec le fork de Git for Windows. De cette manière, vous pouvez utiliser la variable d'environnement MSYS_NO_PATHCONV comme dans Git for Windows mais dans l'original MinGW/MSYS.

Donc pour résumer, pour désactiver cette conversion de chemin Posix :

• Pour MSYS2 (intégré) : MSYS2_ARG_CONV_EXCL="*"
• Pour Git for Windows (intégré) : MSYS_NO_PATHCONV=1
• Pour MinGW.org (avec msys-core-extended) : MSYS_NO_PATHCONV=1.

Answer 5

Export MSYS_NO_PATHCONV=1 était nécessaire dans mon cas sur git-bash sur windows (comme indiqué par dx_over_dt ci-dessus.)