Below is all using a new download of the repo fromr13858 and building in that clean tree with no previous builds. Let me know if I should split this to separate topics. Thanks!
I noticed some things and have a question about SDCPP the new CC1:
When I build on Linux (64 bit) SDCPP does not seem to get built anymore.
CC1 is not present in the Linux 64 bit snapshot build archives, but it is present in the Windows ones.
Is CC1 meant to be called directly from SDCC, or called through SDCPP?
Do I understand right that it is taking over the role as preprocessor?
Build things:
Also, at the end of a successful build many of the binaries no longer get copied into the bin directory, so I just ran the commands below.
Is there a new additional build command or stage that needs to be invoked to complete putting all the binaries in place? It has been about a year since I last built, so perhaps I am forgetting something.
cp src/sdcc bin
cp support/sdbinutils/binutils/sdar bin
cp support/sdbinutils/binutils/sdranlib bin
cp support/sdbinutils/binutils/sdobjcopy bin
cp support/sdbinutils/binutils/nm bin
cp support/cpp/gcc/cc1 bin
The lack of copy to bin also caused building to fail at the library stage, so I added --disable-device-lib to the configure to work around that (we don't use the library, so that is ok).
make[4]:Enteringdirectory'/home/builduser/sdcc_4.3/sdcc-code-r13858-trunk/sdcc/device/lib'if[-fmos6502/Makefile]; then \make-Cmos6502PORT=mos6502||exit1; \fi||:
make[5]:Enteringdirectory'/home/builduser/sdcc_4.3/sdcc-code-r13858-trunk/sdcc/device/lib/mos6502'/home/builduser/sdcc_4.3/sdcc-code-r13858-trunk/sdcc/bin/sdcc-I./../../include-I.--std-c2x-mmos6502--max-allocs-per-node25000--opt-code-speed-c_ret.c-o_ret.relmake[5]:/home/builduser/sdcc_4.3/sdcc-code-r13858-trunk/sdcc/bin/sdcc:Commandnotfound
../incl.mk:153:recipefortarget'_ret.rel'failedmake[5]:***[_ret.rel]Error127
This is my .configure. I'm building on a clean Ubuntu 16.04 virtual machine so that we can have a Linux Build that has broad GLIBC compatibility.
I can only give a very rough idea here. The work was done by @felixs, who is familiar with the details and reasoning.
SDCC for a long time has had a preprocessor based on GCC 4.6.3. It had become clear, that to fix bugs in it, and to be able to support modern C standards, SDCC would need a new preprocessor. Various options were considered; in the end the chosen path was to replace it by one based on the one from GCC 12.1.0.
Since there had been major changes in the architecture of the preprocessor (e.g. it had since become more integrated into GCC, though not as tightly as what LLVM does), this also meant substantial changes in how the preprocessor is handled on the SDCC side.
While the binaries are no longer copied to sdcc/bin, sdcc/bin does contain scripts that do call the binaries.
For me, SDCC does fully build from source from svn on Debian GNU/Linux testing.
Last edit: Maarten Brock 2023-02-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to confirm - was your SDCC build test on a fully clean source tree/repo that hadn't built before?
I just tried again with these steps and still got a failure to copy binaries to bin at the end: (which then also causes the lib build error if I don't add --disable-device-lib to the configure to skip that stage)
And after the build completes there are several binaries in bin which are only a couple hundred bytes ( but do look correct in their pre-copy location).
$make>/dev/nullInfileincludedfrom/usr/include/string.h:495,fromsdcdb.h:47,fromsdcdb.c:24:Infunction‘strncpy’,inlinedfrom‘readCdb’atsdcdb.c:418:11,inlinedfrom‘cmdFile’atsdcdb.c:816:12:/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10:warning:‘__builtin_strncpy’specifiedbounddependsonthelengthofthesourceargument[-Wstringop-overflow=]106|return__builtin___strncpy_chk(__dest,__src,__len,__bos(__dest));|^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~sdcdb.c:Infunction‘cmdFile’:sdcdb.c:418:36:note:lengthcomputedhere418|strncpy(currl->line,bp,strlen(bp)-1);|^~~~~~~~~~cmd.c:Infunction‘displayAll’:cmd.c:3194:11:warning:suggestparenthesesaroundassignmentusedastruthvalue[-Wparentheses]3194|if(sym=symLookup(dsym->name,cctxt))|^~~cmdpars.y:warning:55shift/reduceconflicts[-Wconflicts-sr]cmdpars.y:note:rerunwithoption'-Wcounterexamples'togenerateconflictcounterexamplesasxxxx.c:Infunction‘asxxxx_bfd_is_target_special_symbol’:asxxxx.c:1068:55:warning:unusedparameter‘a’[-Wunused-parameter]1068|staticboolasxxxx_bfd_is_target_special_symbol(bfd*a,asymbol*b)|~~~~~~^asxxxx.c:1068:68:warning:unusedparameter‘b’[-Wunused-parameter]1068|staticboolasxxxx_bfd_is_target_special_symbol(bfd*a,asymbol*b)|~~~~~~~~~~^configure:WARNING:libdebuginfodismissingorunusable;somefeaturesmaybeunavailable.Infileincludedfrom/usr/include/string.h:495,frommakebin.c:31:Infunction‘strncpy’,inlinedfrom‘main’atmakebin.c:819:15:/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10:warning:‘__builtin_strncpy’specifiedbound2equalsdestinationsize[-Wstringop-truncation]106|return__builtin___strncpy_chk(__dest,__src,__len,__bos(__dest));|^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~configure:WARNING:fixed-pointisnotsupportedforthistarget,ignoredconfigure:WARNING:***Makeinfoismissingortooold.***Infodocumentationwillnotbebuilt./home/maarten/sdcc/support/cpp/gcc/configure:line19705:test:=:unaryoperatorexpected/home/maarten/sdcc/support/cpp/gcc/configure:line24018:test:-gt:unaryoperatorexpected/home/maarten/sdcc/support/cpp/gcc/configure:line24019:test:-eq:unaryoperatorexpectedLinksarenowsetuptobuildanativecompilerforx86_64-pc-linux-gnu.expr.cc:Infunction‘unsignedintcpp_classify_number(cpp_reader*,constcpp_token*,constchar**,location_t)’:expr.cc:808:18:warning:formatnotastringliteralandnoformatarguments[-Wformat-security]808|0,message);|^expr.cc:811:39:warning:formatnotastringliteralandnoformatarguments[-Wformat-security]811|virtual_location,0,message);|^expr.cc:821:34:warning:formatnotastringliteralandnoformatarguments[-Wformat-security]821|virtual_location,0,message);|^macro.cc:Inmemberfunction‘vaopt_state::update_typevaopt_state::update(constcpp_token*)’:macro.cc:186:23:warning:formatnotastringliteralandnoformatarguments[-Wformat-security]186|vaopt_paste_error);|^macro.cc:215:24:warning:formatnotastringliteralandnoformatarguments[-Wformat-security]215|vaopt_paste_error);|^macro.cc:Infunction‘cpp_macro*create_iso_definition(cpp_reader*)’:macro.cc:3704:58:warning:formatnotastringliteralandnoformatarguments[-Wformat-security]3704|cpp_error(pfile,CPP_DL_ERROR,paste_op_error_msg);|^macro.cc:3719:58:warning:formatnotastringliteralandnoformatarguments[-Wformat-security]3719|cpp_error(pfile,CPP_DL_ERROR,paste_op_error_msg);|^ar:`u' modifier ignored since `D'isthedefault(see`U')/bin/sh: /home/maarten/sdcc/support/cpp/missing: No such file or directoryconfigure: WARNING: 'missing' script is too old or missingdiagnostic.cc: In function ‘void fancy_abort(const char*, int, const char*)’:diagnostic.cc:2027:52: warning: format not a string literal and no format arguments [-Wformat-security] 2027 | fnotice (stderr, diagnostic_kind_text[DK_ICE]); | ^gcc.cc: In function ‘long unsigned int get_random_number()’:gcc.cc:10577:12: warning: ignoring return value of ‘ssize_t read(int, void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]10577 | read (fd, &ret, sizeof (HOST_WIDE_INT)); | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~gcc.cc: In function ‘void do_report_bug(const char**, int, char**, char**)’:gcc.cc:7789:9: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result] 7789 | write (fd, "\n//", 3); | ~~~~~~^~~~~~~~~~~~~~~gcc.cc:7792:13: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result] 7792 | write (fd, " ", 1); | ~~~~~~^~~~~~~~~~~~gcc.cc:7793:13: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result] 7793 | write (fd, new_argv[i], strlen (new_argv[i])); | ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~gcc.cc:7795:9: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result] 7795 | write (fd, "\n\n", 2); | ~~~~~~^~~~~~~~~~~~~~~SDCC.y:77.1-7: warning: POSIX Yacc does not support %expect [-Wyacc] 77 | %expect 3 | ^~~~~~~In file included from /usr/include/string.h:495, from SDCC.y:30:In function ‘strncpy’, inlined from ‘yyparse’ at SDCC.y:2188:21:/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying 252 bytes from a string of length 256 [-Wstringop-truncation] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~In function ‘strncpy’, inlined from ‘yyparse’ at SDCC.y:2160:21:/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying 252 bytes from a string of length 256 [-Wstringop-truncation] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~SDCCval.c: In function ‘ulFromVal’:SDCCval.c:2002:22: warning: passing argument 1 of ‘ullFromVal’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] 2002 | return ullFromVal (val); | ^~~In file included from SDCCsymt.h:657, from SDCCast.h:29, from common.h:43, from SDCCval.c:26:SDCCval.h:133:32: note: expected ‘value *’ {aka ‘struct value *’} but argument is of type ‘const value *’ {aka ‘const struct value *’} 133 | unsigned long long ullFromVal (value *); | ^~~~~~~gen.c: In function ‘opInfo’:gen.c:330:23: warning: ‘%s’ directive output may be truncated writing up to 768 bytes into a region of size 60 [-Wformat-truncation=] 330 | snprintf(str, 64, "SYM:%s(%s:%d)", | ^~~~~~~~~~~~~~~gen.c:330:23: note: directive argument in the range [-32768, 32767]In file included from /usr/include/stdio.h:867, from ./../common.h:21, from ralloc.h:29, from gen.c:29:/usr/include/x86_64-linux-gnu/bits/stdio2.h:67:10: note: ‘__builtin___snprintf_chk’ output between 9 and 782 bytes into a destination of size 64 67 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 68 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~In file included from /usr/include/string.h:495, from aslink.h:35, from lklist.c:34:In function ‘strncpy’, inlined from ‘lkalist’ at lklist.c:985:9:/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying between 4 and 11 bytes from a string of length 15 [-Wstringop-truncation] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~In function ‘strncpy’, inlined from ‘lkglist’ at lklist.c:1264:9:/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying between 3 and 4 bytes from a string of length 15 [-Wstringop-truncation] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~In function ‘strncpy’, inlined from ‘lkglist’ at lklist.c:1274:25:/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying between 4 and 11 bytes from a string of length 15 [-Wstringop-truncation] 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~lkmem.c: In function ‘summary’:lkmem.c:366:37: warning: ‘%s’ directive writing up to 4095 bytes into a region of size 127 [-Wformat-overflow=] 366 | sprintf(buff, "'%s'\n", Ram[j].Name); | ^~In file included from /usr/include/stdio.h:867, from lkmem.c:18:/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output between 4 and 4099 bytes into a destination of size 128 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~lkmem.c:372:33: warning: ‘%s’ directive writing up to 4095 bytes into a region of size 127 [-Wformat-overflow=] 372 | sprintf(buff, "'%s'\n", IRam.Name); | ^~ ~~~~~~~~~In file included from /usr/include/stdio.h:867, from lkmem.c:18:/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output between 4 and 4099 bytes into a destination of size 128 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~lksdcclib.c: In function ‘buildlibraryindex_sdcclib’:lksdcclib.c:151:37: warning: ‘%s’ directive writing 3 bytes into a region of size between 0 and 4095 [-Wformat-overflow=] 151 | sprintf (buff, "%s%s%c%s", lbnh->path, ModName, FSEPX, LKOBJEXT); | ^~In file included from /usr/include/stdio.h:867, from lk_readnl.h:31, from lksdcclib.c:36:/usr/include/x86_64-linux-gnu/bits/stdio2.h:36:10: note: ‘__builtin___sprintf_chk’ output 5 or more bytes (assuming 4100) into a destination of size 4096 36 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 37 | __bos (__s), __fmt, __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~_rrulonglong.c:60: warning 151: using generic pointer <null> to initialize iTemp8_rrslonglong.c:60: warning 151: using generic pointer <null> to initialize iTemp8lcd390.c:67: warning 283: function declarator with no prototypelcd390.c:89: warning 283: function declarator with no prototypelcd390.c:94: warning 283: function declarator with no prototypelcd390.c:99: warning 283: function declarator with no prototypelcd390.c:103: warning 283: function declarator with no prototypelcd390.c:107: warning 283: function declarator with no prototypelcd390.c:111: warning 283: function declarator with no prototypelcd390.c:115: warning 283: function declarator with no prototypelcd390.c:119: warning 283: function declarator with no prototypelcd390.c:124: warning 283: function declarator with no prototype_rrulonglong.c:60: warning 151: using generic pointer <null> to initialize iTemp8_rrslonglong.c:60: warning 151: using generic pointer <null> to initialize iTemp8make[5]: rcD: Command not foundmake[5]: [Makefile:41: ../build/ds400/libds400.lib] Error 127 (ignored)Makefile:95: warning: overriding recipe for target 'Makefile'Makefile:69: warning: ignoring old recipe for target 'Makefile'Makefile:95: warning: overriding recipe for target 'Makefile'Makefile:69: warning: ignoring old recipe for target 'Makefile'Makefile:97: warning: overriding recipe for target 'Makefile'Makefile:71: warning: ignoring old recipe for target 'Makefile'Makefile:98: warning: overriding recipe for target 'Makefile'Makefile:72: warning: ignoring old recipe for target 'Makefile'Makefile:97: warning: overriding recipe for target 'Makefile'Makefile:71: warning: ignoring old recipe for target 'Makefile'Makefile:96: warning: overriding recipe for target 'Makefile'Makefile:70: warning: ignoring old recipe for target 'Makefile'Makefile:98: warning: overriding recipe for target 'Makefile'Makefile:72: warning: ignoring old recipe for target 'Makefile'
Update: Did a build on a clean tree with source from 13911 and the build errors appear to be resolved now (at least for the subset of target platforms that GBDK uses)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How did you install SDCC 4.3.0 RC1 (.zip? .exe installer? On what system (ReactOS? Windows? wine on GNU/Linux, etc?) Which version of it? Which architecture (x86. amd64)).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I installed sdcc-4.3.0-rc1-x64-setup.exe on a 64-bits version of Windows 10 Family.
That said, if I want to upgrade SDCC to 4.3.0 in my MSXgl library, I need to find a solution to embed SDCC without the user having to install another program as well.
I tested that configuration before uploading sdcc-4.3.0-rc1-x64-setup.exe (and tested it again just now, both time using Win 10 in a qemu VM, then opening a command prompt, the compiling a small test.c file via sdcc test.c).
So I wonder what is different in your case. Did you untick the box "Add C:\Program Files\SDCC\bin to path" in the installer (I left it ticket, which is the default)? How did you invoke sdcc?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the link you shared for where you are placing the sdcc files, it looks like you are missing the now required "libexec\sdcc\" directory that cc1 needs to be placed under.
For example if sdcc.exe is located and named as follows:
c:\TEMP\sdcc\bin\sdcc.exe
Then it should work if cc1 is located and named as follows (without the .exe extension) under:
c:\TEMP\sdcc\libexec\sdcc\cc1
I tryied to move cc1 in a libexec\sdcc\cc1 directory as described but I got the same error: sdcpp.exe: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I untick the box "Add C:\Program Files\SDCC\bin to path" in the installer.
I need my toolchain/library to be usable directly by cloning the Git repository (as is it currently the case with SDCC 4.2.0).
You can find MSXgl here: https://github.com/aoineko-fr/MSXgl
SDCC is embedded into the tools/sdcc/ directory.
The build tool use Node.js scripts (located in engine/script/js/) to call SDCC with the right parameters (depending on project configuration).
Here is an example for the example sample:
- Project root directory: projects/example/
- Build tool invoke SDCC first to compile each C module. E.g. D:\Dev\Private\MSX\MSXgl\tools/sdcc/bin/sdcc -c -mz80 --vc -DTARGET=TARGET_ROM_32K -DMSX_VERSION=MSX_1 -ID:\Dev\Private\MSX\MSXgl\projects\example/ -ID:\Dev\Private\MSX\MSXgl\engine/src -ID:\Dev\Private\MSX\MSXgl\engine/content -ID:\Dev\Private\MSX\MSXgl\tools/ --opt-code-speed --debug -DAPPSIGN ./example.c -o D:\Dev\Private\MSX\MSXgl\projects\example/out/
- Then the build tool invoke SDCC to link all modules together. D:\Dev\Private\MSX\MSXgl\tools/sdcc/bin/sdcc -mz80 --vc --no-std-crt0 -LD:\Dev\Private\MSX\MSXgl\tools/sdcc/lib/z80 --code-loc 0x4000 --data-loc 0xC000 --opt-code-speed --debug D:\Dev\Private\MSX\MSXgl\projects\example/out/crt0_rom32.rel D:\Dev\Private\MSX\MSXgl\projects\example/out/msxgl.lib D:\Dev\Private\MSX\MSXgl\projects\example/out/example.rel -o D:\Dev\Private\MSX\MSXgl\projects\example/out/example.ihx
All paths are dynamically generated relative to the project path.
MSXgl is used by many users, both on Windows and Linux.
Tell me if you need more information.
Last edit: Aoineko 2023-07-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you want, you can use Process Explorer (by Sysinternals / Microsoft) filtered down to just show the sdcc and sdcpp executables. It allows seeing which paths they are actually searching (for sdcpp and cc1). I had success using that to figure out what was going on for our installs (so far).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately, since we do now have that extra cc1 executable, just invoking sdcc without a suitable PATH (or whatever else is used on Windows to look for executables) being set no longer works. AFAIK, we need the directory where cc1 is, or the directory where libexec\sdcc\cc1 is to be in that PATH (or equivalent).
So if you don't want to install and set a suitable PATH (or equivalent) system-wide, this would have to be done by your build tool before invoking sdcc.
Since your build tool needs to know where sdcc is located anyway, it should also know where cc1 is, and thus be able to do this easily.
P.S.: I might be wrong here. I am not a preprocessor expert, and very rarely use Windows.
Last edit: Philipp Klaus Krause 2023-07-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll give it a try, but I don't understand the story behind the /libexec/sdcc/cc1/.
In the SDCC 4.3.0 rc1 package, the cc1 tool is located in the /bin/ directory; If this is not the correct location, why isn't it already in the right place?
Will the trick of changing the path also work under Linux?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know the details (@felixs does), but the high-level perspective is:
Our old sdcpp was a fork of an ancient cpp (the preprocessor of gcc).
We needed a newer one to be able to better support newer C standards.
A year ago, when the decision as made, options were: using the preprocessor from current GCC, using the preprocessor from current clang, using Wave. We went with the first, which looked like the best choice at the time).
cpp is now more tightly integrated into gcc (though not as much as the clang preprocessor is into clang), so we had to make some changes, including having separate sdcpp and cc1, similar to how this is handled in gcc.
From today's perspective, Wave looks like it might be a better option (it is meant for creating stand-alone preprocessors); but a year ago, it was unmaintained and didn't support C standards newer than C99. The new maintainer has already added large parts of C2X support since.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FWIW, I have a similar ambivalence to SDCC's decision to use the GCC 12 pre-processor, and have looked at alternatives for my own use within an SDCC toolchain.
Boost Wave is certainly one option for the SDCC developers to consider, but personally, I have decided to work on adding C23 support to Kiyoshi Matsui's MCPP (mcpp.sourceforge.net), another standalone C preprocessor project that has been unmaintained for a while and stuck at C99-compliance, but which is still used, and which is a current package in practically-all linux distributions.
The preprocessor changes from C99 -> C23 are easy to implement, and MCPP's source code is small, well-written, and seems easy to modify, all factors that I appreciate when looking at using someone else's code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So far(*1) we are using SDCC on Windows in arbitrary install locations without adding it to the system search PATH. As long as cc1 is relative to sdcpp in the way described earlier it has been working for use with gbdk.
(And it works for us so far on Windows 32 & 64 bit, Linux and MacOS)
*1: Tested up to build 14116. I'll trigger updated builds with our patches and check with those soon.
Edit: Built our patched 14186 and it is still working ok on Windows. (https://github.com/gbdk-2020/gbdk-2020-sdcc/actions/runs/5451673964)
An example from a (14110) build running in a Win 8 VM with no PATH updates to include any directories
Sorry for the late reply.
By forcing the path in the build script, it works fine.
It's a pity to have to change the environment variables to make SDCC work, but at least it works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Below is all using a new download of the repo from
r13858
and building in that clean tree with no previous builds. Let me know if I should split this to separate topics. Thanks!I noticed some things and have a question about SDCPP the new CC1:
Is CC1 meant to be called directly from SDCC, or called through SDCPP?
Do I understand right that it is taking over the role as preprocessor?
Build things:
Also, at the end of a successful build many of the binaries no longer get copied into the bin directory, so I just ran the commands below.
Is there a new additional build command or stage that needs to be invoked to complete putting all the binaries in place? It has been about a year since I last built, so perhaps I am forgetting something.
The lack of copy to bin also caused building to fail at the library stage, so I added
--disable-device-lib
to the configure to work around that (we don't use the library, so that is ok).This is my .configure. I'm building on a clean Ubuntu 16.04 virtual machine so that we can have a Linux Build that has broad GLIBC compatibility.
I can only give a very rough idea here. The work was done by @felixs, who is familiar with the details and reasoning.
SDCC for a long time has had a preprocessor based on GCC 4.6.3. It had become clear, that to fix bugs in it, and to be able to support modern C standards, SDCC would need a new preprocessor. Various options were considered; in the end the chosen path was to replace it by one based on the one from GCC 12.1.0.
Since there had been major changes in the architecture of the preprocessor (e.g. it had since become more integrated into GCC, though not as tightly as what LLVM does), this also meant substantial changes in how the preprocessor is handled on the SDCC side.
While the binaries are no longer copied to sdcc/bin, sdcc/bin does contain scripts that do call the binaries.
For me, SDCC does fully build from source from svn on Debian GNU/Linux testing.
Last edit: Maarten Brock 2023-02-20
Just to confirm - was your SDCC build test on a fully clean source tree/repo that hadn't built before?
I just tried again with these steps and still got a failure to copy binaries to
bin
at the end: (which then also causes the lib build error if I don't add--disable-device-lib
to the configure to skip that stage)And after the build completes there are several binaries in
bin
which are only a couple hundred bytes ( but do look correct in their pre-copy location).I also experience build failures when building from a fresh checkout on Ubuntu 20.04 LTS.
Last edit: Maarten Brock 2023-02-20
Update: Did a build on a clean tree with source from 13911 and the build errors appear to be resolved now (at least for the subset of target platforms that GBDK uses)
With version 4.3.0rc1, I still get the CC1 error.
I don't know if this is the right place to mention it.
I hope it will be fixed for the final version 4.3.0.
How did you install SDCC 4.3.0 RC1 (.zip? .exe installer? On what system (ReactOS? Windows? wine on GNU/Linux, etc?) Which version of it? Which architecture (x86. amd64)).
I installed
sdcc-4.3.0-rc1-x64-setup.exe
on a 64-bits version of Windows 10 Family.That said, if I want to upgrade SDCC to 4.3.0 in my MSXgl library, I need to find a solution to embed SDCC without the user having to install another program as well.
In current version 4.2.0, everything needed to compile/build MSX application are included there: https://github.com/aoineko-fr/MSXgl/tree/main/tools/sdcc
Last edit: Aoineko 2023-07-02
I tested that configuration before uploading
sdcc-4.3.0-rc1-x64-setup.exe
(and tested it again just now, both time using Win 10 in a qemu VM, then opening a command prompt, the compiling a small test.c file viasdcc test.c
).So I wonder what is different in your case. Did you untick the box "Add C:\Program Files\SDCC\bin to path" in the installer (I left it ticket, which is the default)? How did you invoke sdcc?
In the link you shared for where you are placing the sdcc files, it looks like you are missing the now required "libexec\sdcc\" directory that cc1 needs to be placed under.
For example if sdcc.exe is located and named as follows:
c:\TEMP\sdcc\bin\sdcc.exe
Then it should work if cc1 is located and named as follows (without the .exe extension) under:
c:\TEMP\sdcc\libexec\sdcc\cc1
More details in the following ticket:
https://sourceforge.net/p/sdcc/bugs/3571/
If
cc1
need to be inlibexec\sdcc\cc1
directory, why not put it there in the SDCC package?I tryied to move cc1 in a
libexec\sdcc\cc1
directory as described but I got the same error:sdcpp.exe: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
Any news on this? Did you get it to work? If not, can you provide the details I asked about yesterday?
Yes, I untick the box "Add C:\Program Files\SDCC\bin to path" in the installer.
I need my toolchain/library to be usable directly by cloning the Git repository (as is it currently the case with SDCC 4.2.0).
You can find MSXgl here: https://github.com/aoineko-fr/MSXgl
SDCC is embedded into the
tools/sdcc/
directory.The build tool use Node.js scripts (located in
engine/script/js/
) to call SDCC with the right parameters (depending on project configuration).Here is an example for the
example
sample:- Project root directory:
projects/example/
- Build tool invoke SDCC first to compile each C module. E.g.
D:\Dev\Private\MSX\MSXgl\tools/sdcc/bin/sdcc -c -mz80 --vc -DTARGET=TARGET_ROM_32K -DMSX_VERSION=MSX_1 -ID:\Dev\Private\MSX\MSXgl\projects\example/ -ID:\Dev\Private\MSX\MSXgl\engine/src -ID:\Dev\Private\MSX\MSXgl\engine/content -ID:\Dev\Private\MSX\MSXgl\tools/ --opt-code-speed --debug -DAPPSIGN ./example.c -o D:\Dev\Private\MSX\MSXgl\projects\example/out/
- Then the build tool invoke SDCC to link all modules together.
D:\Dev\Private\MSX\MSXgl\tools/sdcc/bin/sdcc -mz80 --vc --no-std-crt0 -LD:\Dev\Private\MSX\MSXgl\tools/sdcc/lib/z80 --code-loc 0x4000 --data-loc 0xC000 --opt-code-speed --debug D:\Dev\Private\MSX\MSXgl\projects\example/out/crt0_rom32.rel D:\Dev\Private\MSX\MSXgl\projects\example/out/msxgl.lib D:\Dev\Private\MSX\MSXgl\projects\example/out/example.rel -o D:\Dev\Private\MSX\MSXgl\projects\example/out/example.ihx
All paths are dynamically generated relative to the project path.
MSXgl is used by many users, both on Windows and Linux.
Tell me if you need more information.
Last edit: Aoineko 2023-07-03
If you want, you can use Process Explorer (by Sysinternals / Microsoft) filtered down to just show the sdcc and sdcpp executables. It allows seeing which paths they are actually searching (for sdcpp and cc1). I had success using that to figure out what was going on for our installs (so far).
Unfortunately, since we do now have that extra cc1 executable, just invoking sdcc without a suitable PATH (or whatever else is used on Windows to look for executables) being set no longer works. AFAIK, we need the directory where cc1 is, or the directory where libexec\sdcc\cc1 is to be in that PATH (or equivalent).
So if you don't want to install and set a suitable PATH (or equivalent) system-wide, this would have to be done by your build tool before invoking sdcc.
Since your build tool needs to know where sdcc is located anyway, it should also know where cc1 is, and thus be able to do this easily.
P.S.: I might be wrong here. I am not a preprocessor expert, and very rarely use Windows.
Last edit: Philipp Klaus Krause 2023-07-04
I'll give it a try, but I don't understand the story behind the
/libexec/sdcc/cc1/
.In the SDCC 4.3.0 rc1 package, the cc1 tool is located in the
/bin/
directory; If this is not the correct location, why isn't it already in the right place?Will the trick of changing the path also work under Linux?
I don't know the details (@felixs does), but the high-level perspective is:
FWIW, I have a similar ambivalence to SDCC's decision to use the GCC 12 pre-processor, and have looked at alternatives for my own use within an SDCC toolchain.
Boost Wave is certainly one option for the SDCC developers to consider, but personally, I have decided to work on adding C23 support to Kiyoshi Matsui's MCPP (mcpp.sourceforge.net), another standalone C preprocessor project that has been unmaintained for a while and stuck at C99-compliance, but which is still used, and which is a current package in practically-all linux distributions.
The preprocessor changes from C99 -> C23 are easy to implement, and MCPP's source code is small, well-written, and seems easy to modify, all factors that I appreciate when looking at using someone else's code.
Pardon my popping into this thread so much :)
So far(*1) we are using SDCC on Windows in arbitrary install locations without adding it to the system search PATH. As long as cc1 is relative to sdcpp in the way described earlier it has been working for use with gbdk.
(And it works for us so far on Windows 32 & 64 bit, Linux and MacOS)
*1: Tested up to build 14116. I'll trigger updated builds with our patches and check with those soon.
Edit: Built our patched 14186 and it is still working ok on Windows. (https://github.com/gbdk-2020/gbdk-2020-sdcc/actions/runs/5451673964)
An example from a (14110) build running in a Win 8 VM with no PATH updates to include any directories
It also still works fine if I copy that whole install to a new directory such as
"C:\some-new-path\gbdk..."
Last edit: bbbbbr 2023-07-04
Sorry for the late reply.
By forcing the path in the build script, it works fine.
It's a pity to have to change the environment variables to make SDCC work, but at least it works.