[109]matica:msdb$ ocamlbuild src/main.native
Finished, 1 target (0 cached) in 00:00:00.
+ ocamlfind ocamlopt -thread -linkpkg -package lwt.syntax -package lwt.extra -package lwt -package cohttp -package aws.cohttp src/config.cmx src/keys.cmx src/misc.cmx src/command.cmx src/benchmark.cmx src/tools.cmx src/main.cmx -o src/main.native
/usr/lib/ocaml/lwt/liblwt-unix.a(lwt_libev_stubs.o): In function `ev_loop':
(.text+0x20): undefined reference to `ev_run'
/usr/lib/ocaml/lwt/liblwt-unix.a(lwt_libev_stubs.o): In function `ev_unloop':
(.text+0x4a): undefined reference to `ev_break'
collect2: ld returned 1 exit status
File "caml_startup", line 1, characters 0-1:
Error: Error during linking
Command exited with code 2.

Looks like when lwt_unix.cmx is built, the -dlib option for libev is not being passed.

It works when compiling to bytecode.

On Sat, 25 Jun 2011 15:59:40 -0700 Ian Zimmerman <itz@buug.org> wrote:

The problem is that the dependency on libev-dev is not versioned.  I had
both libev3 and libev4 installed, plus libev-dev 3.x.

Le 26/06/2011 07:34, Ian Zimmerman a écrit :

It depends on the libev it was compiled with. It's unfortunate that you
can have both libev4 and libev-dev 3.x installed at the same time... on
the other hand, compiling lwt with libev-dev 1:3.9-1 generates the
correct dependency to libev3, and working packages, so it doesn't sound
right to version the dependency to libev-dev. I am not aware of another
way to fix this, though.

According to your original report:

you have both stable and testing in your sources.list, and you have
libev-dev from stable, and liblwt-ocaml-dev from testing. Are we
supposed to support such a mix as a development environment? Lwt is
surely not the only package in this situation...


Cheers,

On Sun, 26 Jun 2011 12:34:46 +0200 Stéphane Glondu <glondu@debian.org> wrote:

Ian> The problem is that the dependency on libev-dev is not versioned.
Ian> I had both libev3 and libev4 installed, plus libev-dev 3.x.

Stéphane> you have both stable and testing in your sources.list, and you
Stéphane> have libev-dev from stable, and liblwt-ocaml-dev from
Stéphane> testing. Are we supposed to support such a mix as a
Stéphane> development environment? Lwt is surely not the only package in
Stéphane> this situation...

This particular situation was an accident, there was no good reason for
me to not upgrade the libev-dev package.  But there are many very real
reasons to keep stable in the mix.  That is why CUT is needed.

So yes, I'd say that the fact the dependency is too loose to catch this
pernicious problem on a system configured this way is a bug.  (I'm not
asking for "support" beyond fixing bugs, though) ;-)

"accident"?

Regards,

Le 26/06/2011 17:47, Ian Zimmerman a écrit :

In my opinion, the versioned dependency to libev-dev in liblwt-ocaml-dev
should be filled automatically, the same way it is for liblwt-ocaml. But
I don't know how to do it. dpkg-shlibdeps doesn't seem to be designed to
work this way. If so, I would say the bug is on dpkg-shlibdeps's side;
however it looks like a corner case, whose fix looks difficult and
intrusive...

I've put debian-dpkg in CC. Let's see if someone there has a suggestion.


Cheers,

Hi!

I've read the bug report for some context. Something unrelated to
this query I'd like to point out is that there's really nothing
inherently wrong with having more than one SONAME installed for the
same shared library, and having a single libfoo-dev. If libfooN and
libfooN+1 were not co-installable that would make transitions very
painful.

I don't think this should be solved by dpkg-shlibdeps, because this
kind of dependency (in most cases) does not involve directly a shared
library package, the problematic relationship is between packages
providing static libraries and headers (even though the roo cause is
that the dynamic library package might be out of sync, AFAIUI the
ocaml case).

The current way to solve this kind of issue is by using a substvar
computed from the debian/rules file.

I think this could be made easier to solve with something similar to
what's requested in #689062. If so, I'll work on a syntax proposal for
a new substvar.

Thanks,
Guillem