Skip to content

Core_kernel still depends on "unix" #1

Closed
smondet opened this Issue Jun 7, 2013 · 6 comments

3 participants

@smondet
smondet commented Jun 7, 2013

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 ;
done

OPAMROOT/4.00.1/lib/bin_prot
requires = "unix bigarray"
OPAMROOT/4.00.1/lib/variantslib
OPAMROOT/4.00.1/lib/sexplib
requires = "unix bigarray num"
OPAMROOT/4.00.1/lib/fieldslib
OPAMROOT/4.00.1/lib/bigarray
requires = "unix"
OPAMROOT/4.00.1/lib/pa_ounit
OPAMROOT/4.00.1/lib/res

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:
OPAMROOT/4.00.1/lib/stublibs/dllcore_kernel_stubs.so:
OPAMROOT/4.00.1/lib/stublibs/dllcore_kernel_stubs.so:
undefined symbol: uerror

It seems to be (at least) in lib/channel_stubs.c:62.

@diml
janestreet member
diml commented Jun 7, 2013

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.

@smondet
smondet commented Jun 8, 2013

Hi

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:
https://github.com/janestreet/core_kernel/blob/master/lib/core_int63.ml#L9

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? )

@ibnfirnas

Yep. +1

@diml
janestreet member
diml commented Jun 10, 2013

OK, I'll try to do the same and see what we can do.

@diml
janestreet member
diml commented Jun 11, 2013

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.

@diml
janestreet member
diml commented Nov 29, 2013

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.

@diml diml closed this Nov 29, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.