SQLite driver doesn't link with Eio

[F-Loyer]

I have the following dune file:

(executable
  (name main)
  (modules main)
  (libraries
      ppx_rapper_eio
      eio eio_main
      caqti-eio caqti-eio.unix
      caqti-driver-sqlite3)
  (preprocess (pps ppx_rapper)))
(executable
  (name main2)
  (modules main2)
  (libraries
      ppx_rapper_lwt
      lwt lwt.unix
      caqti-lwt caqti-lwt.unix
      caqti-driver-sqlite3)
  (preprocess (pps ppx_rapper)))

main2.ml contains the Lwt version and works well. The main.ml is the equivalent with Eio, but print the following error at the execution:

Failed to load driver for : Neither caqti-driver-sqlite3 nor the dynamic linker is linked into the application.

Note, a dune build --verbose ./main.exe shows:

/home/loyer/.opam/5.0.0/lib/sqlite3/sqlite3.cmxa -I /home/loyer/.opam/5.0.0/lib/sqlite3 /home/loyer/.opam/5.0.0/lib/caqti-driver-sqlite3/caqti_driver_sqlite3.cmxa

among the files included in the link phase.

[paurkedal]

Do you have an updated switch, including Caqti 2.1.1, and did you pin anything other than the ppx_rapper packages? Does the following work for you if you comment out the ppx_rapper* references from the dune file?

let () =
  Eio_main.run @@ fun env ->
  Eio.Switch.run @@ fun sw ->
  let uri = Uri.of_string "sqlite3:essai.sqlite" in
  let (module C) =
    Caqti_eio_unix.connect ~sw ~stdenv:(env :> Caqti_eio.stdenv) uri
    |> Caqti_eio.or_fail
  in
  C.disconnect ()

If so, I think I'll need a minimised version of your code and information about how you pinned the ppx_rapper_eio.

[janilcgarcia]

I want to report I was having the same issue (version 2.1.1 for everything), but it was caused by me using Caqti_eio.with_connection instead of Caqti_eio*_unix*.with_connection.

[paurkedal]

@janilcgarcia Thanks, I didn't realize originally this was likely the issue. The error message for this case was rather uninformative and even confusing, which should be fixed by the commit referred above. @F-Loyer Can you confirm that your code was using Caqti_eio instead of Caqti_eio_unix?

[paurkedal]

I'm closing this under the assumption that mail.ml used the non-unix entry point and that the improved error message should make the case clear in future versions.

[rizo]

For someone who might run into a similar issue, just wanted to add that I was also using Caqti_eio instead of Caqti_eio_unix and was getting a pretty cryptic error:

Fatal error: exception Failed to load driver for <sqlite3:db.sqlite3?write=true>: Neither caqti-driver-sqlite3 nor the dynamic linker is linked into the application.

Switching to Caqti_eio_unix.connect solved it. The error message could certainly be improved :)

[paurkedal]

In future releases, the message, if we don't make further changes, will be:

Fatal error: exception Failed to load driver for <sqlite3:db.sqlite3?write=true>: A suitable driver for the URI-scheme sqlite3 was not found after linking in caqti-driver-sqlite3. Your entry point provides the networking but not the unix component, which is required by drivers based on C bindings.

[rizo]

That's much better, thanks @paurkedal!

Maybe it's one of those cases, where including a link to this issue or some other place, would actually be the best option.

[paurkedal]

I would prefer making the error message and documentation precise enough over relying on a link to the GitHub issue. There is a statement

This module provides connections to the PGX database for Eio applications. For other database systems, you will need Caqti_eio_unix.

in the module documentation of Caqti_eio, but maybe "Your entry point [...]" is a too vague reference to it?

[rizo]

Just to be clear, I have no strong preference as long as the error is clearer and I think your reworded error message is already substantially better!

With that said, here are my thoughts:

• Completely understand the preference not to include the link to the issue. But hey, what most users will do is search the error message and hopefully they'll find this issue anyway :)
  • Funny enough, I searched for "Neither" in the source code and the issues and that's how I ended up here.
• IMO, the module documentation helps avoiding the error, but does not help fixing it, since the user won't necessary know what is happening in the first place and where to look for solutions. I did read the docs, and mistakenly thought I was already using the _unix entry point. The original error did not tell me that my assumption was wrong.
• I do agree that "Your entry point" is not as clear as just Caqti_eio. Unless there's some kind of ambiguity, I'd use that. Also, maybe explicitly mentioning Hint: are you using Caqti_eio, instead of Caqti_eio_unix? would be ok?

Thanks for looking into this.