Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow .so dynamic libraries on Darwin #534

Merged
merged 2 commits into from
Apr 9, 2020

Conversation

kirelagin
Copy link
Contributor

See commit.

Not tested, because it causes a massive rebuild, and my computer is incompatible with building GHC.

This code is a hack that applied only to Darwin, it collects all
required dynamic libraries into a single directory. It does this by
listing all library dirs and then linkin all dynamic libraries in them.

Before this change, it would link only `*.dylib` files. This was a
problem, because (weirdly) a lot of libraries in Nixpkgs actually
produce .so even on Darwin (and, weirdly, this somehow works).

So we now link `.so` files as well.
@kirelagin
Copy link
Contributor Author

For searchability:

Fixes

ld: library not found for -lblas
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
`cc' failed in phase `Linker'. (Exit code: 1)

This piece of code `ln`s all libraries we might want to link with into a
single directory and then hides all previous directories from Cabal.
The problem is that this code only `ln`s dynamic libraries, however we
might want to link with some library that only comes in a static
version.

So, `ln` static `.a` libraries too so that they are found when linking.
@kirelagin
Copy link
Contributor Author

Oh look, there is already NixOS/nixpkgs#80191.

@hamishmack
Copy link
Collaborator

bors try

iohk-bors bot added a commit that referenced this pull request Apr 5, 2020
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Apr 5, 2020

@maksbotan
Copy link
Contributor

Hi.
I can confirm, that this patch helps to build Haskell library that depends on hmatrix package (which in turn depends on blas and lapack).

With haskell.nix master I get errors about not finding -lblas and -llapack, with this patch I do not.

However, linking of executables is still broken.

Please see https://github.com/maksbotan/nix-hmatrix-repro. If I do

nix-build -A nix-hmatrix-repro.components.exes.repro

I get this error:

Preprocessing executable 'repro' for nix-hmatrix-repro-0.1.0.0..
Building executable 'repro' for nix-hmatrix-repro-0.1.0.0..
[1 of 1] Compiling Main             ( Main.hs, dist/build/repro/repro-tmp/Main.o )
Linking dist/build/repro/repro ...
Undefined symbols for architecture x86_64:
  "__gfortran_concat_string", referenced from:
      _dormqr_ in liblapack.a(dormqr.f.o)
ld: symbol(s) not found for architecture x86_64
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
`cc' failed in phase `Linker'. (Exit code: 1)
builder for '/nix/store/87nxpk1zqgp75pch7s0v8whikz87v6cl-nix-hmatrix-repro-0.1.0.0-exe-repro.drv' failed with exit code 1

Note that to trigger this error the library must use certain functions from liblapack.a. In my case it's triggered with http://hackage.haskell.org/package/hmatrix-0.20.0.0/docs/Numeric-LinearAlgebra.html#v:geig

@maksbotan maksbotan mentioned this pull request Apr 7, 2020
@angerman
Copy link
Collaborator

angerman commented Apr 9, 2020

LGTM

@angerman angerman merged commit 16f43b2 into input-output-hk:master Apr 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants