Compiling on Nixos/OSX/Windows ?

[MarcWeber]

Compiling Alloy on Nixos Linux:

   Compiling unwind v0.0.0 (/no-backup/alloy/library/unwind)
   Compiling adler v1.0.2
   Compiling rustc-demangle v0.1.23
error: could not find native static library `gc`, perhaps an -L flag is missing?

using nix-shell to add boehmgc from nixos:

eg using nix-shell -p boehmgc -> python x.py build yields above error.
Ok, that's the source shipped. Even nix-shell -p autoconf -p libtool -p automake then sh autoconf.sh make yields same.

./include/gc/gc.h|2361| GC_API void GC_init_tls_rootset(void * rootset);
alloc.c|1867| GC_INNER void GC_init_tls_rootset(void * rootset)

Reason could be that declarations are different eg GC_API differ from GC_INNER.
Most recent bdwgc seems to have changed much. Type missmatch was Google told me eventually causing such error.

Looks like you have your own version:

[submodule "src/bdwgc"]
	path = src/bdwgc
	url = https://github.com/softdevteam/bdwgc

Within docker ubuntu or such everything was fine. Maybe it's time to ask you what's best way to proceed ?

  In file included from /no-backup/alloy/src/bdwgc/extra/gc.c:50:
  /no-backup/alloy/src/bdwgc/extra/../alloc.c:1867:15: error: static declaration of ‘GC_init_tls_rootset’ follows non-static declaration
   1867 | GC_INNER void GC_init_tls_rootset(void * rootset)
        |               ^~~~~~~~~~~~~~~~~~~
  In file included from /no-backup/alloy/src/bdwgc/include/private/gc_priv.h:60,
                   from /no-backup/alloy/src/bdwgc/include/private/dbg_mlc.h:28,
                   from /no-backup/alloy/src/bdwgc/extra/../backgraph.c:15,
                   from /no-backup/alloy/src/bdwgc/extra/gc.c:40:
  /no-backup/alloy/src/bdwgc/include/gc/gc.h:2361:13: note: previous declaration of ‘GC_init_tls_rootset’ with type ‘void(void *)’
   2361 | GC_API void GC_init_tls_rootset(void * rootset);
        |             ^~~~~~~~~~~~~~~~~~~
  /no-backup/alloy/src/bdwgc/extra/../alloc.c:1872:16: error: static declaration of ‘GC_tls_rootset’ follows non-static declaration
   1872 | GC_INNER void* GC_tls_rootset()
        |                ^~~~~~~~~~~~~~
  /no-backup/alloy/src/bdwgc/include/gc/gc.h:2362:15: note: previous declaration of ‘GC_tls_rootset’ with type ‘void *()’
   2362 | GC_API void * GC_tls_rootset();
        |               ^~~~~~~~~~~~~~
  /no-backup/alloy/src/bdwgc/extra/../alloc.c:1867:15: warning: ‘GC_init_tls_rootset’ defined but not used [-Wunused-function]
   1867 | GC_INNER void GC_init_tls_rootset(void * rootset)
        |               ^~~~~~~~~~~~~~~~~~~
  make[2]: *** [CMakeFiles/gc.dir/build.make:76: CMakeFiles/gc.dir/extra/gc.c.o] Error 1
  make[1]: *** [CMakeFiles/Makefile2:841: CMakeFiles/gc.dir/all] Error 2
  make: *** [Makefile:146: all] Error 2
  thread 'main' panicked at /home/marc/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cmake-0.1.50/src/lib.rs:1098:5:

  command did not execute successfully, got: exit status: 2

There is src/bdwgc (your fork)

And on Ubuntu (within docker) I it worked with:
/usr/lib/x86_64-linux-gnu/libgccpp.so.1.4.1
/usr/lib/x86_64-linux-gnu/libgccpp.so.1

So what's the way to go?
Use your code ?
Try to use nixos and fix build.rs to find the shared libarries from env or
/run/current-system/ or such ?

[ltratt]

I don't have (I don't think any of us do) a nixos box, so can't comment on that: we really only test this on Debian (and maybe Arch). I wonder if you've not done a clone with submodules, perhaps?

[MarcWeber]

The x.py or config contained some nixos specific patch executable flags. So I looked it up: x.py build seems to install boehmgc to /usr/lib which is readonly on nixos systems or don't exist. So in that case a different install location must be chosen and it must be found by Rust. Then it probably works.

[ltratt]

Ah, yes, and you probably wouldn't have rights to install in /usr/lib. Definitely installing it elsewhere makes sense!

