The Network.DNS library contains a bit of helper C-code for determining the default DNS servers on Windows. This code is linked in by Cabal, when building object code for the library on Windows. The library also has 140 "doctest" examples in the haddock comments, which I'd like to test on Windows via AppVeyor. I'm not having much luck making the dependency on the cbits visible to the GHCi invocations executed by "Test.Doctest". Does anyone have some experience getting this sort of thing to work? What I've tried: 1. Add "-liphlpapi" into the "doctest" command argument list, this proved necessary, but not sufficient. 2. Build a separate internal library (supported in Cabal 2.0 and later), which is a dependency of the main library and links in the C glue code, but this proved to be a significant rabbit hole... In fact approach 2 seems like the more promising one, but it runs into a substantial obstacles: a. Building internal libraries requires a "Simple" Cabal build, but the cabal-doctest package which automates compiling doctests, requires a "Custom" build type. :-( b. A Simple build, means abandoning cabal-doctest, and using "doctest" directly, but the new sandbox builds place package artefacts in locations that the command-line invoked by "Test.DocTest.doctest" does not know how to find. It appears that the "Custom" build from cabal-doctest is there for a good reason: it hooks into Cabal's build process, and has access to enough metatata, to generate wrapper code that invokes doctest with an argument list of the form: -XCPP -i -i<DISTDIR>/build/<ARCHDIR>/<GHCVER>/<PKG>-<VER>/build/autogen -i<DISTDIR>/build/<ARCHDIR>/<GHCVER>/<PKG>-<VER>/build -i<SRCDIR> -package-env=- -hide-all-packages -no-user-package-db -package-db=<CABALGLOBALSTORE>/<GHCVER>/package.db -package-db=<DISTDIR>/packagedb/<GHCVER> -package-db=<DISTDIR>/build/<ARCHDIR>/<GHCVER>/<PKG>-<VER>/package.conf.inplace -optP-include -optP<DISTDIR>/build/<ARCHDIR>/<GHCVER>/<PKG>-<VER>/build/autogen/cabal_macros.h ...visible packages... ...modules to doctest... which are needed for the extracted doctest fragments to find their dependencies. Hard-coding such arguments into the "Simple" build seems to work, but is hardly maintainable. I've not yet found an interface in the Cabal library that would divulge these magic strings as a function of the "pkg.cabal" file, something of the shape: cabalMagicGhcArgs :: FilePath -> IO [String] would make it possible to compute the arguments at runtime (rather than build-time) in a Simple build, without having to use a Custom build to machine-generate wrapper code. Other than the above, I'm out of ideas for now, any help much appreciated. -- Viktor.