#3776 memcpyx.c at 1: error 119:...extension unsupported

[Barry Jackson]

Any clues as to why we are seeing this error during build?

make[5]: Leaving directory '/home/baz/rpmbuild/BUILD/sdcc-4.4.0/device/lib/ds400'
make[5]: Entering directory '/home/baz/rpmbuild/BUILD/sdcc-4.4.0/device/lib/ds400'
../../../bin/sdcc -c -mds400 -I./../../include -I./../../include/ds400 1 --std-c23 memcpyx.c
at 1: error 119: don't know what to do with file '1'. file extension unsupported
make[5]: *** [Makefile:53: memcpyx.rel] Error 1

[Philipp Klaus Krause]

Not really.

Rephrased, your question is: "where does that '1'1 in '../../../bin/sdcc -c -mds400 -I./../../include -I./../../include/ds400 1 --std-c23 memcpyx.c' come from?"

Looking at my sdcc/device/ds400/Makefile.in, I see a line "CFLAGS = -mds400 $(CPPFLAGS) $(VERBOSE) --std-c23", so mostlikely there is something wrong with your CPPFLAGS or VERBOSE. Maybe you have an export VERBOSE=1 in your environment that somehow makes it into the device library build process?

Interestingly, only the ds390 and ds400 library Makefiles do have that $(VERBOSE) in their compiler invokations. I wonder if we could just remove it.

[Barry Jackson]

I have tried removing the $(VERBOSE) from both ds400 and ds390 but the build still errors out after those two but with no useful info as to why.
Link to the build log here:

http://mtf.duckdns.org/pub/linux/barjac/distrib/cauldron/x86_64/log/sdcc-4.4.0-1.mga.src.rpm/build.x86_64.0.20240904222804.log

I had previously tried excluding all the ports that appeared to break the build with:
-- disable-ds390-port \
--disable-ds400-port \
--disable-z80-port \
--disable-mos6502-port \
--disable-mos65c02-port \
--disable-ms08-port \
--disable-s08-port \
--disable-hc08-port \
Some of the above had caused segmentation faults during the build.

However with the above exclusions the build still failed with no real clues as to why :

http://mtf.duckdns.org/pub/linux/barjac/distrib/cauldron/x86_64/log/sdcc-4.4.0-1.mga.src.rpm/build.x86_64.0.20240903222846.log

[Philipp Klaus Krause]

Your first log shows a segfault while building the hc08 library.
The second log shows a segfault while building the z180 library.
These shouldn't happen. After all, the 4.4.0 release, as usual for releases, got built and tested on plenty of systems (GNU/Linux on multiple architectures, FreeBSD on aarch64, OpenBSD, Hurd, macOS) where it worked without problems.
It looks like there is something wrong with your system, or we do have a bug in SDCC that only gets triggered on your system.

[Barry Jackson]

Sorry I missed the segfaults, I don't understand why those did not stop the build or at least produce an 'error:' . Maybe down to one of the ||: in the makefiles.

Do you have a list of versions of the software (e.g. gcc glibc etc.) used in the build chroot for your test builds?

The base-system build chroot here is using these versions:
http://mtf.duckdns.org/pub/linux/barjac/distrib/cauldron/x86_64/log/sdcc-4.4.0-1.mga.src.rpm/rpm_qa.x86_64.0.20240904222804.log

I will test builds of 4.4.0 for earlier distro versions using older tools and report back.

[Philipp Klaus Krause]

SDCC 4.4.0 will not build (unless you disable the pic ports) with GCC 14 / clang 19. Earlier host compiler versions should work: AFAIK the compile farm has machines using at least GCC 6.3.0, 7.5.0, 10.3.0, 13.2.0, and clang 14.0.5, glibs 2.24, 2.33, 2.37, 2.39, and the FreeBSD 13.2 libc.

So I don't think these would be a problem. However, you might want to check your boost version. I strongly recommend to use boost 1.81.0 or later, but not boost 1.85.0. We found serious bugs in boost 1.85.0 and boost earlier than 1.81.0, that did cause segfaults on some systems (the issue in boost earlier than 1.81.0 was sporadic on some GNU/Linux systems, but reproducible on Hurd x86, the 1.85.0 issue was reproducible on GNU/Linux amd64).

[Barry Jackson]

Sorry I did not see your above until after I posted the message below, Thanks for all the pointers regarding boost (always seems to make life difficult!) I will see what can be done.
I am wondering if we should stay at 4.2.0? I have not yet tried a re-build of that in Mageia 10.

[Philipp Klaus Krause]

Staying with 4.2.0 won't help: SDCC has been using boost::flat_multimap since at least SDCC 3.8.0, so SDCC 4.2.0 wouldn't work with boost 1.85.0 either.

P.S.: If you can't avoid boost 1.85.0, using std::multimap instead of boost:flat_multimap should work, but would come at a performance penalty.

[Barry Jackson]

Building for Mageia 9 the build completes without segfaults or compilation errors using the same rpm spec file as used in the 'first' log above which produced the segfaults and does not exclude any devices.
http://mtf.duckdns.org/pub/linux/barjac/distrib/9/x86_64/log/sdcc-4.4.0-1.mga9_bcj.src.rpm/build.x86_64.0.20240905082408.log

The packages list for this chroot:
http://mtf.duckdns.org/pub/linux/barjac/distrib/9/x86_64/log/sdcc-4.4.0-1.mga9_bcj.src.rpm/rpm_qa.x86_64.0.20240905082408.log

The issues seem to only appear using the newer system package versions in the upcoming Mageia 10 release as listed in my previous post.

[Philipp Klaus Krause]

Comparing those package versions, I think your problem is this boost 1.85.0 bug: https://github.com/boostorg/container/issues/281

[Barry Jackson]

OK thanks I will investigate.

[Barry Jackson]

We have now patched boost-1.85.0 which has resolved the issues - many thanks :)

[Philipp Klaus Krause]

That confirms that this is a duplicate of [bugs:#3739].