I just installed SDCC by building the current trunk code from SVN (4.2.9 #13735), on a clean Fedora 36 system. Unfortunately, I discovered that I cannot build any PIC14 program due to a symbol conflict.
Save the following code as test.c
:
#include <pic12f675.h>
void main (void)
{
return;
}
And build with # sdcc -V -mpic14 -p12f675 --use-non-free test.c
:
+ /usr/local/bin/sdcpp -nostdinc -Wall -std=c11 -D__SDCC_PROCESSOR="12f675" -D__SDCC_PIC12F675 -D__SDCC_PIC14_STACK_SIZE=14 --obj-ext=.o -D__SDCC_CHAR_UNSIGNED -D__SDCC_USE_NON_FREE -D__SDCCCALL=0 -D__SDCC=4_2_9 -D__SDCC_VERSION_MAJOR=4 -D__SDCC_VERSION_MINOR=2 -D__SDCC_VERSION_PATCH=9 -D__SDCC_REVISION=13735 -D__SDCC_pic14 -D__STDC_NO_COMPLEX__=1 -D__STDC_NO_THREADS__=1 -D__STDC_NO_ATOMICS__=1 -D__STDC_NO_VLA__=1 -D__STDC_ISO_10646__=201409L -D__SIZEOF_FLOAT__=4 -D__SIZEOF_DOUBLE__=4 -D__SDCC_BITINT_MAXWIDTH=0 -isystem /usr/local/bin/../share/sdcc/include/pic14 -isystem /usr/local/share/sdcc/include/pic14 -isystem /usr/local/bin/../share/sdcc/include -isystem /usr/local/share/sdcc/include -isystem /usr/local/bin/../share/sdcc/non-free/include/pic14 -isystem /usr/local/share/sdcc/non-free/include/pic14 -isystem /usr/local/bin/../share/sdcc/non-free/include -isystem /usr/local/share/sdcc/non-free/include -xc test.c
+ gpasm -o test.o -c test.asm
test.asm:79:Message[1304] Page selection not needed for this device. No code generated.
+ gplink -I/usr/local/bin/../share/sdcc/lib/pic14 -I/usr/local/share/sdcc/lib/pic14 -I/usr/local/bin/../share/sdcc/non-free/lib/pic14 -I/usr/local/share/sdcc/non-free/lib/pic14 -I/usr/local/bin/../share/sdcc/lib/pic14 -I/usr/local/share/sdcc/lib/pic14 -I/usr/local/bin/../share/sdcc/non-free/lib/pic14 -I/usr/local/share/sdcc/non-free/lib/pic14 -w -r -o test test.o libsdcc.lib pic12f675.lib
message: Using default linker script "/usr/share/gputils/lkr/12f675_g.lkr".
error: Duplicate symbol "_main" defined in "test.o" and "libsdcc_a-idata.o".
warning: Relocation of section "UDL_idata_0" failed, relocating to a shared memory location.
warning: Relocation of section "IDD_idata_0" failed, relocating to a shared memory location.
error: Error while writing hex file.
+ gplink -I/usr/local/bin/../share/sdcc/lib/pic14 -I/usr/local/share/sdcc/lib/pic14 -I/usr/local/bin/../share/sdcc/non-free/lib/pic14 -I/usr/local/share/sdcc/non-free/lib/pic14 -I/usr/local/bin/../share/sdcc/lib/pic14 -I/usr/local/share/sdcc/lib/pic14 -I/usr/local/bin/../share/sdcc/non-free/lib/pic14 -I/usr/local/share/sdcc/non-free/lib/pic14 -w -r -o test test.o libsdcc.lib pic12f675.lib returned errorcode 256
As shown here, due to the _main
symbol conflict, no code can be built. Even an empty C program cannot be built.
Mysteriously, I just found the problem doesn't exist in the official snapshot build. I suspect "libsdcc_a-idata.o" was incorrectly generated. Is it possible that an outdated autoconf output caused this problem? I'll try autoreconf and see...
Unfortunately, even running
autoreconf
cannot solve the symbol conflict problem. The official SDCC prebuild snapshots are currently the only functional builds on Fedora. There must be something wrong in the build system that must be investigated.P.S: The main project already enforces autoconf 2.71 in
configure.ac
but there are still autoconf 2.69 overrides in/support/sdbinutils/config/override.m4
and./support/cpp/config/override.m4
. Making it impossible to runautoreconf
without manually commented out the overrides. This is also a problem that needs to be fixed.Last edit: Tom Li 2022-10-23
This issue has already been previous reported on the mailing list in 2021. For a more detailed report, including workaround and assembly output, please see: https://sourceforge.net/p/sdcc/discussion/1865/thread/aa77f0a86a/
I found some information from Patch 303 (https://sourceforge.net/p/sdcc/patches/303/?page=2). It seems that the duplicate
_main
symbol was deliberately added.~~~
// call main after initialization
+ (void)main; / otherwise the _main symbol is not declared /
__asm
PAGESEL _main
GOTO _main
~~~
So, on some systems,
_main
symbol is not generated, but on Fedora,_main
is generated twice.Last edit: Tom Li 2023-01-03