#2616 Single-quoting CCAS variable breaks mingw64 build

[Stephen Whittle]

Compilation of SDCC fails using the current MSYS2/mingw64 environment and toolchain, after downgrading flex to 2.5.8 to avoid https://github.com/westes/flex/issues/162 (as a fixed version is not yet available in MSYS2).

$ gcc -v                                                                                                                                                     <snip>
gcc version 6.3.0 (Rev2, Built by MSYS2 project)                                                                                  

$ gpasm -v                                                                                                                                               gpasm-1.5.0 #1285 (Apr 28 2017)         

I installed gputils from source and set the following environment variables:

export GPUTILS_HEADER_PATH=/mingw64/share/gputils/header
export GPUTILS_LKR_PATH=/mingw64/share/gputils/lkr

I configured SDCC using the following command line
./configure --disable-mcs51-port --disable-z80-port --disable-z180-port --disable-r2k-port --disable-r3ka-port --disable-gbz80-port --disable-tlcs90-port --disable-ds390-port --disable-ds400-port --disable-hc08-port --disable-s08-port --disable-stm8-port --disable-ucsim
(essentially, enable PIC but nothing else).
In the configuration scripts for PIC14 and PIC16 there is the line

AC_SUBST(CCAS, [\'$CCAS\'])

This means that the build system determines CCAS to be /mingw64/bin/gpasm which is then wrapped in single quotes as '/mingw64/bin/gpasm' before other calls append an exe file extension. As a result the command is "'/mingw64/bin/gpasm'.exe "(double quotes excluded).

In SDCCsystem.c:66 we have:

  switch (*p)
    {
    case '\'':
<snip> 

which is splitting the string into a command at the quotation mark as a delimiter, leaving .exe as part of the arguments.

get_path in SDCCsystem.c:201 then adds an extra ".exe" onto our now extension-less command, which is then merged in with our arguments, so the compiler driver attempts to execute

"/mingw64/bin/gpasm.exe .exe <options>" which obviously fails, resulting in the usage information for gpasm being printed and the build consequently fails with missing object files.
The error lines all have the following format:</options>

source='fake_sspbuf.c' object='libdev18f1220_a-fake_sspbuf.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
'/c/source/sdcc/device/non-free/lib/pic16//../../../../bin/sdcc' -DHAVE_CONFIG_H -I. -I..  -I. -I../../../../include/pic16 -I../../../../non-free/include/pic16  -p18f1220 --std-c99 --asm="'/mingw64/bin/gpasm'" --no-warn-non-free --fomit-frame-pointer --obanksel=9 --denable-peeps --optimize-cmp --optimize-df --i-code-in-asm -DUSE_FLOATS=0 -mpic16 -p18f452 -c -o libdev18f1220_a-fake_sspbuf.o `test -f 'fake_sspbuf.c' || echo './'`fake_sspbuf.c

Usage: gpasm [options] file
Options: [defaults in brackets after descriptions]
  -a FMT, --hex-format FMT       Select hex file format. [inhx32]
  -c, --object                   Output relocatable object.
 <gpasm usage info follows>

Build fails much later with error:

error: "libdev18f1220_a-pic18f1220.o" is not a valid object file

You will notice the nested single quotes inside the double quotes being used for the --asm argument.

Commenting out the aforementioned lines in the configure.ac files allows compilation to succeed, with one small caveat:
the driver also calls sdcpp.exe as part of compiling the pic14/16 device libraries - sdcpp has just been built and is therefore not in the PATH.
I have worked around this by temporarily setting the root sdcc source directory as SDCC_HOME ( export SDCC_HOME=/c/source/sdcc/sdcc) during make, but evidently this is sub-optimal and interferes with 'make install'. I expect there's a two-stage compilation process I'm unaware of that obviates the need for this, so it isn't really part of the bug report, but I include it in case it is necessary for repro.