nim-lang / csources Goto Github PK

This succeeded about a week or so ago, but is not working at the moment. Grab the master branch and run sh build.sh on OSX 64bit and get the following error:

clang -o ../bin/nimrod  c_code/3_2/nimrod.o c_code/3_2/stdlib_system.o c_code/3_2/testability.o c_code/3_2/commands.o c_code/3_2/stdlib_os.o c_code/3_2/stdlib_strutils.o c_code/3_2/stdlib_parseutils.o c_code/3_2/stdlib_times.o c_code/3_2/stdlib_posix.o c_code/3_2/msgs.o c_code/3_2/options.o c_code/3_2/lists.o c_code/3_2/stdlib_strtabs.o c_code/3_2/stdlib_hashes.o c_code/3_2/stdlib_osproc.o c_code/3_2/stdlib_streams.o c_code/3_2/stdlib_sets.o c_code/3_2/stdlib_math.o c_code/3_2/stdlib_tables.o c_code/3_2/ropes.o c_code/3_2/platform.o c_code/3_2/crc.o c_code/3_2/stdlib_sockets.o c_code/3_2/stdlib_unsigned.o c_code/3_2/nversion.o c_code/3_2/condsyms.o c_code/3_2/idents.o c_code/3_2/extccomp.o c_code/3_2/wordrecg.o c_code/3_2/babelcmd.o c_code/3_2/lexer.o c_code/3_2/nimlexbase.o c_code/3_2/llstream.o c_code/3_2/nimconf.o c_code/3_2/main.o c_code/3_2/ast.o c_code/3_2/stdlib_intsets.o c_code/3_2/idgen.o c_code/3_2/astalgo.o c_code/3_2/rodutils.o c_code/3_2/syntaxes.o c_code/3_2/parser.o c_code/3_2/pbraces.o c_code/3_2/filters.o c_code/3_2/renderer.o c_code/3_2/filter_tmpl.o c_code/3_2/rodread.o c_code/3_2/types.o c_code/3_2/trees.o c_code/3_2/stdlib_memfiles.o c_code/3_2/rodwrite.o c_code/3_2/passes.o c_code/3_2/magicsys.o c_code/3_2/nimsets.o c_code/3_2/bitsets.o c_code/3_2/importer.o c_code/3_2/lookups.o c_code/3_2/semdata.o c_code/3_2/treetab.o c_code/3_2/vmdef.o c_code/3_2/sem.o c_code/3_2/semfold.o c_code/3_2/saturate.o c_code/3_2/procfind.o c_code/3_2/pragmas.o c_code/3_2/semtypinst.o c_code/3_2/sigmatch.o c_code/3_2/parampatterns.o c_code/3_2/docgen.o c_code/3_2/docutils_rstast.o c_code/3_2/stdlib_json.o c_code/3_2/stdlib_lexbase.o c_code/3_2/stdlib_unicode.o c_code/3_2/docutils_rst.o c_code/3_2/docutils_rstgen.o c_code/3_2/docutils_highlite.o c_code/3_2/sempass2.o c_code/3_2/guards.o c_code/3_2/stdlib_xmltree.o c_code/3_2/stdlib_macros.o c_code/3_2/stdlib_cgi.o c_code/3_2/stdlib_cookies.o c_code/3_2/typesrenderer.o c_code/3_2/stdlib_algorithm.o c_code/3_2/stdlib_sequtils.o c_code/3_2/pretty.o c_code/3_2/transf.o c_code/3_2/cgmeth.o c_code/3_2/lambdalifting.o c_code/3_2/lowerings.o c_code/3_2/vm.o c_code/3_2/vmgen.o c_code/3_2/vmdeps.o c_code/3_2/evaltempl.o c_code/3_2/aliases.o c_code/3_2/patterns.o c_code/3_2/semmacrosanity.o c_code/3_2/cgen.o c_code/3_2/ccgutils.o c_code/3_2/cgendata.o c_code/3_2/ccgmerge.o c_code/3_2/jsgen.o c_code/3_2/passaux.o c_code/3_2/depends.o c_code/3_2/docgen2.o c_code/3_2/service.o c_code/3_2/stdlib_parseopt.o c_code/3_2/modules.o  -ldl -lm
Undefined symbols for architecture x86_64:
  "_HEX00_prettybaseDatInit", referenced from:
      _PreMainInner in nimrod.o
  "_HEX00_prettybaseInit", referenced from:
      _PreMainInner in nimrod.o
  "_HEX00_semparallelDatInit", referenced from:
      _PreMainInner in nimrod.o
  "_HEX00_semparallelInit", referenced from:
      _PreMainInner in nimrod.o
  "_liftparallel_476918", referenced from:
      _genmagicexpr_568274 in cgen.o
  "_ncpicountProcessors", referenced from:
      _nospcountProcessors in stdlib_osproc.o
  "_replacedeprecated_291324", referenced from:
      _skipalias_292255 in lookups.o
  "_stdlib_cpuinfoDatInit", referenced from:
      _PreMainInner in nimrod.o
  "_stdlib_cpuinfoInit", referenced from:
      _PreMainInner in nimrod.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

