Dependees not able to link with vendored C library since 2.1, using lang dune 1.8

[aantron]

Expected Behavior

git clone https://github.com/aantron/luv.git
cd luv
make test-installation
# should succeed

Actual Behavior

Produces

/usr/bin/ld: cannot find -luv
collect2: error: ld returned 1 exit status
File "caml_startup", line 1:
Error: Error during linking

This works if one inserts opam install dune.2.0.1 before make test-installation.

The Makefile target installs Luv, which contains a vendored libuv. It then tries to build a trivial test project against the installed Luv. It is linking the executable in this project that fails.

I checked that the compiled libuv.a is present in my switch's lib/luv/ directory:

$  ls _opam/lib/luv/ | grep libuv
libuv.a

This is the same whether using Dune 2.0.1 or 2.1.1.

The main project has

(lang dune 1.8)

EDIT: the test project has

(lang dune 1.0)

Specifications

• Version of dune (output of dune --version): 2.1.1 (also fails with 2.1.3; 2.1.1 is the minimal available version for which this failure occurs)
• Version of ocaml (output of ocamlc --version) 4.08.0
• Operating system (distribution and version): Ubuntu 16.04 in WSL1

[rgrinberg]

Do you think it would be possibly to port luv to use the foreign_library stanza? This is the approach that we'd like to support going forward, and it's too tough for us to debug everyone's specialized setups.

[aantron]

Yes, however I have to take exception with the idea that this is a specialized setup, as it's the ordinary setup that was supported by Dune until recently that Dune broke in a non-major release. I will update the Luv build system.

[rgrinberg]

Thanks, I apologize for the frustration and this is absolutely our own fault for not providing a proper mechanism to support this from beginning and leaving users to create their own fragile hacks. Here, the issue is that we’ve stopped passing the root dir of the library in the include path when linking. Instead, we’re relying on precise specification of library archives using our higher level stanzas (library, foreign_library). In retrospect, we could certainly bring this back and somehow warn users that they should not rely on this in a proper deprecation cycle. How feasible is it for you to just switch to foreign_library and cut off support for older dune’s? If it’s not feasible, then we’ll reconsider and re-introduce this behavior.

…

On Jan 24, 2020, 12:57 PM +0800, Anton Bachin ***@***.***>, wrote: Yes, however I have to take exception with the idea that this is a specialized setup, as its the ordinary setup that was supported by Dune until recently that Dune broke in a non-major release. I will update the Luv build system. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[aantron]

It's totally feasible, I wouldn't make any changes in Dune to support Luv.

Part of the reason this breaking change is "especially breaking" is that Dune has versioned syntax, so one would be surprised, if subscribing to a syntax less than 2.1, to see this broken by a change in 2.1, especially since older syntax shouldn't have foreign_library support as an option. That's part of the reason I reported it rather than just silently adapting. However, it is not a problem for Luv in particular. With luck, no other using projects are affected in a way that prevents easy adaptation.

[ghost]

Thanks for reporting @aantron. I agree with your interpretation. Let's just say that when it comes to C, there are a lot of ways to organise a project and less established conventions. As a result it's difficult for us to provide a 100% compatibility guarantee.

But agreed with @rgrinberg. If it was a problem or too many users were affected, we'd reconsider.

[aantron]

I'm closing this issue, as IMO nothing needs to be done at this point. Thanks for the discussions!