-
Notifications
You must be signed in to change notification settings - Fork 57
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
Cannot build Cairo.jl on macOS Mojave #271
Comments
I am also getting this error, both locally and on Travis |
Me as well. |
I can now see this error on Travis, which looks to have been introduced since I last ran it (which was 5 days ago, Tuesday): https://travis-ci.org/JuliaGraphics/Luxor.jl/jobs/503554126 (Although Travis builds on the previous macOS release rather than the latest Mojave, I think.) It might be a fontconfig/pango problem? |
@cormullion It's obviously a homebrew/brew problem in the first place. Do you have a build log with homebrew version output available? |
Only the Travis logs I limked to... I've not had the problem locally (i've pinned a few things to avoid these productivity-ruining issues.. :). |
Get similar tasting error: Funny thing is, managed to build it on one computer, not on the other. Both are Mac Mojave, both times initially Queryverse needed Cairo. Below is the message I get from initial install of Queryverse. Any ideas where to go? Thanks ┌ Error: Error building |
I can see the same thing on a recent build in travis. My first (and only) guess is, something changed in brew, |
It's confusing me that Travis is running:
(which is High Sierra, not Mojave). |
Can this be reproduced using brew alone :
? |
I did /Users/sdanthine/.julia/packages/Homebrew/s09IX/deps/usr/bin/brew reinstall cairo then tried using Queryverse with error as below once more. Really puzzing to me.
|
And when I then try building Cairo from Julia: Pkg.build("Cairo"):
so seems like it can't find libsystem_platform.dylib |
So brew alone works, correct ? I'm just trying to understand if we should open an issue on homebrew-core or not. |
Yes brew alone works.
…On Thu, Mar 14, 2019 at 3:12 PM Jonathan Bieler ***@***.***> wrote:
So brew alone works, correct ? I'm just trying to understand if we should
open an issue on homebrew-core or not.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#271 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AVxxWURmvO-rIdkspmaMI7TXeZA4y7l4ks5vWljkgaJpZM4bl1bX>
.
|
Hello
|
What about : using Libdl
l = "/Users/sdanthine/.julia/packages/Homebrew/s09IX/deps/usr/Cellar/cairo/1.16.0/lib/libcairo.dylib"
h = Libdl.dlopen_e(l, Libdl.RTLD_LAZY) ? (the path might not be correct) That's how BinDeps tests that the libraries work, maybe it crashes at that point. |
Like such? Doesn't seem to work (but I might not have done it properly).... Thanks for your inputs!
` |
The fact that it returns a non-null pointer means the library exists (homebrew managed to install it) and Julia manages to open it. It maybe crashes when trying to do something with it. There's also other libraries in that folder. |
I tried to setup a package to test this (can't reproduce on my laptop): https://github.com/jonathanBieler/TestCairo.jl/blob/master/test/runtests.jl But that fails with a :
https://travis-ci.org/jonathanBieler/TestCairo.jl/jobs/508454006#L232 I'm pretty sure I've seen this error somewhere, any idea what the fix is ? |
No change for me, still the signal (11) segmentation fault : 11 when building Cairo |
i see test of travis ci failing with signal11. I think, that Makie isn't using Cairo.jl but an own cairo adaptation (excluding the features not needed). |
I'm still seeing this issue too: (v1.1) pkg> build Cairo
Building LibCURL ─→ `~/.julia/packages/LibCURL/khRkY/deps/build.log`
Building WinRPM ──→ `~/.julia/packages/WinRPM/Y9QdZ/deps/build.log`
Building Homebrew → `~/.julia/packages/Homebrew/s09IX/deps/build.log`
Building Cairo ───→ `~/.julia/packages/Cairo/CXPG1/deps/build.log`
┌ Error: Error building `Cairo`:
│
│ signal (11): Segmentation fault: 11
│ in expression starting at ~/.julia/packages/Cairo/CXPG1/deps/build.jl:165
│ _platform_strcmp at /usr/lib/system/libsystem_platform.dylib (unknown line)
│ Allocations: 19355595 (Pool: 19352771; Big: 2824); GC: 43
└ @ Pkg.Operations /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl:1075 |
I managed to get my test package going and I tested installing cairo and pango, opening each library and make some basic call in libcairo and libpango, everything works fine. https://github.com/jonathanBieler/TestCairo.jl/blob/master/test/runtests.jl I think that all what BinDeps does when installing Cairo, so I don't get what causes the crash. |
@jonathanBieler I ran your runtests.jl file, it didn't error. But then after |
Getting the same issue with my macOS Mojave 10.14.2 Seems this problem is specific to macOS system, everything goes fine on Windows 10 and Ubuntu 16 with same Julia and same installation sequence. |
Could someone try to add this to their Cairo/deps/build.jl (after using/import) and try to build again. It adds a bunch of print statements in BinDeps and should tells us which library crashes (assuming it crashes at this point): @eval BinDeps begin
function _find_library(dep::LibraryDependency; provider = Any)
println("test print")
ret = Any[]
# Same as find_library, but with extra check defined by dep
libnames = [dep.name;get(dep.properties,:aliases,String[])]
# Make sure we keep the defaults first, but also look in the other directories
providers = unique([reduce(vcat,[getallproviders(dep,p) for p in defaults]);dep.providers])
for (p,opts) in providers
(p !== nothing && can_use(typeof(p)) && can_provide(p,opts,dep)) || continue
paths = AbstractString[]
# Allow user to override installation path
if haskey(opts,:installed_libpath) && isdir(opts[:installed_libpath])
pushfirst!(paths,opts[:installed_libpath])
end
ppaths = libdir(p,dep)
append!(paths,isa(ppaths,Array) ? ppaths : [ppaths])
if haskey(opts,:unpacked_dir)
dir = opts[:unpacked_dir]
if dir == "." && isdir(joinpath(depsdir(dep), dep.name))
# the archive unpacks into the root, so we created a subdir with the dep name
push!(paths, joinpath(depsdir(dep), dep.name))
elseif isdir(joinpath(depsdir(dep),dir))
push!(paths,joinpath(depsdir(dep),dir))
end
end
# Windows, do you know what `lib` stands for???
if Compat.Sys.iswindows()
push!(paths,bindir(p,dep))
end
(isempty(paths) || all(map(isempty,paths))) && continue
for lib in libnames, path in paths
@info "testing $lib"
l = joinpath(path, lib)
@show h = Libdl.dlopen_e(l, Libdl.RTLD_LAZY)
if h != C_NULL
@info "validating $lib"
works = dep.libvalidate(l,h)
@info "done validating $lib"
l = Libdl.dlpath(h)
Libdl.dlclose(h)
if works
push!(ret, ((p, opts), l))
else
# We tried to load this providers' library, but it didn't satisfy
# the requirements, so tell it to force a rebuild since the requirements
# have most likely changed
opts[:force_rebuild] = true
end
end
@info "done testing $lib"
end
end
# Now check system libraries
for lib in libnames
# We don't want to use regular dlopen, because we want to get at
# system libraries even if one of our providers is higher in the
# DL_LOAD_PATH
for path in Libdl.DL_LOAD_PATH
for ext in EXTENSIONS
opath = string(joinpath(path,lib),ext)
check_path!(ret,dep,opath)
end
end
for ext in EXTENSIONS
opath = string(lib,ext)
check_path!(ret,dep,opath)
end
soname = lookup_soname(lib)
isempty(soname) || check_path!(ret, dep, soname)
end
return ret
end
end |
@jonathanBieler Thanks for this troubleshooting script! full output:
|
I am on High Sierra 10.13.6, get Building Cairo ───→ `~/.julia/packages/Cairo/p68X8/deps/build.log`
┌ Error: Error building `Cairo`:
│ WARNING: redefining constant DEBIAN_VERSION_REGEX
│ WARNING: redefining constant have_sonames
│ WARNING: redefining constant sonames
│ WARNING: redefining constant EXTENSIONS
│ Error: glib: undefined method `uses_from_macos' for Formulary::FormulaNamespace4eb6f3b02951643dc38adb936658d948::Glib:Class
│ Error: glib: undefined method `uses_from_macos' for Formulary::FormulaNamespace4eb6f3b02951643dc38adb936658d948::Glib:Class
│ Error: glib: undefined method `uses_from_macos' for Formulary::FormulaNamespace4eb6f3b02951643dc38adb936658d948::Glib:Class
│
│ signal (11): Segmentation fault: 11
│ in expression starting at /Users/abradley/.julia/packages/Cairo/p68X8/deps/build.jl:176
│ _platform_strcmp at /usr/lib/system/libsystem_platform.dylib (unknown line)
│ Allocations: 20112496 (Pool: 20109614; Big: 2882); GC: 44
└ @ Pkg.Operations /Users/osx/buildbot/slave/package_osx64/build/usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl:1075 with julia> versioninfo()
Julia Version 1.1.0
Commit 80516ca202 (2019-01-21 21:24 UTC)
Platform Info:
OS: macOS (x86_64-apple-darwin14.5.0)
CPU: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-6.0.1 (ORCJIT, skylake)
Environment:
JULIA_NUM_THREADS = 4 |
Has anybody been able to get over the libffi issue? |
I was able to. But it seems did not work for others.
On Thu, Jul 25, 2019 at 3:01 PM Maria Isabel Restrepo < ***@***.***> wrote:
Has anybody been able to get over the libffi issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#271?email_source=notifications&email_token=ABK7C6BW5N4CWKGAJJDRCA3QBIIDDA5CNFSM4G4XK3L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD22YOUA#issuecomment-515213136>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABK7C6FVL7FZVCPBINV36K3QBIIDDANCNFSM4G4XK3LQ>
.
--
-monty
monty.gitlab.io
|
About the problem of segfault:
Notice Homebrew used the Why does it fail when called from inside Julia? 🤔 The log (~/.julia/packages/Cairo/p68X8/deps/build.log) contains the exact same error message, nothing more to learn from there. The error:
seems to be from this code:
Not sure how to proceed from here, does anyone know how to call these BinDeps installs manually in order to see which one is failing, and maybe get a better error message? |
Just checking- is there even an older version of this that can build successfully on mac for julia v1.1+ ? Or has it been broken for newest mac OS? |
There's been a lot of recent discussion of TTFP as a Julia problem, but I'd like to remind some of the folks worried about such things that TTFP is also a Cairo.jl and Gtk.jl problem because of this issue. Currently, the TTFP is infinite for some people using certain applications, and that's much worse than waiting a few minutes. Would love it if there were some effort to get BinaryBuilder working for both Cairo.jl & Gtk.jl, then we could move past this. Otherwise we'll just have to abandon Cairo/Gtk. |
Yikes. That's a "goodbye Julia" scenario (for me)... |
Definitely don't want that! By "we" I meant "my group and my applications": ImageView, ProfileView, and my lab's entire GUI toolkit. But really, it's not OK for this to drag out for months while also complaining that other hard problems aren't getting enough attention. |
Oh, OK :) I thought you might be speaking on behalf of Julia in general. But isn't this mainly a macOS problem - Cairo seems to still run on Linux/Travis and Windows/Travis (the two most popular OSs according to Viral's 2019 survey)? Or is it a deeper problem? |
Sorry for the confusion. I can't really do that 😄.
I think that's right. And I don't personally use macOS, and AFAICT neither do the primary maintainers of this package and Gtk.jl. However, it's a serious problem to have a package that doesn't work for one of the most popular platforms. I've spent an awful lot of time fixing problems that only show up on platforms I don't use. (Most recent example dating from approximately 2min ago: timholy/Revise.jl#336 😄.) The purpose of this message is to point out that those who are expressing concerns about a different problem (TTFP) might instead consider investing some time fixing this one. There is an obvious if difficult path: get BinaryBuilder working all the way through Gtk.jl. Then we don't rely on Homebrew anymore, and IIUC the differences between platforms are almost eliminated. |
Ideally one would use native libraries, especially for creating anything that has any actual interface components instead of just displaying an image. Gtk interfaces are… clunky… compared to Mac native ones. Also see JuliaGraphics/Gtk.jl#437 and JuliaImages/ImageView.jl#178 for serious problems with trying to use Gtk —which wants to take complete control of everything—from Julia. I think the real solution is to have an "interface/graphics server" running in a different system thread that the backend library has full control of. A simple protocol for accessing that server (I don't think we need full-fledged GUI libraries) which can then be implemented using native libraries. Or use Qt, which is much better at integrating with the native GUI framework than Gtk (which along with everything Gnome-related, I'd personally not touch with a long stick; they destroyed Linux for me, creeping into everything, hiding the unix under layers of something undescribable). |
@timholy I'm a mac user, I've tried a couple times to use BinaryBuilder but never managed to do anything with it. Last time I got stuck on this issue, so there's not much I can do to help. |
Note that I've just updated CairoBuilder to latest BinaryBuilder version: JuliaGraphics/CairoBuilder#5. I'm also working on building Pango (see JuliaGraphics/CairoBuilder#5) but it'll take time (and some changes to BinaryBuilder itself, too) |
I think I've gone through all the threads I could find about the topic but still can't get Cairo.jl to work on my Mac Mojave system.. So far I've tried:
if I try to build Cairo now I get this
I feel like I'm going in circles here, there are several threads about interrelated problems and too many workarounds to try that I don't know what the order of steps is I need to take. I don't understand why installing cairo through homebrew works, but then building Cairo.jl doesn't. What is there left to build after brew has done its job? If someone on Mojave has managed to get their system to work, could they be so kind to post a short sequence of steps going from a clean julia environment? |
If you can please wait just a few days more, we're trying to deliver an hopefully working solution for everyone 🙂 |
Of course, thank you for putting in the effort to fix this! You're talking about your previous post using CairoBuilder? Once it's done I'll be glad to test it on my system and report back |
Yes, I'm talking about that. There is actually a preview in #289, if you're able to test that branch on macOS it would be awesome. For the time being Travis tells us that Cairo basic features are working, Pango is disabled on that branch but there is the possibility that it's working for macOS (I can't check right now) |
I had to rebuild Cairo on a new machine. The step I proposed before fixed it again:
|
Folks, I think you may want to check out #292 🙂. |
Hi guys!
I am trying to build Cairo.jl on macOS Mojave (clean Julia installation) and I am getting the following error:
Trying to build manually Cairo leads to:
The text was updated successfully, but these errors were encountered: