Compilation error with older version of libck

[justinethier]

Cyclone fails to compile with an older version of libck (0.4.??). This would not really be a problem except for the fact that it is the default version in Linux Mint, and possibly other distros. TBD if there is a way to (for example) detect version and adjust compilation as necessary.

[ararslan]

Something that the Julia language does that might be useful here is that we download and compile all dependencies ourselves as part of the build. That way we have full control over the versions used, any patches that need to be applied to ensure the libraries work as we expect them to with our supported platforms, and we don't have to rely on the availability (or lack thereof) of a particular library on the system. It also improves the user experience when building from source: they need only run make.

Anyway, just a suggestion.

[justinethier]

@ararslan That's a good idea, I like that. Does Julia have a compilation step though? Cyclone's third party dependencies are needed not just in the initial build but also when compiling and linking C code generated by our compiler. It may be necessary to adjust library paths to ensure the appropriate library version is linked, in case the host machine has another version installed. Anyway, just thinking out loud.

[ararslan]

Julia isn't statically compiled but we do distribute Julia with its dependencies compiled as shared libraries. This allows user code to call into them dynamically, which is a similar situation to requiring the libraries be available for linking. I could envision in this situation distributing Cyclone binaries with ConcurrencyKit and TomMath compiled as shared libraries. Then the generated linking step would just need to include a -L to Cyclone's private library directory.

[arthurmaciel]

Hi! On Linux Mint 19.1 the current version is 0.6.0-1.

[lassik]

Could CK_VERSION from the Concurrency Kit headers be checked?

$ echo '#include <ck_pr.h>' | cpp -dM -E - | grep CK_VERSION
#define CK_VERSION "0.6.0"

Only problem is, it's a string instead of an integer. Not sure whether C preprocessor conditionals can compare strings.

[justinethier]

@lassik I think the real solution here is to integrate the libck into the build somehow such that we are not relying on the proper version to be installed already on the system. We have done this for libtommath, which is (was) the only other external library dependency.

[justinethier]

See also #458 for a discussion of dependencies being pulled in by the system vs our build scripts.

It is a moot point if we can completely remove libck but I'm not sure that is a viable option at this time.

[xgqt]

0.4.0 seems quite outdated. On Gentoo most recent dev-libs/concurrencykit has version 0.7.1 (which is the latest CK tag on GitHub) & cyclone builds.

@arthurmaciel does cyclone build for you with 0.6.0? I think CK shouldn't be bundled if cyclone works with one (or maybe two) releases back (0.6.X / 0.5.X).

[arthurmaciel]

@xgqt, cyclone-bootstrap builds here, but breaks on tests (seems unrelated to libck):

$ sudo ./install.sh
(...)
cc icyc.c  -O2 -fPIC -Wall -Wno-shift-negative-value -Wno-unused-command-line-argument -Iinclude -c -o icyc.o
cc icyc.o scheme/base.o scheme/read.o scheme/write.o scheme/case-lambda.o scheme/char.o scheme/complex.o scheme/cxr.o scheme/eval.o scheme/file.o scheme/inexact.o scheme/lazy.o scheme/load.o scheme/process-context.o scheme/repl.o scheme/time.o scheme/cyclone/common.o scheme/cyclone/libraries.o scheme/cyclone/macros.o scheme/cyclone/transforms.o scheme/cyclone/ast.o scheme/cyclone/cps-optimizations.o scheme/cyclone/cgen.o scheme/cyclone/util.o scheme/cyclone/pretty-print.o scheme/cyclone/hashset.o scheme/cyclone/primitives.o libs/cyclone/concurrent.o libs/cyclone/foreign.o libs/cyclone/match.o libs/cyclone/test.o srfi/1.o srfi/2.o srfi/18.o srfi/27.o srfi/28.o srfi/60.o srfi/69.o srfi/106.o srfi/111.o srfi/113.o srfi/117.o srfi/121.o srfi/128.o srfi/132.o srfi/133.o srfi/143.o -pthread -lcyclone -lck -lm -lcyclonebn -ldl -L.  -Wl,--export-dynamic -o icyc
./cyclone -I libs -COPT '-Iinclude' -CLNK '-L.' tests/unit-tests.scm
./tests/unit-tests
(130 tests passed with no errors)
rm -rf tests/unit-tests tests/unit-tests.c tests/unit-tests.o
./cyclone -I libs -COPT '-Iinclude' -CLNK '-L.' tests/base.scm
./tests/base
vector literals: ..
2 out of 2 (100.0%) tests passed in 0.0 seconds.
strings: .
1 out of 1 (100.0%) test passed in 0.0 seconds.
(many minutes elapsed)
make: *** [Makefile:144: tests/base] Killed
make: ** Deleting file 'tests/base'

Makefile @ 144:

(...)

$(TESTS) : %: %.scm
	./cyclone -I libs -COPT '-Iinclude' -CLNK '-L.' $<
	./$@  <----
	rm -rf $@ [email protected] [email protected]

(...)

tests/base.scm

(...)

(test-group
  "vector literals"
  (test #(1 2) vec)
  (test vec (vector 1 2))
)

(test-group
  "strings"
  (test "??>" "??>")
)

(test-group
  "make-list"
  (test '() (make-list -2))
)

(...)

[justinethier]

@arthurmaciel This looks like https://github.com/justinethier/cyclone/issues/467 - would it be possible for you to re-test with the latest version of cyclone installed?

[arthurmaciel]

@justinethier, the problem was solved.

@xgqt, so yes, it builds with libck-0.6.0 on a Linux Mint 20.1 Ulyssa 5.4.0-80-generic SMP x86_64 machine.