Nim 0.17.2 worked fine, Nim 0.18.0 has this problem when attempting to run the './koch tools' part of the manual setup:
Hint: gcc -c -w -pthread -O3 -fno-strict-aliasing -I/var/lib/rrnim/nim-0.18.0/lib -o nimsuggest/nimcache/stdlib_system.o nimsuggest/nimcache/stdlib_system.c [Exec]
nimsuggest/nimcache/stdlib_system.c: In function ‘atomicInc_4E9cxwuunx9aiL7vj9bdy8WvAsystem’:
nimsuggest/nimcache/stdlib_system.c:2514: error: ‘__ATOMIC_RELAXED’ undeclared (first use in this function)
nimsuggest/nimcache/stdlib_system.c:2514: error: (Each undeclared identifier is reported only once
nimsuggest/nimcache/stdlib_system.c:2514: error: for each function it appears in.)
Error: execution of an external program failed: 'gcc -c -w -pthread -O3 -fno-strict-aliasing -I/var/lib/rrnim/nim-0.18.0/lib -o nimsuggest/nimcache/stdlib_system.o nimsuggest/nimcache/stdlib_system.c'
FAILURE
GCC version is 4.1.2, underlying OS is Debian 4 (Etch).
GCC 4.1.2 is older than Nim itself, do we really want to support it? https://gcc.gnu.org/releases.html
@Araq GCC 4.1.2 never worked with Nim, so when people say its working they are wrong, and just not compiled --threads:on applications. The main problem is ATOMIC.
This actually duplicates my issue #4046.
and to @andreaferretti @Yardanico and @trustable-code there so many SOCs which using outdated Linux distros, in which you are not able to upgrade GCC easily, and also usage of the modern ATOMIC builtins was a mistake made in the past, just because somebody not investigated this problem properly. Even OpenBSD (modern) using GCC 4.1.2 by default.
My scenario is similar to what @cheatfate is describing.
More or less, Nim seems to fit that niche very well compared to any other modern high level programming language version. eg, have never been able to (so far) get modern go, lang, rust, haskell, llvm, clang, gcc, D, etc running on there; I'm only able to compile from very vanilla C, so long as no recent/convenience GCC features are used. Normally this limits me to Python. However, Python 3.5 is the last version to be compilable from source, Python 3.6 and onwards are no longer compilable. While eg, latest ffmpeg still compiles fine. Would be really nice to have at least the one high level lang where modern versions can continue to be used in that kind of very old and niche environment.
@wizzardx did you try to compile newer GCC for this platform?
@Yardanico - not recently - I tried a few times before but got stuck and didn't want to spend too much time on it. I'll need to give it another try sometime.
Isn't this a relatively simple fix that will use conditional compilation to replace the atomic procs with a manually coded alternative that would work on these old systems? Somebody having access to such an old system is best positioned to fix this.
You should Use AntiX Linux instead of Debian 4.
Most helpful comment
GCC 4.1.2 is older than Nim itself, do we really want to support it? https://gcc.gnu.org/releases.html