Is there a way to get drracket going on NetBSD 10.1? Having racket-mini-8.15 installed and then performing
$ raco pkg install --auto drracket
there are ffi-lib issues, see as follows
Is there a way to get drracket going on NetBSD 10.1? Having racket-mini-8.15 installed and then performing
$ raco pkg install --auto drracket
there are ffi-lib issues, see as follows
I've never used NetBSD, but I'd recommend installing the racket-8.15nb1
package instead of the racket-minimal-8.15
. Presumably your distro package maintainers will have compiled racket-8.15nb1
with the appropriate linker directives so that dlopen()
can find the shared libraries for the GUI.
If you have tried to install DrRacket on top of the minimal distribution, you may need to rm -rf /u/van/.local/share/racket/8.15/
first to ensure you don't have conflicting copies of packages or other stale state.
Looking at the email you linked, my guess is that NetBSD's package manager may keep packages' shared libraries in a package-specific tree, rather than installing them into a global place like /usr/lib/
. This is an appealing approach in many ways for a package manager. (I maintain the distro package of Racket for Guix, which works that way.) However, it can create problems for dynamically loading shared libraries. With this style of package manager, you can pass appropriate linker flags when building an ELF executable to embed places to look for shared libraries in a DT_RUNPATH
(or DT_RPATH
) entry (see rpath - Wikipedia). However, this doesn't help if you don't know when building the ELF what places to look, e.g. because there are optional dependencies or user extensibility. In that case, you need some kind of search path that can be extended after the ELF has been built. One option for a package manager is to modify the search path used by ld.so
, either by changing its configuration or using LD_LIBRARY_PATH
, but this has various downsides. The other option is for an application that's aware of this problem to define its own search path and a means for extending it.
The Racket-specific way to configure extra directories to search for shared libraries is the lib-search-dirs
configuration entry. But this is rather obscure—for almost everyone, the right way to get Racket to find GUI shared libraries is to install a Racket distribution that is set up properly. It also requires picking the right places! In your email, I'm very suspicious that /usr/pkg/emul/linux/usr/lib64/libX11.so.6
might be a variant of libX11
for use related to Linux emulation or something, rather than a native NetBSD libX11
shared library.
Thank you. I have managed to run drracket from the complete racket-8.15 pkgsrc on NetBSD 10.1 but when I tried to build from the source redistribution, there were Makefile.inc Invalid line type messages leading to fatal errors after
cd cs/c/ChezScheme/pb/lz4/lib && /usr/bin/make liblz4.a
GNU Make is needed to build Racket if lz4 has to be built. But if you have liblz4.a
installed, then configure
should find and link to it instead of building a new copy.
The GNU Emacs autogen.sh
or configure
script finds the GNU Make to work with. NetBSD has the gmake
and make
convention for identifying which of the two.
Using gmake
goes as far as
gcc -g -O2 -Wall -pthread -o cs/c/raw_racketcs cs/c/main.o cs/c/boot.o cs/c/ChezScheme/ta6nb/boot/ta6nb/libkernel.a cs/c/ChezScheme/ta6nb/lz4/lib/liblz4.a cs/c/rktio/librktio.a -pthread -rdynamic -lm -lm -lpthread -lz
paxctl +m cs/c/raw_racketcs
cs/c/ChezScheme/ta6nb/bin/ta6nb/scheme -B cs/c/ChezScheme/ta6nb/boot/ta6nb/petite.boot -B cs/c/ChezScheme/ta6nb/boot/ta6nb/scheme.boot --script /u/van/src/racket-8.15/src/cs/c/to-vfasl.ss cs/c/ChezScheme/ta6nb/boot/ta6nb/petite.boot cs/c/petite-v.boot
cs/c/ChezScheme/ta6nb/bin/ta6nb/scheme -B cs/c/ChezScheme/ta6nb/boot/ta6nb/petite.boot -B cs/c/ChezScheme/ta6nb/boot/ta6nb/scheme.boot --script /u/van/src/racket-8.15/src/cs/c/to-vfasl.ss cs/c/ChezScheme/ta6nb/boot/ta6nb/scheme.boot cs/c/scheme-v.boot petite
cs/c/ChezScheme/ta6nb/bin/ta6nb/scheme -B cs/c/ChezScheme/ta6nb/boot/ta6nb/petite.boot -B cs/c/ChezScheme/ta6nb/boot/ta6nb/scheme.boot --script /u/van/src/racket-8.15/src/cs/c/to-vfasl.ss cs/c/racket.boot cs/c/racket-v.boot petite scheme
cs/c/raw_racketcs -O info'@'compiler/cm -l- setup --boot /u/van/src/racket-8.15/src/setup-go.rkt cs/c/compiled ignored cs/c/ignored.d /u/van/src/racket-8.15/src/cs/c/embed-boot.rkt --target ta6nb cs/c/raw_racketcs cs/c/racketcs cs/c/petite-v.boot cs/c/scheme-v.boot cs/c/racket-v.boot
seek in boot file petite failed
failed
in build-one
in loop
in module->hash
gmake: *** [Makefile:22: all] Error 1
seek in boot file petite failed
-- would this help? seek in boot file petite failed · Issue #5122 · racket/racket · GitHub
seek in boot file petite failed
-- would this help? https://github.com/racket/racket/issues/5122
This works with liblz4.so
, too. But in either case, if the library isn't installed in a global place, you may need to supply command-line arguments to tell the linker where to find it at build time. (This is essentially the same as dlopen()
not finding libraries, but recording where to look in the ELF file works fine in this case.)
Racket doesn't require GNU Make unless you want to build the few vendored dependencies that require it. My impression is that non-GNU make
users would prefer not to pull it in if they don't really need it. Racket does use Autoconf, but the situation is more complicated because LZ4 is a dependency of Chez Scheme, which doesn't use Autoconf. Possibly an Autoconf wizard could have configure
look for GNU Make as an optional dependency, then adapt the build scripts to specifically use GNU Make only when necessary and to report a better error if it's needed but not found … but that seems like a lot of work.
Yes, the NetBSD packagers applied the following patch for that issue in racket-8.15nb1
:
Indeed the patch is contributed by riastradh
Could the not found situation complication with LZ4, Chez Scheme, Autoconf, GNU Make be an opportunity to improve the initial sketchcoding AI assistants offered in xAI Grok, Google Gemini, Meta Code Llama, Microsoft Co‑pilot to reduce the amount of work? And, that would attract sponsorship and resources to the projects from those organizations in exchange for realworld problem solving feedback?