bug#40072: Incorrect escaping on MinGW 32-bit

[Jeffrey Walton]

On Sun, Mar 15, 2020 at 9:59 AM Bob Friesenhahn
<address@hidden> wrote:
>
> On Sun, 15 Mar 2020, Jeffrey Walton wrote:
>
> > Hi Everyone,
> >
> > I'm working on a MSYS2 system on a Windows 7 host. MSYS2 can be
> > obtained at https://www.msys2.org/. I'm using the environment from
> > msys2-i686-20190524.exe. After installing MSYS2, click the MinGW
> > 32-bit link on the desktop.
> >
> > After configuring Expat (https://github.com/libexpat/libexpat), make
> > is resulting in:
> >
> > libtool: link: gcc -g -O2 -Wall -Wextra -fexceptions -fno-strict-aliasing 
> > -Wmiss
> > ing-prototypes -Wstrict-prototypes -pedantic -Wduplicated-cond 
> > -Wduplicated-bran
> > ches -Wlogical-op -Wrestrict -Wnull-dereference -Wjump-misses-init 
> > -Wdouble-prom
> > otion -Wshadow -Wformat=2 -Wmisleading-indentation -fvisibility=hidden 
> > -DXML_ENA
> > BLE_VISIBILITY=1 -fno-strict-aliasing -o .libs/xmlwf.exe xmlwf-xmlwf.o 
> > xmlwf-xml
> > file.o xmlwf-codepage.o xmlwf-unixfilemap.o  ../lib/.libs/libexpat.dll.a 
> > -L/ming
> > w32/lib
> > ./.libs/lt-xmlwf.c:164:35: error: expected ',' or ';' before 'C'
> >  164 | const char * LIB_PATH_VALUE   = ""C:\\msys32\\home\\Jeffrey 
> > Walton\\libe
> > xpat\\expat\\lib\\.libs";";
>
> In my experience, Autotools has never supported paths which include
> spaces.  This is just too hard to fix given that the shell splits
> arguments on white-space by default.  Even if Autoconf, Automake, and
> Libtool where to somehow fix this problem for a well-crafted package,
> it would almost certainly fail once the configure script uses any
> shell content other than the provided macros.
>
> There was already a challenge to solve given that backslash has
> special meaning to the shell.
>
> For my purposes I made sure that my default Windows login directory
> does not include spaces in the path, but I also created a new
> directory path for builds which does not include spaces in the path
> and has Windows Defender scaning and automatic indexing disabled.

Thanks Bob.

It seems (to me) Libtool is very close to the correct answer.

Taking a page from my experience trying to use the date(1) command
everywhere, I stopped using it. I now supply a small C program that
adds, subtracts, formats and prints dates. I call it from my scripts.
My scripts now work everywhere from AIX, BSDs, OS X, Solaris and
Windows. No putzing around anymore with different OS personalities.

Maybe libtool can do the same. Supply a small C program, compile it
and call it from the libtool scripts. Its would be quite easy to
supply the path in argv[1], and get back either (1) the original name
(no spaces), (2) a short file name or (3) a quoted long file name. If
the path gets split and shows up in pieces across argv[1]...argv[n-1],
then just combine the pieces because you know what is supposed to
happen.

Jeff