[Haskell-cafe] Trying desperately to make a c library binding on Windows - solved!

Nicu Ionita nicu.ionita at acons.at
Fri Mar 18 22:17:01 UTC 2016


Thanks for this information, didn't know it, I will begin to work like 
this too.
Beeing the first time when I try to link to external C libs I guess 
there will be more to learn anyway :-)
Nicu

Am 18.03.2016 um 22:40 schrieb Michał Antkiewicz:
> I always use the MSYS/MinGW provided with stack. It has pacman and
> everything so there's no need to have a custom installation of MSYS
> (which I used to do before).
>
> You can start the shell using the script
>
> mingw64_shell.bat
>
> located in
>
> C:\Users\<user name>\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512
>
> Glad it worked out.
> --
> Michał
>
>
> On Fri, Mar 18, 2016 at 4:53 PM, Nicu Ionita <nicu.ionita at acons.at> wrote:
>> This was really dumb.
>>
>> My MinGW was just a 32 bit installation, but the stack is version 1.0.4.2
>> x86_64, so (I guess) the default arch of the project is x86_64.
>>
>> The extra-lib-dirs & extra-libraries were ok, but trhu the filters of stack
>> I could not see that ld ignored the incompatible libraries. So it looked
>> (even with --verbose) like the libraries were not found, when in fact they
>> were just incompatible.
>>
>> Now at least this is clarified.
>>
>> Sorry for the noise.
>>
>> Nicu
>>
>> Am 18.03.2016 um 00:05 schrieb Nicu Ionita:
>>> What I don't understand is why the stack message sounds:
>>>
>>> If the library is already installed but in a non-standard location then
>>> you can use the flags
>>> --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
>>>
>>> Why would be an include directory necessary, if I only miss the library? I
>>> understand that the includes are needed to compile the (generated) C
>>> sources, but why needed to link? Or is maybe just a typo in the stack
>>> message?
>>>
>>> Nicu
>>>
>>> Am 17.03.2016 um 23:50 schrieb Nicu Ionita:
>>>> Am 17.03.2016 um 23:24 schrieb Theodore Lief Gannon:
>>>>>> I am on Win 7, using stack (configured for lts-4.2) under MinGW.
>>>>> Stack itself provides MSYS2/MinGW during builds on Windows. Do you mean
>>>>> you have an independent MinGW shell that you're opening, and then running
>>>>> stack from there?
>>>>
>>>> Yes, I work under the git bash (git for Windows comes with an own msys).
>>>>
>>>>> If so, assuming you're not already using this flag, try:
>>>>>
>>>>> stack build --skip-msys
>>>>
>>>> Just tried that now, same result.
>>>>>
>>>>> This tells stack that it's already running inside a unix-style shell,
>>>>> and shouldn't assert its related path overrides.
>>>>>
>>>>> Beyond that, it would help to have more information about exactly where
>>>>> everything is and how it's being built/invoked/etc.
>>>>
>>>> Project is under:
>>>> J:\Projects\BaseOh
>>>>
>>>> Library is under:
>>>> J:\BO\lib
>>>>
>>>> and is called:  libbayesopt.a
>>>>
>>>> (under bash they are called /j/Projects/BaseOh and /j/BO/lib, needless to
>>>> say I tried those too, but they are not found, as the programs know only
>>>> Windows style paths).
>>>>
>>>> So beeing under the git bash in the project directory, I type:
>>>>> stack build
>>>> or even:
>>>>> stack build --extra-lib-dirs=j:\\BO\\lib
>>>> But in both cases, if the line "extra-libraries: bayesopt" is present in
>>>> the cabal file, then configure does not work (message below).
>>>>
>>>> Inbetween I upgraded stack (now is version 1.0.4.2 x86_64). When I try to
>>>> build, I get the message:
>>>>
>>>> Continuing despite missing tool: msys2
>>>>
>>>> after which the build continues and brings exactly the same failures.
>>>>
>>>>> On Thu, Mar 17, 2016 at 2:19 PM, Nicu Ionita <nicu.ionita at acons.at
>>>>> <mailto:nicu.ionita at acons.at>> wrote:
>>>>>
>>>>>      Hi all,
>>>>>
>>>>>      I am really stuck with my try to make a Haskell binding for the
>>>>>      library bayesopt on Windows.
>>>>>      In theory it looks all simple, just put some lines in the cabal
>>>>>      configuration file:
>>>>>
>>>>>      ...
>>>>>      extra-lib-dirs:      /path/to/the/lib    -- contains the file
>>>>>      libbayesopt.a
>>>>>      extra-libraries:    bayesopt
>>>>>      ...
>>>>>
>>>>>      But whatever I tried, I can't step over the configuration phase,
>>>>>      coz I get (I'm compiling with stack):
>>>>>
>>>>>      Configuring BaseOh-0.1.0.0...
>>>>>      setup-Simple-Cabal-1.22.5.0-x86_64-windows-ghc-7.10.3.exe: Missing
>>>>>      dependency
>>>>>      on a foreign library:
>>>>>      * Missing C library: /j/BO/lib/libbayesopt.a
>>>>>      This problem can usually be solved by installing the system
>>>>>      package that
>>>>>      provides this library (you may need the "-dev" version). If the
>>>>>      library is
>>>>>      already installed but in a non-standard location then you can use
>>>>>      the flags
>>>>>      --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
>>>>>
>>>>>      If I comment those lines out, then the configure phase succeeds,
>>>>>      the library is compiled (i.e. my binding library), but a test
>>>>>      executable in the same project does of course not compile, as
>>>>>      symbols are missing:
>>>>>
>>>>>      ...
>>>>>      In-place registering BaseOh-0.1.0.0...
>>>>>      Preprocessing executable 'test' for BaseOh-0.1.0.0...
>>>>>      [1 of 2] Compiling Optimisation.Stochastic.BayesOpt (
>>>>>      src\Optimisation\Stochasti
>>>>>      c\BayesOpt.hs,
>>>>> .stack-work\dist\x86_64-windows\Cabal-1.22.5.0\build\test\test-tm
>>>>>      p\Optimisation\Stochastic\BayesOpt.o )
>>>>>      ghc.exe: unable to load package `BaseOh-0.1.0.0'
>>>>>      ghc.exe:
>>>>> J:\Projects\BaseOh\.stack-work\dist\x86_64-windows\Cabal-1.22.5.0\build
>>>>>      \HSBaseOh-0.1.0.0-GdNObdePATgDIW1I2OVwEc.o: unknown symbol
>>>>>      `initialize_parameter
>>>>>      s_to_default'
>>>>>
>>>>>      --  While building package BaseOh-0.1.0.0 using:
>>>>>      ...
>>>>>
>>>>>      Does somebody have some idea, what is going on?
>>>>>
>>>>>      I am on Win 7, using stack (configured for lts-4.2) under MinGW.
>>>>>      (I'm using inline-c to make the bindings, and the same trick for
>>>>>      include - include-dirs: ... - worked fine.)
>>>>>
>>>>>      Thanks, and sorry for the longer email.
>>>>>      Nicu
>>>>>      _______________________________________________
>>>>>      Haskell-Cafe mailing list
>>>>>      Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe



More information about the Haskell-Cafe mailing list