GNOME Bugzilla – Bug 794292
glib-networking 2.56.0: does not build
Last modified: 2018-03-14 17:15:20 UTC
meson is invoked as: meson -Dpkcs11_support=false -Dca_certificates_path=/usr/local/etc/openssl/cert.pem .. and produces: The Meson build system Version: 0.45.0 Source dir: /Users/schoon/Library/Caches/Homebrew/glib-networking-2.56.0 Build dir: /Users/schoon/Library/Caches/Homebrew/glib-networking-2.56.0/build Build type: native build Project name: glib-networking Native C compiler: cc (clang 9.0.0 "Apple LLVM version 9.0.0 (clang-900.0.39.2)") Build machine cpu family: x86_64 Build machine cpu: x86_64 Found pkg-config: /usr/local/bin/pkg-config (0.29.2) Native dependency glib-2.0 found: YES 2.56.0 Native dependency gio-2.0 found: YES 2.56.0 Native dependency libproxy-1.0 found: YES 0.4.15 Native dependency gsettings-desktop-schemas found: YES 3.28.0 Native dependency gnutls found: YES 3.5.18 Message: location of system Certificate Authority list: /usr/local/etc/openssl/cert.pem Configuring config.h using configuration Configuring org.gtk.GLib.PACRunner.service using configuration Configuring glib-pacrunner.service using configuration Configuring libproxy.test using configuration Configuring gnome.test using configuration Configuring certificate.test using configuration Configuring file-database.test using configuration Configuring connection.test using configuration Configuring dtls-connection.test using configuration Program meson_post_install.py found: YES (/usr/bin/env python3 /Users/schoon/Library/Caches/Homebrew/glib-networking-2.56.0/meson_post_install.py) Message: libproxy support: true GNOME proxy support: true PKCS#11 support: false TLS CA file: /usr/local/etc/openssl/cert.pem Build targets in project: 13 Found ninja-1.8.2 at /usr/local/bin/ninja Running ninja produces the error: [22/34] Compiling C object 'tls/tests/file-database@exe/file-database.c.o'. FAILED: tls/tests/file-database@exe/file-database.c.o cc -Itls/tests/file-database@exe -Itls/tests -I../tls/tests -I. -I../ -I/usr/local/Cellar/glib/2.56.0/include/glib-2.0 -I/usr/local/Cellar/glib/2.56.0/lib/glib-2.0/include -I/usr/local/opt/gettext/include -I/usr/local/Cellar/pcre/8.41/include -I/usr/local/Cellar/gnutls/3.5.18/include -I/usr/local/Cellar/nettle/3.4/include -I/usr/local/Cellar/libtasn1/4.13/include -I/usr/local/Cellar/p11-kit/0.23.10/include/p11-kit-1 -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -std=c11 -O0 -g -DHAVE_CONFIG_H '-DG_LOG_DOMAIN="GLib-Net"' '-DLOCALE_DIR="/usr/local/Cellar/glib-networking/2.56.0/share/locale"' -DG_DISABLE_DEPRECATED -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_56 -D_REENTRANT '-DSRCDIR="/Users/schoon/Library/Caches/Homebrew/glib-networking-2.56.0/tls/tests"' '-DTOP_BUILDDIR="/Users/schoon/Library/Caches/Homebrew/glib-networking-2.56.0/build"' -MD -MQ 'tls/tests/file-database@exe/file-database.c.o' -MF 'tls/tests/file-database@exe/file-database.c.o.d' -o 'tls/tests/file-database@exe/file-database.c.o' -c ../tls/tests/file-database.c ../tls/tests/file-database.c:31:10: fatal error: 'gnutls/gtlscertificate-gnutls.h' file not found #include "gnutls/gtlscertificate-gnutls.h" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. I assume this can be fixed by adding an include?
Created attachment 369629 [details] [review] Fixes building glib-networking with pkcs11 support disabled
Review of attachment 369629 [details] [review]: Thanks for this patch. It looks right to me. I'm just going to adjust it a bit for code style before pushing.
Ok thanks for that. By the way, even after this, the plugins can be compiled by that cannot be used by glib/libsoup due to them having the .dylib suffix instead of .so... But that's a bug in meson, not glib-networking I guess.
(In reply to Tom Schoonjans from comment #3) > Ok thanks for that. > > By the way, even after this, the plugins can be compiled by that cannot be > used by glib/libsoup due to them having the .dylib suffix instead of .so... > But that's a bug in meson, not glib-networking I guess. Hmm, it sounds like meson's shared_module() function needs to produce a file with the .so suffix instead of .dylib, then? Is it a convention on macOS to only allow dlopening libraries with the .so extension (the place to report that would be https://github.com/mesonbuild/meson/issues), or do you think it is a bug in GIO that it does not try to open GIO modules with the .dylib extension? There's no point in having glib-networking installed if those modules are not loadable, btw, so you'll want to hack the filenames up as needed.
meson's shared_module function should give the option to specify the suffix at the very least. Problem is that the suffix has no real meaning as these plugins are loaded via their full file path, including whatever suffix they may have. Apple recommends .bundle I think but that is barely used. Glib's GModule doesn't take the full filename, just the name, and constructs the full name by appending .so on on Linux and macOS, and .dll on Win32. I assume .so was used because that's what libtool uses for plugins on Linux and macOS. For now I can probably just rename the plugins after they are produced by ninja, will try that tomorrow.
I can confirm that "ninja test" runs after renaming the plugin extensions to .so, with the exception of libproxy: 1/6 libproxy FAIL 0.04 s --- command --- G_TEST_SRCDIR='/Users/schoon/Library/Caches/Homebrew/glib-networking-2.56.0/proxy/tests' G_TEST_BUILDDIR='/Users/schoon/Library/Caches/Homebrew/glib-networking-2.56.0/build/proxy/tests' GIO_MODULE_DIR='/Users/schoon/Library/Caches/Homebrew/glib-networking-2.56.0/build/proxy/libproxy' /Users/schoon/Library/Caches/Homebrew/glib-networking-2.56.0/build/proxy/tests/libproxy --- stdout --- /proxy/libproxy/uri: --- stderr --- ** GLib-Net:ERROR:../proxy/tests/common.c:37:test_proxy_uri_common: assertion failed (proxies[0] == "http://proxy.example.com:8080"): ("direct://" == "http://proxy.example.com:8080") However, I guess this is not meson related...
(In reply to Tom Schoonjans from comment #6) > GLib-Net:ERROR:../proxy/tests/common.c:37:test_proxy_uri_common: assertion > failed (proxies[0] == "http://proxy.example.com:8080"): ("direct://" == > "http://proxy.example.com:8080") > > However, I guess this is not meson related... Looks like GLibProxyResolver is broken. (That might be the most confusingly-named object I've ever seen... I'm inclined to rename it from GLibProxyResolver to GLibproxyResolver. Capitalization makes a world of difference there.) (In reply to Tom Schoonjans from comment #5) > Apple recommends .bundle I think but that is barely used. Glib's GModule > doesn't take the full filename, just the name, and constructs the full name > by appending .so on on Linux and macOS, and .dll on Win32. I assume .so was > used because that's what libtool uses for plugins on Linux and macOS. Might be worth a separate GLib bug report, then, to consider changing GModule to look for the .dylib suffix as well. But maybe the developers will say that Meson should be changed instead of GModule. No strong opinion from me.
(In reply to Michael Catanzaro from comment #7) > (In reply to Tom Schoonjans from comment #5) > > Apple recommends .bundle I think but that is barely used. Glib's GModule > > doesn't take the full filename, just the name, and constructs the full name > > by appending .so on on Linux and macOS, and .dll on Win32. I assume .so was > > used because that's what libtool uses for plugins on Linux and macOS. > > Might be worth a separate GLib bug report, then, to consider changing > GModule to look for the .dylib suffix as well. But maybe the developers will > say that Meson should be changed instead of GModule. No strong opinion from > me. Bug #671212.
Which leads to https://github.com/mesonbuild/meson/issues/3053