Fixing GCC/Homebrew building issues on macOS?

General Usage
1

Context: A lot of packages that have binary dependencies on macOS use Homebrew to install them. A few months ago there was some changes that caused Homebrew to build GCC from sources instead of just downloading it. Building GCC from scratch take hours (and all your CPUs) and since a lot of packages are affected by this it’s a serious issue (specially with 1.0 coming).

As I understand the Homebrew devs don’t have time to deal with this so we need to fix the issue ourselves and make a PR. I would give it a try but I don’t really understand what the issue is.

Does anybody here that is familliar with Homebrew can give us some hints, and hopefully we can fix this somehow ?

3 Likes
2

is this at all related to:

1 Like
3

Maybe I overestimate the issue, I don’t know if other packages beside hdf5 depends on gcc (I haven’t found a way to check this with homebrew).

If HDF5.jl is the only packages suffering from this a solution might be to switch to BinaryProvider.jl for distributing the binaries and avoid problem altogether.

4

Using BinaryBuilder/Provider would be a good solution but I’m not sure what to do with MPI. Do people generally need a HDF5 build that works with MPI or can the default be non-parallel? If people need an MPI linked HDF5 they might have HDF5 on their system already which BinaryProvider might be able to detect. Is that the case @staticfloat?

5

If people need an MPI linked HDF5 they might have HDF5 on their system already which BinaryProvider might be able to detect

Pretty sure that’s against the core philosophy of BinaryProvider + BinaryBuilder.

But there should be no problem in adapting the build script to do this.

Just have something like:

path = detect_system_hdf5()
if path != nothing && check_version(path) &&  check_mpi(path)
    write_deps(path)
    exit()
end

Maybe a write_deps(library_path) could be part of BinaryProvider, to make this a bit more smooth :wink:

6

I think having some standardized functionality for this would be useful. It doesn’t seem ideal that each package has custom code to handle these cases.

1 Like
7

Well, if we have the write_deps in BinaryProvider, that’s probably all we can ask for.
Base.Libdl.find_library is the closest a library can offer to help finding a system library, and check_version is highly library specific! :wink:

It could be bundled in one function, but I’m not sure how that should be integrated into BinaryProvider’s work flow.

8

Not sure it is related but installing Cairo and Makie is quite troublesome now on macOS.

9

I hope mostly Cairo? That’s kind of unrelated, but hopefully soon fixed in some way by https://github.com/JuliaGraphics/Cairo.jl/pull/229!

10

You are right. I cant get Cairo.jl to work on osx.

11

Cairo is being very awkward on both v0.6 and v0.7 at the moment. In https://github.com/JuliaGraphics/Cairo.jl/issues/230 you might find a temporary workround.