[MarcWeber]

Can you help me with the static error ? Because cd src/bdwgc configure make -> same on recent Ubuntu. My understanding is that bdwgc is a fork of boehmgc so it should just compile cause it's basically C

[ltratt]

Can you give the exact sequence of commands you're running (ideally starting at git clone) and then we can see if we can replicate it. [I tried quickly on Debian and everything worked, but I might e.g. have assumptions about what to do that aren't properly documented.]

[MarcWeber]

These work:
docker gcc debian

FROM debian

RUN apt-get update
RUN apt-get install -y git curl python3 cmake
RUN git clone --recurse-submodules https://github.com/softdevteam/alloy.git /root/alloy

RUN apt-get install -y gcc

RUN  cd /root/alloy; python3 x.py build

docker ubuntu clang

FROM ubuntu

RUN apt-get update
RUN apt-get install -y git curl python3 cmake
RUN git clone --recurse-submodules https://github.com/softdevteam/alloy.git /root/alloy

RUN apt-get install -y clang

RUN  cd /root/alloy; python3 x.py build

The ubuntu gcc version is missing c++ - probably could be fixed easily. So at least 2 versions to start finding out the difference.

[ltratt]

Just to check: with the above configurations you can compile Alloy? If so, then I would start looking at the differences in versions (e.g. of clang/gcc) between the configurations that succeed/fail. That might point out the culprit.

[MarcWeber]

I was interested in how far I would get compiling on OSX:

  -- Generating done (0.0s)
  -- Build files have been written to: /Users/marcweber/mw-repos/alloy/build/aarch64-apple-darwin/stage0-std/aarch64-apple-darwin/release/build/bdwgc-d7a747f95268f0b0/out/build
  running: cd "/Users/marcweber/mw-repos/alloy/build/aarch64-apple-darwin/stage0-std/aarch64-apple-darwin/release/build/bdwgc-d7a747f95268f0b0/out/build" && MAKEFLAGS="-j --jobserver-fds=8,9 --jobserver-auth=8,9" "cmake" "--build" "." "--target" "install" "--config" "Release"
  [  6%] Building C object CMakeFiles/gc.dir/gc_dlopen.c.o
  [  6%] Building C object CMakeFiles/gc.dir/misc.c.o
  [  9%] Building C object CMakeFiles/gc.dir/pthread_support.c.o
  [ 12%] Building C object CMakeFiles/gc.dir/darwin_stop_world.c.o
  [ 15%] Building C object CMakeFiles/gc.dir/gcj_mlc.c.o
  [ 18%] Building C object CMakeFiles/gc.dir/specific.c.o
  [ 21%] Building C object CMakeFiles/gc.dir/pthread_start.c.o
  [ 25%] Building C object CMakeFiles/gc.dir/thread_local_alloc.c.o
  [ 28%] Building C object CMakeFiles/gc.dir/fnlz_mlc.c.o

  --- stderr
  Explicit GC_INIT() calls may be required.
  /Users/marcweber/mw-repos/alloy/src/bdwgc/misc.c:1481:3: error: call to undeclared function 'GC_init_buffered_finalization'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
    GC_init_buffered_finalization();
    ^
  1 error generated.
  make[2]: *** [CMakeFiles/gc.dir/misc.c.o] Error 1
  make[2]: *** Waiting for unfinished jobs....
  make[1]: *** [CMakeFiles/gc.dir/all] Error 2
  make: *** [all] Error 2
  thread 'main' panicked at /Users/marcweber/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cmake-0.1.50/src/lib.rs:1098:5:

  command did not execute successfully, got: exit status: 2

  build script failed, must exit now
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Build completed unsuccessfully in 0:00:03

That's the result after removing the assertion about pointer/platform. So again bdwgc seems to be a limiting factor.

Is there any documentation why that version was used rather than latest official ? To me it feels like GC_malloc .. should be stable interface.

git remote add ivmai https://github.com/ivmai/bdwgc.git
seems to compile. So maybe rebasing the fork might make some of the issues go away? Any plans to give this a try ?

[jacob-hughes]

Can you show me your exact build steps for compiling on OSX?

It is not possible to compile Alloy with the official BDWGC library because we use a custom fork to support Rust features which would otherwise be unsound. Much of this is around finalisation and supporting thread-locals.

We have only tested Alloy on Linux with x86_64 machines because our fork contains non-portable code (e.g. for making roots discoverable from inside thread-locals) so I would imagine even if you were to get Alloy to compile on OSX you may encounter subtle GC bugs around this.