The merged link needs the stubs archive, and must not name a libdl that is gone

lib/dev.ml

@@ -2062,6 +2062,13 @@ let compiler_object () =
             "-output-complete-obj";
             "-I"; Filename.quote (Filename.concat lib ".flan.objs/byte");
             "-I"; Filename.quote (Filename.concat lib ".flan.objs/native");
+            (* [lib] again, as a library search path. The macro work gave
+               [lib/dune] a [foreign_stubs] stanza, so [flan.cmxa] now records
+               a dependency on [-lflan_stubs] and the linker has to be told
+               where dune put the archive. Without this the merged object
+               fails with "cannot find -lflan_stubs" and only
+               [--two-process] works. *)
+            "-cclib"; Filename.quote ("-L" ^ lib);
             "-o"; Filename.quote tmp;
             Filename.quote cmxa; Filename.quote ml ]
       in

lib/dune

@@ -14,7 +14,12 @@
  (foreign_stubs
   (language c)
   (names dynload_stubs))
- (c_library_flags (-ldl)))
+ ; No (c_library_flags (-ldl)): since glibc 2.34 dlopen lives in libc itself
+ ; and libdl is a stub, and naming it breaks the merged build -- the partial
+ ; link -output-complete-obj performs cannot resolve -ldl, so `flan dev` in
+ ; one process fails at the link with "cannot find -ldl" while the ordinary
+ ; build is unaffected. Add it back only with a platform guard.
+ )
 
 ; The host shim is Flan's, not the user's, so the compiler carries it rather
 ; than looking for it in an install directory. Generated from the real .c files