This can be closed; it was fixed in 3f802317.
Since no developer has responded to this bug report in nearly 2 years, I guess the gobject-introspection project is dead and will never work correctly on macOS?
glib's meson scripts search for dbus and, if found, build some additional tests that link with the dbus library. This can fail if dbus is installed but the library is not suitable for some reason. (For example, a user reported to MacPorts that glib failed to build when they were trying to build it universal (i.e. for both i386 and x86_64 architectures) but dbus happened to be installed but was not installed universal.)
To work around this problem, I've added a patch to MacPorts that disables the use of these dbus-based tests, but I would prefer not to have to carry this patch around in MacPorts forever. Would it be possible to add a meson option by which I could indicate my desire to have the dbus-based tests skipped?
You can see how things failed by examining the original user's report which is linked above.
Even if you check whether dbus works before using it, package management systems like MacPorts want to be able to inform the build what dependencies to use. We don't want external libraries/programs to be used opportunistically.
It works for me when shared libraries are disabled (
./configure --disable-shared
).
Right but as an extension to what I said above 2 years ago, the xslt-config
script's behavior should be consistent. When I ask for information about how to do static linking I should get it, whether libxslt was installed with only static libraries or both static and dynamic libraries. When I ask for information about how to do dynamic linking I should get it, whether libxslt was installed with only dynamic libraries or both static and dynamic libraries. And as I said libxml2 succeeds at offering this.
I'm thinking about changing the configuration process to only allow shared or static libraries, not both.
That would be nonstandard and not ideal. It is customary for autotools projects to offer both and to default to doing both. (For that reason, MacPorts installs both when possible, and users have been sad when they've requested that we do so in other ports and are unable to comply due to the limits of those other ports' build systems.) Could the way libxml2 does it be used here?
Thanks, however after this patch while the output of xslt-config --libs --dynamic
correctly lists only those libraries needed for dynamic linking, xslt-config --libs
is missing the information that would be required to link with a static library:
$ # actual
$ xslt-config --libs
-L/opt/local/lib -lxslt -lxml2
$ xslt-config --libs --dynamic
-L/opt/local/lib -lxslt -lxml2
What I expected to see was:
$ # expected
$ xslt-config --libs
-L/opt/local/lib -lxslt -lxml2 -licui18n -licuuc -licudata -lpthread -lz -llzma -liconv -lm
$ xslt-config --libs --dynamic
-L/opt/local/lib -lxslt -lxml2
Compare with what libxml2's config script does:
$ # actual
$ xml2-config --libs
-L/opt/local/lib -lxml2 -L/opt/local/lib -lz -L/opt/local/lib -llzma -lpthread -liconv -L/opt/local/lib -licui18n -licuuc -licudata -lm
$ xml2-config --libs --dynamic
-L/opt/local/lib -lxml2
Of course! That fixes it. Thank you.
Hello, I'm a developer with MacPorts trying to figure out why our glade port (version 3.38.2) no longer builds on any macOS version (we tried 10.6 through 12 inclusive). I backported 6da47128 (to fix build failure with latest meson) but it still fails the meson step, now saying:
help/meson.build:6:6: ERROR: Tried to create target "help-glade-da-update-po", but a target of that name already exists.
Hello, I'm a developer with MacPorts trying to figure out why our glade port (version 3.38.2) no longer builds on any macOS version (we tried 10.6 through 12 inclusive). I backported 6da47128 (to fix build failure with latest meson) but it still fails the meson step, now saying:
help/meson.build:6:6: ERROR: Tried to create target "help-glade-da-update-po", but a target of that name already exists.
I suppose this can be closed since glade no longer uses autotools (b9288f25).
I see that some automated builds failed, but looking at their logs I don't think they are related to my change.
gnome-keyring 3.36.0 doesn't build (on macOS 10.15.7 with Xcode 12.4):
pkcs11/xdg-store/mock-xdg-module.c:91:2: error: implicit declaration of function 'gettimeofday' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
gettimeofday (tv, NULL);
^
pkcs11/xdg-store/mock-xdg-module.c:95:6: error: implicit declaration of function 'utimes' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if (utimes (filename, tv) < 0)
^
pkcs11/xdg-store/mock-xdg-module.c:95:6: note: did you mean 'times'?
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/times.h:90:9: note: 'times' declared here
clock_t times(struct tms *);
^
2 errors generated.
This was reported to MacPorts here: https://trac.macports.org/ticket/64880
Although I realize newer versions of gnome-keyring are available and I have not tested them, this source code file doesn't look like it has been touched in 8 years so I don't believe you've fixed the problem yet. This PR fixes the problem for me on macOS.
It seems like there was just a typo where sys/times.h
should have been sys/time.h
so that's what I changed. It's possible that on systems other than mine something this file uses is actually declared in sys/times.h
and that both headers should be there.
Ryan Schmidt (d3a52240) at 24 Mar 02:47
Fix implicit declaration of utimes and gettimeofday.
If we find gi-docgen, we'll build the docs regardless of the gtk_doc option.
Really? As I say I'm not experienced with meson but in make-release.sh I saw:
# make the release tarball
meson setup -Dgtk_doc=true --force-fallback-for gi-docgen ${release_build_dir} || exit
meson compile -C${release_build_dir} || exit
meson dist -C${release_build_dir} --include-subprojects || exit
I assumed this would mean that the release tarball would already contain the documentation created by gi-docgen. And in meson.build I saw:
if get_option('gtk_doc')
subdir('docs')
endif
I assumed this would mean that if the "gtk_doc" option is false, as it is by default, then the docs directory would not be traversed into and processed.
Obviously I want to see the rest of the meson output. What I don't want to see is meson looking for something it doesn't need. I don't understand meson well enough to know why it's looking for something it won't use. I was hoping you might know why it's doing that and how to fix it so it doesn't do that.
When I run meson
to configure pango 1.50.3, the output contains these lines:
Run-time dependency gi-docgen found: NO (tried pkgconfig and framework)
Looking for a fallback subproject for the dependency gi-docgen
Executing subproject gi-docgen
gi-docgen| Project name: gi-docgen
gi-docgen| Project version: 2021.9
gi-docgen| Program python3 (jinja2, markdown, markupsafe, pygments, toml, typogrify) found: NO
gi-docgen| ../subprojects/gi-docgen/meson.build:10:0: Exception: python3 is missing modules: jinja2, markdown, markupsafe, pygments, toml, typogrify
Subproject subprojects/gi-docgen is buildable: NO (disabling)
Dependency gi-docgen from subproject gi-docgen found: NO (subproject failed to configure)
Subprojects
gi-docgen : NO python3 is missing modules: jinja2, markdown, markupsafe, pygments, toml, typogrify
I don't want to see any of this output. Is there any way to tell meson that I do not want it to look for gi-docgen
by any means? My understanding is that it is used to build documentation, and that if the meson "gtk_doc" option is false (which I believe by default it is, if I read meson_options.txt correctly) then it isn't used; therefore I wouldn't expect it to go looking for it and printing messages that give the erroneous impression that something important is missing.
This was reported to MacPorts here: https://trac.macports.org/ticket/64370
A user reported to MacPorts that pangox-compat 0.0.2 does not build, and the reason appears to be that it uses something that used to exist in pango 1.42.4 but no longer exists in pango 1.48.10 or 1.50.1:
pangox-fontmap.c:944:21: error: implicit declaration of function 'pango_config_key_get' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
char *files_str = pango_config_key_get ("PangoX/AliasFiles");
^
pangox.c:282:15: error: no member named 'find_shaper' in 'struct _PangoFontClass'
font_class->find_shaper = pango_x_font_find_shaper;
~~~~~~~~~~ ^
/opt/local/include/glib-2.0/glib/gmacros.h:990:38:: error: implicit declaration of function 'pango_font_metrics_new' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
metrics = pango_font_metrics_new ();
^
note: expanded from macro 'GLIB_DEPRECATED_MACRO_FOR'
#define GLIB_DEPRECATED_MACRO_FOR(f) _GLIB_GNUC_DO_PRAGMA(GCC warning #f)
^
pango 1.50.1 fails to build for me on macOS 10.15.7. Grepping my build log for "error:" I see:
../pango-1.50.1/pango/json/gtkjsonparser.c:1475:3: error: use of undeclared identifier 'errno'
../pango-1.50.1/pango/json/gtkjsonparser.c:1478:7: error: use of undeclared identifier 'errno'
../pango-1.50.1/pango/json/gtkjsonparser.c:1480:11: error: use of undeclared identifier 'errno'
../pango-1.50.1/pango/json/gtkjsonparser.c:1480:20: error: use of undeclared identifier 'ERANGE'
../pango-1.50.1/pango/json/gtkjsonparser.c:1483:62: error: use of undeclared identifier 'errno'
../pango-1.50.1/pango/json/gtkjsonparser.c:1509:3: error: use of undeclared identifier 'errno'
../pango-1.50.1/pango/json/gtkjsonparser.c:1517:7: error: use of undeclared identifier 'errno'
../pango-1.50.1/pango/json/gtkjsonparser.c:1519:11: error: use of undeclared identifier 'errno'
../pango-1.50.1/pango/json/gtkjsonparser.c:1519:20: error: use of undeclared identifier 'ERANGE'
../pango-1.50.1/pango/json/gtkjsonparser.c:1522:62: error: use of undeclared identifier 'errno'
../pango-1.50.1/pango/json/gtkjsonparser.c:1553:3: error: use of undeclared identifier 'errno'
../pango-1.50.1/pango/json/gtkjsonparser.c:1561:7: error: use of undeclared identifier 'errno'
../pango-1.50.1/pango/json/gtkjsonparser.c:1563:11: error: use of undeclared identifier 'errno'
../pango-1.50.1/pango/json/gtkjsonparser.c:1563:20: error: use of undeclared identifier 'ERANGE'
../pango-1.50.1/pango/json/gtkjsonparser.c:1566:62: error: use of undeclared identifier 'errno'
Adding #include <errno.h>
to that file fixes it.
As shipped, anjuta 3.34.0 and 3.28.0 come with configure scripts generated by autoconf 2.69 which works fine. But sometimes users have a need to patch the configure.ac file or regenerate the configure script for other reasons, and the build of either version fails on macOS if the configure script is regenerated with autoconf 2.71:
checking for library containing shm_open... no
configure: error: Failed to find library with shm_open()
config.log says:
configure:25424: checking for library containing shm_open
configure:25454: ccache /usr/bin/clang++ -o conftest -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64 -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64 conftest.cpp >&5
Undefined symbols for architecture x86_64:
"shm_open()", referenced from:
_main in conftest-fdd949.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure:25454: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "Anjuta"
| #define PACKAGE_TARNAME "anjuta"
| #define PACKAGE_VERSION "3.34.0"
| #define PACKAGE_STRING "Anjuta 3.34.0"
| #define PACKAGE_BUGREPORT "http://bugzilla.gnome.org/enter_bug.cgi?product=anjuta"
| #define PACKAGE_URL "http://www.anjuta.org/"
| #define ANJUTA_MAJOR_VERSION 3
| #define ANJUTA_MINOR_VERSION 34
| #define ANJUTA_MICRO_VERSION 0
| #define ANJUTA_VERSION 3.34.0
| #define PACKAGE "anjuta"
| #define VERSION "3.34.0"
| #define YYTEXT_POINTER 1
| #define PREF_SUFFIX ""
| #define HAVE_STDIO_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_UNISTD_H 1
| #define STDC_HEADERS 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define HAVE_VTE_2_91 1
| #define HAVE_WEBKIT2 1
| #define HAVE_RENDER 1
| #define HAVE_CFPREFERENCESCOPYAPPVALUE 1
| #define HAVE_CFLOCALECOPYCURRENT 1
| #define HAVE_ICONV 1
| #define ENABLE_NLS 1
| #define HAVE_GETTEXT 1
| #define HAVE_DCGETTEXT 1
| #define GETTEXT_PACKAGE "anjuta"
| #define YYENABLE_NLS 1
| #define HAVE_DIRENT_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_FNMATCH_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_TIME_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_SYS_DIR_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_SYS_TIMES_H 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_UTIL_H 1
| #define HAVE_FNMATCH 1
| #define HAVE_STRSTR 1
| #define HAVE_GETLINE 1
| #define HAVE_DECL_LOCKF 1
| #define HAVE_LOCKF 1
| #define HAVE_FGETPOS 1
| #define HAVE_MKSTEMP 1
| #define TMPDIR "/tmp"
| /* end confdefs.h. */
|
| /* Override any GCC internal prototype to avoid an error.
| Use char because int might match the return type of a GCC
| builtin and then its argument prototype would still apply. */
| char shm_open ();
| int
| main (void)
| {
| return shm_open ();
| ;
| return 0;
| }
configure:25454: ccache /usr/bin/clang++ -o conftest -pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64 -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64 conftest.cpp -lrt >&5
ld: library not found for -lrt
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The check for shm_open
was added in https://bugzilla.gnome.org/show_bug.cgi?id=704985. Presumably there was some behavior change in autoconf 2.70 or 2.71 that makes this fail where it used to work. The check is only needed for Linux, but is allowed to run on all operating systems, hence the problem now on macOS. Perhaps the simplest fix is to only run the test on Linux. If I remove that check, then build works fine.