[Bug]: quickjs cross compilation issues

Start with src/couch_quickjs/quickjs/Makefile and src/couch_quickjs/build_js.escript, then reproduce the reported cross-compilation failure and trace how qjsc is built and executed. Determine which supported approach is appropriate—host-built qjsc, a supplied executable, or a wrapper—and document CROSS_PREFIX or related configuration. Done means the chosen cross-compilation path works and its instructions are documented.

Version

3.5.2

Describe the problem you're encountering

TLDR

The vendored quickjs builds its qjsc for the target architecture, but it is executed during the build process.

Solutions:

1. Allow providing system installed qjsc

Suboptimal solutions:

1. Allow specifying an executable wrapper (so that the builder can provide Wine, QEMU or something custom)

2. Modify quickjs's build system to build qjsc for host architecture

   src/couch_quickjs/patches already seems to include some infrastructure on applying patches to the vendored project. A patch similar to the following one may be included in the already present list of patches:

   --- a/Makefile
   +++ b/Makefile
   @@ -264,7 +264,7 @@ qjs-debug$(EXE): $(patsubst %.o, %.debug.o, $(QJS_OBJS))
    	$(CC) $(LDFLAGS) -o $@ $^ $(LIBS)
    
    qjsc$(EXE): $(OBJDIR)/qjsc.o $(QJS_LIB_OBJS)
   -	$(CC) $(LDFLAGS) -o $@ $^ $(LIBS)
   +	$(HOST_CC) $(LDFLAGS) -o $@ $^ $(LIBS)
    
    fuzz_eval: $(OBJDIR)/fuzz_eval.o $(OBJDIR)/fuzz_common.o libquickjs.fuzz.a
    	$(CC) $(CFLAGS_OPT) $^ -o fuzz_eval $(LIB_FUZZING_ENGINE)
   

The fact that CROSS_PREFIX or argument overriding HOST_CC should be specified during cross compilation should be documented.

Introduction

I am trying to package couchdb for Void Linux. Void Linux prides itself with support for a plethora of architectures and glibc/musl support. It supports these architectures by cross compiling to them.

Right of the bat, the fact that couchdb doesn't use any higher level well established build system is an issue. The fact that the project uses a hand written configure script and an elaborate Makefile structure do not necessarily have to mean that the build system is less capable than CMake for example, but my experience shows that there is a very strong corelation between such endevaurs and configure/build errors + poor or nonexistant support for systems not exactly matching the developer's build environment.

Problem

I will comment on the src/couch_quickjs/quickjs/Makefile file. I assume it is part of couchdb. If it is vendored, please say so and I will make an issue in the appropriate repository.

This file includes a lot of hardcoded platform dependant logic which doesn't really belong there. This issue would be more aproachable if higher level build systems were used, but because Make lacks a standard mechanism to specify things like host and target compiler and executable wrapper (like Wine), it is understandable.

This makefile uses a handrolled cross compilation suport, which is to my knowledge completely undocumented. I was surprized that there even is a host/target compiler distinction.

Even though there is such a distinction, it doesn't seem to be that useful, because the qjsc executable is built for target architecture, even though it is later executed as part of the build process:

...
i686-pc-linux-gnu-gcc -fstack-clash-protection -D_FORTIFY_SOURCE=2 -O2 -pipe -march=i686   -I/usr/i686-pc-linux-gnu/usr/include -ffile-prefix-map=/builddir/couchdb-3.5.2=. -g -Wall -MMD -MF .obj/qjsc.o.d -Wno-array-bounds -Wno-format-truncation -Wno-infinite-recursion -fwrapv  -D_GNU_SOURCE -DCONFIG_VERSION=\"2025-09-13\" -DCONFIG_CC=\"gcc\" -DCONFIG_PREFIX=\"/usr\" -O2 -c -o .obj/qjsc.o qjsc.c
i686-pc-linux-gnu-ar rcs libquickjs.a .obj/quickjs.o .obj/dtoa.o .obj/libregexp.o .obj/libunicode.o .obj/cutils.o .obj/quickjs-libc.o
i686-pc-linux-gnu-gcc -Wl,-z,relro -Wl,-z,now -Wl,--as-needed    -L/usr/i686-pc-linux-gnu/usr/lib -g -o qjsc .obj/qjsc.o .obj/quickjs.o .obj/dtoa.o .obj/libregexp.o .obj/libunicode.o .obj/cutils.o .obj/quickjs-libc.o -lm -lpthread -ldl
make[1]: Leaving directory '/builddir/couchdb-3.5.2/src/couch_quickjs/quickjs'
escript: exception error: {command_failed,"/bin/sh: line 1: /builddir/couchdb-3.5.2/src/couch_quickjs/quickjs/qjsc: cannot execute: required file not found\n",
                                 127}
  in function  os:cmd/2 (os.erl:583)
  in call from build_js_escript__escript__1788__778366__612935__1573:compile_bytecode/2 (build_js.escript:76)
  in call from build_js_escript__escript__1788__778366__612935__1573:main/1 (build_js.escript:29)
  in call from escript:run/2 (escript.erl:906)
  in call from escript:start/1 (escript.erl:420)
  in call from init:start_it/1
  in call from init:start_em/1
  in call from init:do_boot/3
ERROR: Command [compile] failed!

quickjs/qjsc: ELF 32-bit LSB pie executable, Intel i386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=788d22328f0807aa30fee65d6256c07545c64749, for GNU/Linux 3.2.0, with debug_info, not stripped

I have little experience with erlang, but that file does not seem to include any support for an executable wrapper (like QEMU or Wine, which would be necessary to execute target built qjsc). I know little about couchdb's build system architecture, but from the little I know, I don't think qjsc is even needed to be built for target architecture, I think it is only used during the build process.

This issue could be rectified by letting the user provide their own qjsc. For example Void Linux already packages /usr/bin/qjsc in its quickjs-devel package. I saw no way of doing that from a brief glance at the build system.

Expected Behaviour

qjsc should be built for host architecture and/or there should be a way to provide a custom executable wrapper and/or there should be a way to provide a custom qjsc system installed executable.

Cross compilation support, including instructions on how to use it, like using CROSS_PREFIX, should be properly documented. If couchdb doesn't support cross compiling of if there is limited support for certain targets of for example musl, this should also be documented.

Steps to Reproduce

Try to cross compile the project.

Your Environment

I believe that I have described the issue sufficiently. My build environment depends on the Void Linux package builder. Reproducing that for someone unfamiliar with it would be difficult. But I can provide more details if requested.

Additional Context

No response