Discussion:
[Sdcc-user] Compiling SDCC with MSYS2/MINGW
Stephen Whittle
2017-04-28 06:18:54 UTC
Permalink
Hello everybody,
Running into a strange issue trying to compile SDCC with the msys2
environment.
I've successfully downloaded gputils from source and compiled:

$ gcc -v

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

gpasm-1.5.0 #1285
(Apr 28 2017)

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-ucsim
(essentially, enable stm8 and PIC but nothing else)
STM8 and pic14 seem to build without errors, but it looks like something in
the pic16 lib is invoking gpasm incorrectly, as all of the 18f* file
command lines result 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:

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

Does anybody have any suggestions for how I can diagnose this?
Thanks,
Stephen
alvin albrecht
2017-05-03 20:27:49 UTC
Permalink
I’m seeing some odd behaviour in a change from 9880 to 9889 where some peephole rules are applied while others are not for user supplied peephole rules on a z80 target.

The sdcc invoke uses the form: “--no-peep --peep-file peep.def”. Some rules are applied and others are not.

The results we see are compiled binaries that are several kb larger.

Can anyone think of something specific in there that might cause such behaviour? I’m still investigating so if I find it I will write back.
alvin albrecht
2017-05-03 21:00:00 UTC
Permalink
Of course I found the problem in the very next thing I checked.

The patch applied for https://sourceforge.net/p/sdcc/bugs/2600/
is incorrect and I will file there shortly.
Maarten Brock
2017-05-14 15:44:35 UTC
Permalink
> Hello everybody,
> Running into a strange issue trying to compile SDCC with the msys2
> environment.
> I've successfully downloaded gputils from source and compiled:
>
> $ gcc -v
>
> <snip>
> gcc version 6.3.0 (Rev2, Built by MSYS2 project)
> $ gpasm -v
>
> gpasm-1.5.0
> #1285
> (Apr 28 2017)
>
> 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-ucsim
> (essentially, enable stm8 and PIC but nothing else)
> STM8 and pic14 seem to build without errors, but it looks like something
> in
> the pic16 lib is invoking gpasm incorrectly, as all of the 18f* file
> command lines result 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:
>
> 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
>
> Does anybody have any suggestions for how I can diagnose this?
> Thanks,
> Stephen

Hello Stephen,

Can you modify the makefile to make SDCC more verbose using --verbose ? It
will print the way gpasm is called.

Maarten
Stephen Whittle
2017-05-15 10:00:12 UTC
Permalink
Hello Maarten,
Thank you for pointing me towards looking at the driver's output more
closely.
I eventually narrowed things down. In sdcc/device/lib/pic16/configure.ac
(and evidently in the corresponding configure script) we have

line 60: 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.

Commenting out the AC_SUBST line in the pic14, pic16, and non-free pic16
configure 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, but evidently this is sub-optimal.
Is there a way to tell sdcc it is being run during an SDCC compilation, and
so it should look within its own folder? Should I be building SDCC in two
stages instead?
With regards to the commented lines - does wrapping the executable in
single quotes serve a purpose? Is it worth me sending in a patch for the
changes?


Secondly, in my original post I indicated that STM8 support was building
OK. Unfortunately this is not the case, but the build process doesn't error
out.

