WeasyPrint icon indicating copy to clipboard operation
WeasyPrint copied to clipboard

gobject-2.0.0 missing using nix on m2 MacOS

Open ranman166 opened this issue 1 year ago • 2 comments

I've looked through a lot of other issues with gobject-2.0.0. I think I'm missing just a small piece to resolve, and would appreciate any suggestions.

First of all, I'm using nix-shell with nix to create defined repeatable environments for my testing. Nix packages includes all the required packages, but may require distinct outputs like glib requires the dev flake, glib.dev

Here is my nix-shell file


{ pkgs ? import <nixpkgs> {} }:
pkgs.mkShell {
  buildInputs = [
    pkgs.python311
    pkgs.python311Packages.pip
    pkgs.glib.dev # contains gobject-2.0
    pkgs.glib 
    pkgs.libffi.dev  
    pkgs.libffi  
    pkgs.harfbuzz.dev
    pkgs.harfbuzz
    pkgs.fontconfig.dev
    pkgs.fontconfig
    pkgs.gobject-introspection
    pkgs.gobject-introspection.dev
    pkgs.pango 
    pkgs.pango.dev 
    pkgs.pango.out 
    pkgs.xmlsec
    pkgs.python3
    pkgs.python3Packages.virtualenv
    pkgs.pkg-config
    pkgs.libxml2.dev  
    pkgs.libxml2
    pkgs.libxslt.dev
    pkgs.zlib
    pkgs.darwin.libiconv
    pkgs.openssl
    pkgs.xcode-install
  ];

#gobject-2.0 shows up in pkg-config
#typefree 2 already included
#libprce is private

#cflags
#-I/nix/store/hynri3kb4kj5450yj75l0bi8h99igli6-glib-2.78.3-dev/include -I/nix/store/hynri3kb4kj5450yj75l0bi8h99igli6-glib-2.78.3-dev/include/glib-2.0 -I/nix/store/bb7k0a7rjlyrjzy175x620q9srlyjzj0-glib-2.78.3/lib/glib-2.0/include
#libs
#-L/nix/store/bb7k0a7rjlyrjzy175x620q9srlyjzj0-glib-2.78.3/lib -lgobject-2.0 -lglib-2.0

  shellHook = ''
    # Create a virtual environment and activate it
    virtualenv venv
    source venv/bin/activate

    pip install weasyprint==60.2
    weasyprint --version
  '';
}

With this i run nix-shell to start up the environment. I have it immediately bootup the virtual env and run weasyprint. I get the error listed below.

Here is the OSErrror OSError: cannot load library 'gobject-2.0-0': dlopen(gobject-2.0-0, 0x0002): tried: 'gobject-2.0-0' (no such file), '/System/Volumes/Preboot/Cryptexes/OSgobject-2.0-0' (no such file), '/usr/lib/gobject-2.0-0' (no such file, not in dyld cache), 'gobject-2.0-0' (no such file), '/usr/local/lib/gobject-2.0-0' (no such file), '/usr/lib/gobject-2.0-0' (no such file, not in dyld cache). Additionally, ctypes.util.find_library() did not manage to locate a library called 'gobject-2.0-0'

Listed in the comments above, I was able to confirm that with pkg-config that installing glib.dev provides gobject-2.0 pkg-config --print-requires gobject-2.0

I then listed the libs for gobject-2.0 using pkg-config --libs gobject-2.0 -L/nix/store/bb7k0a7rjlyrjzy175x620q9srlyjzj0-glib-2.78.3/lib -lgobject-2.0 -lglib-2.0

This indicated to me that for statically pkg-config was aware of gobject-2.0, but dynamically during runtime it is not looking in the right spot. The paths that are listed in the error obviously don't look close to the right location as they should be nix/store/blah similar to the libraries mentioned. One thought i had was the disparity between gobject-2.0-0 and gobject-2.0, but i checked the code here and it looks to check both patterns.

I want avoid using DYLD_LIBRARY_PATH to set the path as I don't think it will work with SIP, but I suppose i can try to see if that resolves the issue. The core issue does seem to be the path reference.

I am also using python 3.11.7 and weasyprint 60.2

I started to add a bunch of different packages trying to resolve the issue like gtk4, cairo, and so on, but I realized those were already included with the previous packages or not needed as gtk4 is for windows it seems.

I had a different nix-shell at some point and it provided ~closer~ errors that were using nix/store/random_hash references but still not referencing the values correctly. At some point I thought i had it working, but I think i may have mistakenly referenced the homebrew install i did when i was experimenting.

Sorry for being all over the place. I'm not too familiar with a lot of these packages or how the external packages operate, so I've been learning as I go. Feels like there is just piece of knowledge I am missing. If this is too nix specific, feel free to close.

ranman166 avatar Feb 15 '24 02:02 ranman166

Hi!

I don’t have a Mac at home to test and I don’t use nix, so it’ll be hard for me to help. 😄

To know if it’s related to WeasyPrint, you can try to launch this script (after installing the cffi Python package):

import cffi

ffi = cffi.FFI()
ffi.cdef('int pango_version (void);')
pango = ffi.dlopen('libpango-1.0.dylib')
# You can also try
# pango = ffi.dlopen('pango-1.0')
# pango = ffi.dlopen('pango-1.0-0')
# pango = ffi.dlopen('libpango-1.0-0')
print(pango.pango_version())

If the script does work, then we may be able to find a solution!

If it doesn’t work, then the problem is that Python can’t find Pango and other libraries. I don’t know how nix does to help other libraries find its libraries in /nix/, you’ll probably have to ask nix gurus for that answer!

I want avoid using DYLD_LIBRARY_PATH to set the path as I don't think it will work with SIP, but I suppose i can try to see if that resolves the issue. The core issue does seem to be the path reference.

Indeed.

liZe avatar Feb 17 '24 12:02 liZe

Thanks. I'll test this this and report back.

ranman166 avatar Feb 19 '24 16:02 ranman166

Don’t hesitate to add a comment if we can do anything for you.

liZe avatar Mar 04 '24 21:03 liZe

Thanks. Prioritizes have shuffled around, so I haven't had time for this yet. I'll post once i figure it out/need any more guidance.

ranman166 avatar Mar 04 '24 22:03 ranman166

@ranman166 Did you find a solution? I've run into the same problem.

hng avatar May 08 '24 12:05 hng

Hi @hng,

If you install WeasyPrint with Homebrew and use it with Homebrew’s Python, you shouldn’t have a problem. If you do, please open a separate issue!

liZe avatar May 08 '24 12:05 liZe

Hi @liZe, I know that I can get weasyprint to work in some way, e.g. with docker. But this issue is specific in using it with nix, which is quite common now for reproducible development environments e.g. with something like devbox which we use. So I thought this would be the right place to discuss this issue.

hng avatar May 08 '24 12:05 hng

@hng Could you please open a separate issue, with all the details of your system?

liZe avatar May 08 '24 14:05 liZe