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 mailto:nicu.ionita@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@haskell.org mailto:Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

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 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).

...

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

So beeing under the git bash in the project directory, I type: 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 mailto:nicu.ionita@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@haskell.org mailto:Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe