Getting lwt to compile with libev

Learning
1

I am trying to use libev with Lwt. Unfortunately it is failing on me.

Specifically the issue is that although I have installed conf-libev via opam, and libev-dev via apt, whenever I try to do

  Lwt_engine.set (new Lwt_engine.libev ()) ;

I get an error saying that libev is not found.

Primarily I am not sure how to approach debugging this, because I presume that this is just due to some system settings that I have. For reference I am using the Ubuntu 16 xenial docker image to do this development in.

An additional point is that when I installed conf-libev via opam, lwt was reinstalled and I would presume that that was to compile it with libev.

2

Could you show the precise message you get, and the commands you run, including for installing libev, conf-libev, and Lwt? Please also check that you are building against the same opam switch that you installed conf-libev in, i.e. make sure you have run eval `opam env` .

Try installing Lwt 4.3.0 with verbose output:

opam install lwt.4.3.0 --verbose

you will see a line that looks like this:

- libev ................................... skipped

what does yours say?

3

I’m seeing when installing lwt.4.3.0 (nothing for lwt.4.4.0…):

- libev ................................... skipped

That is within the same environment as conf-libev is installed in.

Installation is:

apt install libev-dev
opam install conf-libev lwt

This is on Ubuntu xenial I believe, in a root user environment (for other stuff the root user is required).

4

Yes, it has to be 4.3.0. That output is silenced in 4.4.0, but I might add a flag to restore it for this kind of debugging.

That you are getting skipped indicates that the Lwt install process isn’t detecting the conf-libev that you have installed in opam. The code it runs for doing that can be found here, perhaps you can try the command that Lwt is running. What version of opam are you using?

You should be able to work around this with

$ LWT_DISCOVER_ARGUMENTS="--use-libev true" opam install lwt.4.3.0 --verbose

However, I’d be very curious to know why the automatic detection is failing.

In my Ubuntu Xenial environment, I’m seeing

$ sudo apt install libev-dev
$ opam install conf-libev
$ opam install lwt.4.3.0 --verbose
- libev ................................. available

Are your commands running in a container I could get access to? Perhaps a stripped-down version of it, if it is proprietary?

5

So opam config var conf-libev:installed returns true… specifically:

root@f6c5c405a895:~# opam config var conf-libev:installed
[WARNING] Running as root is not recommended
true
root@f6c5c405a895:~# opam install lwt.4.3.0 --verbose
[WARNING] Running as root is not recommended
The following actions will be performed:
  - install   lwt  4.3.0
  - recompile logs 0.7.0 [uses lwt]
===== 1 to install | 1 to recompile =====
Do you want to continue? [Y/n] y

<><> Gathering sources ><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
[logs.0.7.0] found in cache
[lwt.4.3.0] found in cache

<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
+ /root/.opam/opam-init/hooks/sandbox.sh "build" "dune" "build" "-p" "lwt" "-j" "15" (CWD=/root/.opam/4.08.0/.opam-switch/build/lwt.4.3.0)
-     discover src/unix/lwt_features.{h,ml},src/unix/unix_c_flags.sexp,src/unix/unix_c_library_flags.sexp
- libev ................................... skipped
- pthread ............................... available
- eventfd ............................... available
- fd passing ............................ available
- sched_getcpu .......................... available
- affinity getting/setting .............. available
- credentials getting (Linux) ........... available
- credentials getting (NetBSD) ........ unavailable
- credentials getting (OpenBSD) ....... unavailable
- credentials getting (FreeBSD) ....... unavailable
- getpeereid .......................... unavailable
- fdatasync ............................. available
- netdb_reentrant ..................... unavailable
- reentrant gethost* .................... available
- st_mtim.tv_nsec ....................... available
- st_mtimespec.tv_nsec ................ unavailable
- st_mtimensec ........................ unavailable
- BSD mincore ......................... unavailable

They are running in containernet/containernet:latest. Just checking on that base container, it skips libev as well.

Will attempt the LWT_DISCOVER_ARGUMENTS approach now as well.

6

Libev comes up as availabile when LWT_DISCOVER_ARGUMENTS is used.

Thanks!

7

I opened an issue about looking into this. Is it correct to say that the workaround is good enough for your needs for the time being?