../../../bin/sdar -rcD ../build/stm8/stm8.lib setjmp.rel _mulint.rel
__mulsint2slong.rel _divsint.rel _modsint.rel _mullong.rel _divulong.rel
_modulong.rel _divslong.rel _modslong.rel _fast_long_neg.rel heap.rel
strcpy.rel strcmp.rel memcpy.rel _atof.rel _schar2fs.rel _sint2fs.rel
_slong2fs.rel _uchar2fs.rel _uint2fs.rel _ulong2fs.rel _fs2schar.rel
_fs2sint.rel _fs2slong.rel _fs2uchar.rel _fs2uint.rel _fs2ulong.rel
_fsadd.rel _fsdiv.rel _fsmul.rel _fssub.rel _fseq.rel _fsgt.rel _fslt.rel
_fsneq.rel fabsf.rel frexpf.rel ldexpf.rel expf.rel powf.rel sincosf.rel
sinf.rel cosf.rel logf.rel log10f.rel sqrtf.rel tancotf.rel tanf.rel
cotf.rel asincosf.rel asinf.rel acosf.rel atanf.rel atan2f.rel sincoshf.rel
sinhf.rel coshf.rel tanhf.rel floorf.rel ceilf.rel modff.rel errno.rel
isinf.rel isnan.rel _mulschar.rel _divschar.rel _modschar.rel
_rrulonglong.rel _rrslonglong.rel _rlulonglong.rel _rlslonglong.rel
_mullonglong.rel _divslonglong.rel _divulonglong.rel _modslonglong.rel
_modulonglong.rel isalnum.rel isalpha.rel isblank.rel iscntrl.rel
isdigit.rel isgraph.rel islower.rel isprint.rel ispunct.rel isspace.rel
isupper.rel isxdigit.rel tolower.rel toupper.rel atoi.rel atol.rel
atoll.rel abs.rel labs.rel rand.rel _strcat.rel _strchr.rel _strcspn.rel
_strncat.rel _strncmp.rel strxfrm.rel _strncpy.rel _strpbrk.rel
_strrchr.rel _strspn.rel _strstr.rel _strtok.rel _memchr.rel _memcmp.rel
_memset.rel aligned_alloc.rel calloc.rel malloc.rel realloc.rel free.rel
mblen.rel mbtowc.rel wctomb.rel mbstowcs.rel wcstombs.rel mbrtoc16.rel
c16rtomb.rel mbrtoc32.rel c32rtomb.rel wcscmp.rel wcslen.rel btowc.rel
wctob.rel mbsinit.rel mbrlen.rel mbrtowc.rel wcrtomb.rel printf_large.rel
puts.rel gets.rel assert.rel time.rel _itoa.rel _ltoa.rel _startup.rel
_strlen.rel _memmove.rel sprintf.rel vprintf.rel
make[5]: *** [Makefile:66: ../build/stm8/stm8.lib] Segmentation fault
make[5]: *** Deleting file '../build/stm8/stm8.lib'
make[5]: Leaving directory '/c/source/sdcc/sdcc/device/lib/stm8'
make[4]: [Makefile:408: port-specific-objects] Error 2 (ignored)

<compilation continues>

Through a process of elimination I was able to determine that the segfault
is caused by any of the .rel files from _atof.rel onwards. For example:

$ ../../../bin/sdar -rcD ../build/stm8/stm8.lib vprintf.rel
Segmentation fault

This looks similar to "#1903 compile of library file cause seg violation"
(that one also mentions _atof.rel). Would you like me to raise a ticket for
it, start another email thread (given the issues are both mingw related,
but target different architectures) or shall we continue the discussion
here alongside the other MINGW compilation issue?

Thanks,

Stephen





On Mon, May 15, 2017 at 1:44 AM, Maarten Brock <***@dse.nl>
wrote:

> > Hello everybody,
> > Running into a strange issue trying to compile SDCC with the msys2
> > environment.
> > I've successfully downloaded gputils from source and compiled:
> >
> > $ gcc -v
> >
> > <snip>
> > gcc version 6.3.0 (Rev2, Built by MSYS2 project)
> > $ gpasm -v
> >
> > gpasm-1.5.0
> > #1285
> > (Apr 28 2017)
> >
> > 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-ucsim
> > (essentially, enable stm8 and PIC but nothing else)
> > STM8 and pic14 seem to build without errors, but it looks like something
> > in
> > the pic16 lib is invoking gpasm incorrectly, as all of the 18f* file
> > command lines result 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:
> >
> > 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
> >
> > Does anybody have any suggestions for how I can diagnose this?
> > Thanks,
> > Stephen
>
> Hello Stephen,
>
> Can you modify the makefile to make SDCC more verbose using --verbose ? It
> will print the way gpasm is called.
>
> Maarten
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Sdcc-user mailing list
> Sdcc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
Maarten Brock
2017-05-15 11:47:50 UTC
Permalink
Hello Stephen,

Please file a bug report (or several) in our bug tracker.

Maarten

