Core_kernel's META file references unix and pa_ounit.
And among its dependencies, there a few more unix requires:
for i in bin_prot variantslib sexplib fieldslib bigarray pa_ounit res ; do
cd ../$i ; pwd; cat META | grep unix ; cd - > /dev/null ;
requires = "unix bigarray"
requires = "unix bigarray num"
requires = "unix"
So I removed unix (and pa_onuit) from all the META files, and
then I got a linking error:
File "_none_", line 1:
Error: Error on dynamically loaded library:
undefined symbol: uerror
It seems to be (at least) in lib/channel_stubs.c:62.
Yeah, but unfortunately bigarray depends on Unix so there is not much we can do.
For uerror in channel_stubs.c we can probably return a Sys_error like the stdlib. I'll have a look.
I actually managed to get some core_kernel code running on client side with js_of_ocaml
(c.f. OCsigen mailing-list).
It works only when compiling from 32 bits architectures because of an annoying assert in Core_int63:
Of course, a lot of the code is invalid in that case (all the missing primitives are broken code).
PS: by putting console.log calls in those primitives, we can see that Core_kernel's intialization code is huge, hundreds of C functions calls are done at program startup just because of linking with the library.
( @ibnfirnas : weren't you talking about start-up time performance problems? )
OK, I'll try to do the same and see what we can do.
To solution to avoid the assert is to make sure Sys.word_size is the same as the one of the compiler. But for building on 64bits there is another problem: the initialization of the Nat module of OCaml fails.
The num initialization problem should be fixed in 109.53. It is not planned to remove the unix dependency at the moment due to the bigarray dependency, so I'm closing this issue.