-
Notifications
You must be signed in to change notification settings - Fork 122
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
add additional environment variables and add libraries/flags to linki… #636
Conversation
…ng tests to fix build issues in non-standard installs
FWIW, this solves many of the install problems (really linking problems) that occur with this library; albeit, this places the responsibility on the user to correctly configure the library. However, we're implicitly relying on them doing this by asking them to For example, I encountered problems linking Instead of doing ad hoc I was also able to use this PR (and @mseri While it's a bit of a burden for the user to learn about how to configure this, I could add in some tutorial material, and perhaps an install FAQ based on the install issues, and the future install problems can be reduced to figuring out the right combination of flags to pass via these proposed environment variables. |
I would very much welcome such a PR. I am used to setting linking and C flag variables for installing lacaml and gsl, and it works well there to use homebrew installed libs after reading some basic instructions in the respective READMEs. |
See owlbarn#636 Signed-off-by: Marcello Seri <[email protected]>
See owlbarn#636 Signed-off-by: Marcello Seri <[email protected]>
@nilsbecker I included the change both in my arm64 and arm64-bak (which includes also changes from the open PRs) branches if you want to test it out |
i just tied #625 (comment) and that worked for me -- i guess it's using your updated arm64 branch yes? |
Yes |
On another M1 mac I tried the same but keep getting a linker error that says one more try: |
@mseri How come the changes in your fork to support the M1 haven't been merged? Thanks for the work to fix it BTW. |
I don't know. You can check if |
indeed that did allow it to install! the working command line was: i.e. without adding a path to the separately installed lapack library. no idea why it was necessary on this machine and not the other one. |
ok, while disabling the lapacke linking did allow owl to get installed, it then does not work properly in an application. i get loads of linking errors saying that some lapacke symbols are not found. adding the brew-installed lapack to the |
I don't know, indeed |
no that should not be the problem. i did a rebuild of the homebrew installation from an exported package list. i just noticed that i have an env variable set: also my default |
i think the manual linking flags were from a previous workaround for installing owl. i just retried with |
Ok, I've got it now. Mea culpa. For a reason I cannot fathom, my full opam switch was an x86_64 binary without me knowing it. It silently ran under Rosetta2 but when trying to link arm64-only libraries, that did not work anymore somehow. So @mseri 's initial hunch was correct: some x86 cruft was still around: all of the switch! I was really convinced that this was a new install of ocaml via opam and not an old file tree transferred from a backup, but now i'm not so sure anymore. Bottom line: the intallation instructions referenced above, pinning @mseri 's branch do work for me now. |
* Progress towards ARM64 support Signed-off-by: Marcello Seri <[email protected]> * Re-introduce Ofast flag Signed-off-by: Marcello Seri <[email protected]> * unit_signal: fix test Signed-off-by: Marcello Seri <[email protected]> * Update architecture detection Signed-off-by: Marcello Seri <[email protected]> * ocamlformat Signed-off-by: Marcello Seri <[email protected]> * fixup! Update architecture detection * Improve architecture and os detection Signed-off-by: Marcello Seri <[email protected]> * config: cleanup unused open Signed-off-by: Marcello Seri <[email protected]> * reintroduce -mfpmath=sse on x86_64 Signed-off-by: Marcello Seri <[email protected]> * owl_macros.h: remove empty if * owl/configure: remove devmode cflags They break the compilation with some c compilers. See #609 Signed-off-by: Marcello Seri <[email protected]> * owl_core_utils: Fix empty elif Signed-off-by: Marcello Seri <[email protected]> * Cleanup arch detection code Signed-off-by: Marcello Seri <[email protected]> * configure: update to support new lapacke packages Debian now ships lapacke separately, requiring new set of flags for the linking to work. This uses pkg-config to improve the detection of these flags. Furthermore this commit adds a workaround to solve the issue with libgcc11_s not found, which will not be addressed upstream in homebrew for the time being. Signed-off-by: Marcello Seri <[email protected]> * ocamlformat the code Signed-off-by: Marcello Seri <[email protected]> * Workaround configurator problem with windows And remove march=native from arm, since it breaks on a number of arm systems Signed-off-by: Marcello Seri <[email protected]> * configurator: make more robust wrt not officially supported platforms (e.g. bsds) * Update src/owl/config/configure.ml Co-authored-by: Thomas Gazagnaire <[email protected]> * configurator: drop unnecessary dependency on stdio Signed-off-by: Marcello Seri <[email protected]> * add @jcreinhold patch for nonstandard setups See #636 Signed-off-by: Marcello Seri <[email protected]> * Update src/aeos/config/configure.ml * Update src/owl/config/configure.ml --------- Signed-off-by: Marcello Seri <[email protected]> Co-authored-by: Thomas Gazagnaire <[email protected]>
Close for now since the configuration has been updated. |
RFC
This PR addresses the problems raised in #635
For non-standard build setups, this adds
OWL_LDFLAGS
,OWL_CPPFLAGS
, andOWL_LDLIBS
which correspond to the usualgcc
flags.I personally don't think these are excessive, but we could change this to only add
OWL_LDFLAGS
(or, e.g.,OWL_LIBRARY_FLAGS
) which would be sufficient if this PR adds too many new environment variables. The current implementation in this PR, however, allows the user to specify flags like they would if they were directly usinggcc
. Even though the flags are eventually combined intoc_flags
andc_library_flags
, this allows users to not cram everything into something labeledOWL_CFLAGS
and (the minimally required for this to build)OWL_LDFLAGS
.This also adds the generated flags to the OpenBLAS linking tests with
c_test
which were previously failing for the reasons mentioned in #635. This change is required for non-standard builds; the linking test will fail simply because it's lacking the correct flags—even thoughowl
would build withOWL_CFLAGS
and something akin toOWL_LDFLAGS
.