A quick review shows that 3_2/prettybase.c and 3_2/stdlib_cpuinfo.c were not compiled and are missing from the linker statement. Furthermore, 3_2/ has 205 c source files, but only 108 were compiled to objects. Is the build process expecting to compile and link all of them?

I get this error when using the makefile. The archive at http://nim-lang.org/download/nim-0.13.0.tar.xz does not have this problem.

In README it says:

Building these will not result in the latest compiler being built, these C sources should be used in conjuction with koch.

Could you explain in README what is the exact difference between nim built from this repository and one that is built with koch? Is it not OK to use this repository for building non-development nim?

Shouldn't this repository track at least the revision used to build official releases? Meaning, there should be a v0.9.4 tag.

Some windows systems actually use gcc.bat to run gcc. This is fine, and everything works the same, but I used to run into an issue of the build(64).bat stopping after the first gcc call when I used this setup. I decided to check it out today, and it seems like if you want to keep running in the original batch file, you need to use "CALL" before calling a batch file. I'm submitting a PR for this, but I'm writing the issue here for reference.

I just tried building from source, as explained at http://nimrod-lang.org/download.html, but the build is failing:

clang -w -O3 -fno-strict-aliasing -Ic_code -c c_code/3_2/nimrod.c -o c_code/3_2/nimrod.o
clang: error: no such file or directory: 'c_code/3_2/nimrod.c'

It looks like the naming scheme of the files changed, and the references in build.sh should contain the appropriate prefixes (e.g., compiler_)?

In general, we want to be sure that a binary corresponds to the source that it claims to be built from. This is a hard problem (Thompson's "Trusting Trust" paper), but (e.g.) Debian's reproducible builds effort and "Diverse Double Compilation" can help improve our confidence in this security property.

However, the current build system is such that even if we assume outside tools (kernel, C compiler) are clean, we can still end up with a backdoored Nim compiler. This can be done similarly to "Trusting Trust" - it is possible to poison this csources repo (call this B0, which is effectively an opaque unverifiable binary), such that when a clean C compiler builds it into executable code (call this B1), B1 will run on the Nim compiler sources (Araq/Nim) in such a way that the resulting binary Nim compiler (call this B2) contains a backdoor. Further, B2 then can regenerate this csources repo exactly as B0, containing the exact same backdoor, which is still undetectable (opaque autogenerated C code), yet it "looks legit" since you have a converging bootstrapping process.

Hello,

I am able to build the boostrap nim compiler and successfully get it to boostrap and build nim itself. Where I run into trouble is when I try to install it.

koch install c:\compiler\nim\bin

it fails when it tries to do sh ./install.sh which is of course a unix command. I'm just wondering if I left something out or if perhaps there is a bug in koch? I poked around a bit to see if there was a corresponding install.bat but could not find one. Any thoughts?

Please run git tag v0.10.2 96a5b7fe23eb1964f2e68e455f14246b390b9507.

To build nim in Solaris please add "-lrt" to the link flag. Otherwise compilation will fail.

Please make a release that's able to compile Nim-0.10.2. It would help me make a better Gentoo ebuild and it would probably help all the other distro packagers that want a replicable build.

build.sh needs executable permissions. Otherwise cd csources && ./build.sh from the readme doesn't work.

It breaks aasdf-nim rfrancis/asdf-nim#5

When following the instructions for building Nim on Windows, the last line:

koch boot -d:release

throws an error during processing:

...\nim-devel\lib\packages\docutils\rstgen.nim(606, 6) Error: type mismatch: got (seq[string], proc (T, T): int)
but expected one of:
tables.sort(t: OrderedTableRef[A, B], cmp: proc (tuple[key: A, val: B], tuple[key: A, val: B]): int{.closure.})
tables.sort(t: CountTableRef[A])
tables.sort(t: var CountTable[A])
tables.sort(t: var OrderedTable[A, B], cmp: proc (tuple[key: A, val: B], tuple[key: A, val: B]): int{.closure.})
algorithm.sort(a: var openarray[T], cmp: proc (T, T): int{.closure.}, order: SortOrder)
FAILURE

A couple of weeks back it was working though.
If more information is needed, notify me.