> Hello Maarten,
> Thank you for pointing me towards looking at the driver's output more
> closely.
> I eventually narrowed things down. In sdcc/device/lib/pic16/configure.ac
> (and evidently in the corresponding configure script) we have
>
> line 60: 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.
>
> Commenting out the AC_SUBST line in the pic14, pic16, and non-free pic16
> configure 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, but evidently this is sub-optimal.
> Is there a way to tell sdcc it is being run during an SDCC compilation,
> and
> so it should look within its own folder? Should I be building SDCC in two
> stages instead?
> With regards to the commented lines - does wrapping the executable in
> single quotes serve a purpose? Is it worth me sending in a patch for the
> changes?
>
>
> Secondly, in my original post I indicated that STM8 support was building
> OK. Unfortunately this is not the case, but the build process doesn't
> error
> out.
>
> ../../../bin/sdar -rcD ../build/stm8/stm8.lib setjmp.rel _mulint.rel
> __mulsint2slong.rel _divsint.rel _modsint.rel _mullong.rel _divulong.rel
> _modulong.rel _divslong.rel _modslong.rel _fast_long_neg.rel heap.rel
> strcpy.rel strcmp.rel memcpy.rel _atof.rel _schar2fs.rel _sint2fs.rel
> _slong2fs.rel _uchar2fs.rel _uint2fs.rel _ulong2fs.rel _fs2schar.rel
> _fs2sint.rel _fs2slong.rel _fs2uchar.rel _fs2uint.rel _fs2ulong.rel
> _fsadd.rel _fsdiv.rel _fsmul.rel _fssub.rel _fseq.rel _fsgt.rel _fslt.rel
> _fsneq.rel fabsf.rel frexpf.rel ldexpf.rel expf.rel powf.rel sincosf.rel
> sinf.rel cosf.rel logf.rel log10f.rel sqrtf.rel tancotf.rel tanf.rel
> cotf.rel asincosf.rel asinf.rel acosf.rel atanf.rel atan2f.rel
> sincoshf.rel
> sinhf.rel coshf.rel tanhf.rel floorf.rel ceilf.rel modff.rel errno.rel
> isinf.rel isnan.rel _mulschar.rel _divschar.rel _modschar.rel
> _rrulonglong.rel _rrslonglong.rel _rlulonglong.rel _rlslonglong.rel
> _mullonglong.rel _divslonglong.rel _divulonglong.rel _modslonglong.rel
> _modulonglong.rel isalnum.rel isalpha.rel isblank.rel iscntrl.rel
> isdigit.rel isgraph.rel islower.rel isprint.rel ispunct.rel isspace.rel
> isupper.rel isxdigit.rel tolower.rel toupper.rel atoi.rel atol.rel
> atoll.rel abs.rel labs.rel rand.rel _strcat.rel _strchr.rel _strcspn.rel
> _strncat.rel _strncmp.rel strxfrm.rel _strncpy.rel _strpbrk.rel
> _strrchr.rel _strspn.rel _strstr.rel _strtok.rel _memchr.rel _memcmp.rel
> _memset.rel aligned_alloc.rel calloc.rel malloc.rel realloc.rel free.rel
> mblen.rel mbtowc.rel wctomb.rel mbstowcs.rel wcstombs.rel mbrtoc16.rel
> c16rtomb.rel mbrtoc32.rel c32rtomb.rel wcscmp.rel wcslen.rel btowc.rel
> wctob.rel mbsinit.rel mbrlen.rel mbrtowc.rel wcrtomb.rel printf_large.rel
> puts.rel gets.rel assert.rel time.rel _itoa.rel _ltoa.rel _startup.rel
> _strlen.rel _memmove.rel sprintf.rel vprintf.rel
> make[5]: *** [Makefile:66: ../build/stm8/stm8.lib] Segmentation fault
> make[5]: *** Deleting file '../build/stm8/stm8.lib'
> make[5]: Leaving directory '/c/source/sdcc/sdcc/device/lib/stm8'
> make[4]: [Makefile:408: port-specific-objects] Error 2 (ignored)
>
> <compilation continues>
>
> Through a process of elimination I was able to determine that the segfault
> is caused by any of the .rel files from _atof.rel onwards. For example:
>
> $ ../../../bin/sdar -rcD ../build/stm8/stm8.lib vprintf.rel
> Segmentation fault
>
> This looks similar to "#1903 compile of library file cause seg violation"
> (that one also mentions _atof.rel). Would you like me to raise a ticket
> for
> it, start another email thread (given the issues are both mingw related,
> but target different architectures) or shall we continue the discussion
> here alongside the other MINGW compilation issue?
>
> Thanks,
>
> Stephen
>
>
>
>
>
> On Mon, May 15, 2017 at 1:44 AM, Maarten Brock <***@dse.nl>
> wrote:
>
>> > Hello everybody,
>> > Running into a strange issue trying to compile SDCC with the msys2
>> > environment.
>> > I've successfully downloaded gputils from source and compiled:
>> >
>> > $ gcc -v
>> >
>> > <snip>
>> > gcc version 6.3.0 (Rev2, Built by MSYS2 project)
>> > $ gpasm -v
>> >
>> > gpasm-1.5.0
>> > #1285
>> > (Apr 28 2017)
>> >
>> > 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-ucsim
>> > (essentially, enable stm8 and PIC but nothing else)
>> > STM8 and pic14 seem to build without errors, but it looks like
>> something
>> > in
>> > the pic16 lib is invoking gpasm incorrectly, as all of the 18f* file
>> > command lines result 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:
>> >
>> > 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
>> >
>> > Does anybody have any suggestions for how I can diagnose this?
>> > Thanks,
>> > Stephen
>>
>> Hello Stephen,
>>
>> Can you modify the makefile to make SDCC more verbose using --verbose ?
>> It
>> will print the way gpasm is called.
>>
>> Maarten
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Sdcc-user mailing list
>> Sdcc-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot_______________________________________________
> Sdcc-user mailing list
> Sdcc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sdcc-user
>
Loading...