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

split libpolymake_julia into separate repo #304

Merged
merged 12 commits into from
Aug 11, 2020
Merged

Conversation

benlorenz
Copy link
Member

@benlorenz benlorenz commented Jul 2, 2020

libpolymake-julia lives here: https://github.com/oscar-system/libpolymake-julia
I have deployed a first set of binaries: https://github.com/benlorenz/libpolymake_julia_jll.jl

advantages:

  • this should fix any GLIBCXX errors
  • removes the need for the xcode workaround
  • recommended by cxxwrap and a further step towards Pkg artifacts
  • faster installation as no compilation is needed

disadvantages:

  • disabled custom path for polymake / libpolymake-julia for now as it would be quite an effort to determine all the required paths
    one could try to install a custom polymake + libpolymake_julia into deps/usr after installing the binaries once, as long as all products are satisfied this should not be overwritten
  • I have no idea about compatibility with different cxxwrap versions, we cannot really provide binaries built with different libcxxwrap-julia versions, so probably this will pin us to 0.11, github actions will hopefully tell us more

benlorenz and others added 5 commits July 2, 2020 13:25
disabled custom path for polymake / libpolymake-julia for now
only the libcxxwrap version used at build-time seems relevant here
try to run on ubuntu 20.04 as well
@saschatimme
Copy link
Collaborator

saschatimme commented Jul 2, 2020

disabled custom path for polymake / libpolymake-julia for now as it would be quite an effort to determine all the required paths

Does this mean you cannot point to your own local polymake installation anymore?

@benlorenz
Copy link
Member Author

disabled custom path for polymake / libpolymake-julia for now as it would be quite an effort to determine all the required paths

Does this mean you cannot point to your own local polymake installation anymore?

unfortunately yes, at least for now
using your own polymake installation will also require having your own libpolymake-julia installation

@benlorenz
Copy link
Member Author

so according to github actions both cxxwrap 0.11 and cxxwrap 0.10 work, but 0.9 complains about a missing symbol. not really surprising since we built the library with latest libcxxwrap 0.8 (from cxxwrap 0.11).
I guess we can drop support for 0.9.

@benlorenz
Copy link
Member Author

For a custom installation we need to have the path to a libpolymake-julia installation (containing shared library + type_translator.jl) but currently we also need the path to the corresponding polymake installation to run the json generator script. We also use the perl binary that corresponds to that polymake installation at the moment but maybe we don't really need that.

I thought about running the script via the shared library but we need to run that at precompilation before the library is really available. Maybe we could build a tiny script-runner executable linked against the same polymake (built together with libpolymake-julia) that we can use instead. Then we (hopefully) don't need any path apart from the prefix of libpolymake-julia.

@benlorenz
Copy link
Member Author

benlorenz commented Jul 7, 2020

Weird, it seems that github actions was faster than github ... the run https://github.com/oscar-system/Polymake.jl/actions/runs/160331645 should not have succeeded but it used an older commit instead of the one that it refers to ... there is an undefined variable polymake_run_script in Polymake.jl that will come from a newer libpolymake_julia binary.

edit: maybe this was something like this: actions/checkout#237

@benlorenz benlorenz marked this pull request as draft July 8, 2020 14:54
@benlorenz benlorenz changed the title WIP: split libpolymake_julia into separate repo split libpolymake_julia into separate repo Jul 8, 2020
@benlorenz benlorenz force-pushed the libpolymake_julia branch 2 times, most recently from c0a05b4 to d18d344 Compare July 9, 2020 22:06
@benlorenz
Copy link
Member Author

I was trying to remove the builds for different libstdc++ versions, but maybe this causes the segfaults of the script runner (luckily I get them on my laptop as well, but not every time). Especially since this doesn't happen on MacOS which uses libc++ instead.

@kalmarek
Copy link
Contributor

uuu, all green! :)

@benlorenz
Copy link
Member Author

I was slightly surprised myself, no errors, even without separate builds per gcc / libstdc++ version. The previous crashes were coming from a missing shell enable in the script runner.

There are still a few things that I want to do:

  • support custom path for libpolymake_julia, with the new script runner we just need this directory and no explicit path to perl or polymake.
  • we might need to store the libcxxwrap-julia version that was used at build-time (e.g. for the check at the end of src/setup_types.jl
  • we need some versioning and tests for libpolymake_julia, and then some version check
  • maybe more?

benlorenz referenced this pull request Aug 1, 2020
update many dependencies to jll based binaries, but using legacy installation as building the interface and wrappers wont work otherwise (at least for now)

flint_jll currently at 0.0.2 (which corresponds to pre 2.6) for
compatibility reasons
@kalmarek kalmarek merged commit 6f17c67 into master Aug 11, 2020
@benlorenz benlorenz deleted the libpolymake_julia branch August 12, 2020 07:37
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.

3 participants