Native dependencies on Windows with stack


#1

I am completely stuck trying to get a stack build with a native library dependency to work on Windows. The concrete problem occurs with htaglib/TagLib, but I assume it’s a generic native dependency issue.

On Linux (Ubuntu), there’s no problem - I just installed the libtag package via apt, added the dependency to my cabal file, added import line and some code to a .hs file, and the build worked just fine.

I’m neither familiar with C/C++ builds nor with Windows, so for the time being I wanted to avoid building TagLib from scratch and instead hoped to get away with grabbing the dlls from cygwin. So now I have libtag.dll and libtag_c.dll in C:\cygwin64\usr\x86_64-w64-mingw32\sys-root\mingw\bin, but I have no idea how to inject them into the build dependencies.

I have tried to refer to the containing folders (both the original cygwin location and a lib folder in the project root) via extra-lib-dirs: both in stack.yaml and the global config.yaml. I have come across this bug and tried the workaround using ghc-options: -L... (as well as extra-lib-dirs:) in the cabal file. I have experimented with all file separator variants: slash, back slash, double back slash.

Whatever I do, it boils down to one of two outcomes:

  • If there is no lib folder in the project root, I get
    <command line>: can't load .so/.DLL for: tag_c.dll (addDLL: tag_c or dependencies not loaded. (Win32 error 126))
     ghc.EXE: addLibrarySearchPath: C:\path\to\project\lib (Win32 error 2): Das System kann die angegebene Datei nicht finden.   
    

(german locale, “system cannot find the file”)

  • With a 'lib` folder present, I get
    <command line>: can't load .so/.DLL for: C://path//to//project//lib/libtag_c.dll
      (addDLL: C:\\path\to\project\lib\libtag_c or dependencies not l)
    

I have run stack with -v --cabal-verbose and I’m at least seeing the "-LC:\cygwin64\usr\x86_64-w64-mingw32\sys-root\mingw\bin" (from the cabal file workaround) in the ghc args.

Does anybody have an idea what I’m doing wrong, or can somebody point me to a working minimalist example of a Windows stack build with native dependencies? (Again, probably doesn’t need to be TagLib, any native dependency will probably do.) Any help is appreciated.

Thanks and best regards,
Patrick


#2

Turns out the build works if all required .dlls are placed directly at the project root. m( Still, this can’t be the proper setup, no…?


#3

Using taglib on Windows (Qt Forum - 28 Jun 2016)

It looks like testing has been done on VS and MinGW.

Welcome to the Interix UNIX utilities.

DISPLAY=localhost:2.0
$ ed taglib-1.11.1/INSTALL
5581
52,55p
Tested with:
  Microsoft Visual Studio 2010
  Gcc by mingw-w64.sf.net v4.6.3 (Strawberry Perl 32b)
  MinGW32-4.8.0
q
$ exit

MinGW and MSYS/MSYS2 run in the win32 or win64 subsystem.

The Cygnus port (a.k.a. Cygwin) is a POSIX layer running above win32/win64.

On Windows-Native maintain all your C++ coöperating programs compiled with the same compiler, i.e., in this instance use MinGW or VS compiled code.

Interix (Tcler’s Wiki - Updated 25 Oct 2016)

Interix (known as Microsoft SFU)

+----------------------------+-----------------+-------------------+-------------------+
| Firmware                   | Firmware        | Firmware          | Firmware          |
+----------------------------+-----------------+-------------------+-------------------+
| NT Kernel                  | NT Kernel       | NT Kernel         | NT Kernel         |
+----------------------------+-----------------+-------------------+-------------------+
| Win32                      | Win32           | Win32             | Services for Unix |
+----------------------------+-----------------+-------------------+-------------------+
| NTVDM                      | NTVDM           | Cygwin            | Posix Application |
+----------------------------+-----------------+-------------------+-------------------+
| Windows on Windows         | DOS Application | Posix Application |                   |
+----------------------------+-----------------+-------------------+-------------------+
| 16-bit Windows Application |                 |                   |                   |
+----------------------------+-----------------+-------------------+-------------------+

OS/2 content omitted from the table for purposes of brevity.

In Windows 8.0 SFU/SUA Interix was deprecated.

GHC can be installed also into WSL.

p9p blog Post (if you want an X Server)

https://nurmi-labs.github.io/blog/screenshots.html
WSL


#4

Thanks a lot for the pointers! However, I’m not sure this gives me a lead on my specific issue - instructing a stack/cabal build on Windows to find the native dlls required by some 3rd party library like htaglib.

The Qt forum thread seems unrelated to Haskell, and the OP there seems to have placed their dlls in the project folder root, anyway - which worked for me, too, as reported above, but which feels wrong, going around extra-lib-dirs and friends in cabal/stack.

If I understand correctly, the rest of your information seems to be more geared towards building C++ libs and/or getting an integrated C++ development/build environment on Windows. I’d like to stay away from this as far as possible. :wink: I’m developing on Linux and just want to be able to do a Windows build (in a Win 10 VM).


#5

https://docs.haskellstack.org/en/stable/developing_on_windows/

This above page indicates Stack comes with an installation of msys2.

I’d assume any taglib .dll and .a files would be installed into the msys2 tree.


grabbing the dlls from cygwin

C:\cygwin64\usr\x86_64-w64-mingw32\sys-root\mingw\bin

Running in win64 I don’t understand your reference to the Cygnus port (a.k.a. Cygwin).


#6

FWIW, a compile of taglib on a legacy VS was uneventful.


#7

Thanks, this looks interesting. I’ll take a look at msys2/pacman.

As I said, I wanted to avoid setting up a full native dev stack in order to build the lib from source, at least for the first step, so I just copied the lib dlls from cygwin.


#8

How does MSYS2 differ from Cygwin (GitHub)

Packages

  • mingw64 : Containing 64-bit native Windows software (compiled with mingw-w64 x86_64 toolchain)