#4112 Title: PIC16 library build fails on Windows/MSYS2 because configure embeds single quotes in CCAS

[zeynelsagcan]

Environment:

SDCC trunk r16960

Windows

MSYS2 / MinGW-w64 x86_64

gputils built from source and available in PATH

PIC16 backend (PIC18)

While building the PIC16/PIC18 device libraries, configure detects gpasm correctly:

/r/gputils-code-r1333-trunk-gputils/gpasm/gpasm

However, device/lib/pic16/configure.ac contains:

AC_PATH_PROG(CCAS, gpasm, :)
...
AC_SUBST(CCAS, ['$CCAS'])

This causes config.status / generated Makefiles to store CCAS with embedded single quotes:

CCAS = '/r/gputils-code-r1333-trunk-gputils/gpasm/gpasm'

The resulting SDCC invocation becomes:

--asm="'/r/gputils-code-r1333-trunk-gputils/gpasm/gpasm'"

On native Windows SDCC this fails when the assembler is launched, with:

The system cannot find the path specified.

The build then fails, for example at:

device/lib/pic16/debug/gstack.o

The issue can be reproduced reliably.

As a workaround, overriding CCAS on the make command line:

CCAS=gpasm

produces:

--asm="gpasm"

and allows the PIC18 libraries to build.

A minimal fix is to remove the embedded single quotes from the configure substitution:

--- device/lib/pic16/configure.ac
+++ device/lib/pic16/configure.ac
@@

-AC_SUBST(CCAS, ['$CCAS'])
+AC_SUBST(CCAS, [$CCAS])

After regenerating configure with autoconf, the generated Makefiles contain:

CCAS = /r/gputils-code-r1333-trunk-gputils/gpasm/gpasm

and SDCC is invoked as:

--asm="/r/gputils-code-r1333-trunk-gputils/gpasm/gpasm"

I tested this without any CCAS override.

The complete PIC16/PIC18 library build then succeeds, including libio, libsdcc and startup libraries.

Both configure.ac and the regenerated configure file are included in the attached patch.

[Maarten Brock]

I admit that I don't know anything about autoconf, but it seems weird to only change CCAS and leave LD and AR below that line alone. I also wonder what happens if you have spaces in the path to gpasm, which I assume is why there are quotes there in the first place.

[zeynelsagcan]

Yes, that is exactly the issue I was trying to understand.

CCAS is special here because it is used in two different contexts.

It is used directly by Automake as a shell command:

$(CCAS) ...

but it is also embedded into the SDCC command line:

--asm="$(CCAS)"

With the current substitution:

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

the generated Makefile contains:

CCAS = '/path/to/gpasm'

so the SDCC option becomes:

--asm="'/path/to/gpasm'"

At that point the single quotes are no longer shell quoting; they are literal characters in the assembler name passed to SDCC. This is what breaks the native Windows build.

AR is different. In the generated PIC16 Makefiles I found it being used directly as the archive command, for example:

$(AR) $(ARFLAGS)

so keeping its shell quoting is useful and does not create the same problem.

I also tested the case you mentioned with spaces in the gpasm path. Keeping a quoted CCAS for direct shell use and passing an unquoted raw value to --asm= fixes the original quoting problem, but a path such as:

/r/gputils space/gpasm/gpasm

still fails inside SDCC. setPrefixSuffix() currently determines the program name by scanning only up to the first whitespace:

for (p = arg; (p) && !isblank (p); p++);

and SDCC then tries to execute:

R:/gputils.exe

So paths containing spaces are a separate issue in SDCC's command handling. The quotes in CCAS help when Automake invokes gpasm directly, but they cannot also be embedded into the --asm= value.