This request is for anyone who packages the Racket implementation for installation by an OS package manager (as opposed to people who manage Racket packages in the sense of raco pkg).
The upcoming v8.6 release will include an overhaul of the Racket build scripts. The intent is that configure and make work just as before, and we've tested on many platforms and configurations, but there's a good chance that there are still some problems. It would be better to discover lingering problems before the release.
So, if you can, please try building a snapshot as if it were a release, and let us know about any problems that you run into. Snapshot source distributions can be found here:
I'm getting the following error when using my usual ebuild on gentoo. The reason is because we traditionally build cgc-core first, and that option is now gone due to the transition to zuo. Is there an equivalent way to get the same results as the old make cgc-core?
Compiling source in /var/tmp/portage/dev-scheme/racket-8.6_pre1/work/racket-18.104.22.168/src ...
make -j73 -l8 cgc-core
make: *** No rule to make target 'cgc-core'. Stop.
Currently, there's not a makefile in the bc build directory. While configure and make are meant to work as before in the main src directory, I hadn't added bridge makefiles in src/bc or src/cs/c, because I didn't expect make to be used there.
Probably it's best to add makefiles and preserve the old behavior of being able to run configure and make within bc and cs/c. I'll make that change, and hopefully you can try again with the next snapshot.
I've pushed the change, calling the target just-racket3m instead of racket3m (to avoid the name of the generated file).
The build scripts have a notion of a POST_LINKER step, which is automatically defined as paxctl +m for NetBSD. Would that approach work better for pax marking in gentoo builds? If so, I could add --enable-postlinker=.... so it can be set via configure.
What is the right way in this context for Racket's build scripts to get a compiler whose output is for the host?
One possibility is that the Void script to derive a Racket build supplies HOSTCC=.
Another possibility is that there's already a good way to get a host compiler, and the Racket build scripts should use that.
Finally, a possibility is that builds aren't supposed to want a compiler for host-platform output, and Zuo needs to be built and available (in much the same way that a host Racket has been built) so that the Void script can supply ZUO=zuo (or something like that) when driving a Racket build.
This came up for Guix, too, but I worked around it by packaging Zuo separately and adding it as a build dependency, letting us supply ZUO=zuo.
I think the right thing is probably for Racket's configure to arrange to build Zuo so that Zuo's "host" is Racket's "build", in the Autoconf build/host/target sense. Sometimes such compiler for this scenario seems to be called CC_FOR_BUILD. I'm not sure what the best way to do this with Autoconf is—in particular, how much should be fixed at configure time vs. overridable at make time—but I did see ax_prog_cc_for_build (Autoconf Archive).
A packager may still need to add a suitable C toolchain to the build environment, depending on how sparse their default build environment is, but I think this would at least produce a descriptive error, rather than attempting to execute code for the wrong system.
With the recent fixes I have made if far enough to encountered a new issue, which is that it seems that cs-install and bc-install are the new names for install-cs and install-bc, however it seems that there is no longer a cgc-install.
Another point of strangeness is that calling make bc doesn't seem to actually build racketbc, e.g. you have to call make 3m in order for make install-bc to not fail due to missing racket3m? Should make bc be calling make 3m internally (via zuo)?
The fixes for --enable-shared seem to be working when I test them in git. I'll check again when the snapshot finishes building.
I have been able to use --enable-postlink to simplify the build process, the bridging make files for cgc-core and just-racket3m are still useful in cases where we don't need to pax mark absolutely everything.
Not sure what happened, but on master if I run ./configure or ./configure --enable-cs and then make cs I now get the following error
mkdir -p bin
cc -O2 -DZUO_LIB_PATH='"'".././zuo/lib"'"' -o bin/zuo ./zuo/zuo.c
bin/zuo . cs
cd cs/c/rktio/ && ../../../rktio/configure CC=gcc CFLAGS=-g" "-O2" "-Wall LDFLAGS=" "-pthread LIBS=-ldl" "-lm" "-lrt" "-lncurses" "-ltinfo" "-lz" "-llz4 AR=ar ARFLAGS=rc RANLIB=ranlib WINDRES=windres CPPFLAGS=" "-pthread --enable-pthread --enable-iconv
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for ranlib... ranlib
checking for fmod in -lm... yes
checking for dlopen in -ldl... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for intptr_t... yes
checking for uintptr_t... yes
checking whether byte ordering is bigendian... no
checking for struct dirent.d_namelen... no
checking for struct dirent.d_namlen... no
checking for xlocale.h... no
checking for xlocale functions... yes
checking for getaddrinfo... yes
checking iconv.h usability... yes
checking iconv.h presence... yes
checking for iconv.h... yes
checking iconv is usable... yes
checking for nl_langinfo (CODESET)... yes
checking for mbsrtowcs... yes
checking for poll... yes
checking for epoll... yes
checking for inotify... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating rktio_config.h
gcc -pthread -DPORTABLE_BYTECODE -Ics/c/ChezScheme/pb/boot/pb -Ics/c/ChezScheme/pb/c -IChezScheme/c/ -g -O2 -Wall -pthread -o cs/c/ChezScheme/pb/c/statics.o -c ChezScheme/c/statics.c
In file included from ChezScheme/c/system.h:46,
ChezScheme/c/segment.h: In function ‘S_object_to_reference’:
ChezScheme/c/segment.h:94:31: error: ‘reference_disp’ undeclared (first use in this function)
94 | return ((ptr)((uptr)(p) + reference_disp));
ChezScheme/c/segment.h:94:31: note: each undeclared identifier is reported only once for each function it appears in
ChezScheme/c/segment.h: In function ‘S_reference_to_object’:
ChezScheme/c/segment.h:101:31: error: ‘reference_disp’ undeclared (first use in this function)
101 | return ((ptr)((uptr)(p) - reference_disp));
ChezScheme/c/segment.h: In function ‘S_maybe_reference_to_object’:
ChezScheme/c/segment.h:124:31: error: ‘reference_disp’ undeclared (first use in this function)
124 | return ((ptr)((uptr)(p) - reference_disp));
make: *** [Makefile:23: cs] Error 1