Open Neumann-A opened 2 years ago
Glib itself never had that issue. Does searching for a dependency('intl')
without hardcoding the method to cmake (????) work? That's what future versions of Glib will be doing...
Does searching for a dependency('intl') without hardcoding the method to cmake (????) work?
configure passes (used uppercase 'Intl') but building fails. I assume it has to due but it will take some time until I get the build log from https://dev.azure.com/vcpkg/public/_build/results?buildId=63612&view=logs&j=7b75bd19-17d3-53d4-00fd-23f1a49a8ba4&t=a23dba4e-3a62-59dc-a73c-a7222676d7a4
@eli-schwartz
the problem is that -lintl does not work. It needs to have an additional -L flag to find the library. With the cmake method the libraries are added with full paths.
All I see from those logs is:
Building package glib[core]:x64-osx...
-- Downloading https://ftp.gnome.org/pub/gnome/sources/glib/2.66/glib-2.66.4.tar.xz -> glib-2.66.4.tar.xz...
-- Extracting source /Users/vagrant/Data/downloads/glib-2.66.4.tar.xz
-- Applying patch use-libiconv-on-windows.patch
Command failed: /usr/local/bin/ninja install -v
Working Directory: /Users/vagrant/Data/buildtrees/glib/x64-osx-dbg
Error code: 1
See logs for more information:
/Users/vagrant/Data/buildtrees/glib/package-x64-osx-dbg-out.log
Call Stack (most recent call first):
scripts/cmake/vcpkg_install_meson.cmake:53 (vcpkg_execute_required_process)
ports/glib/portfile.cmake:54 (vcpkg_install_meson)
scripts/ports.cmake:142 (include)
Error: Building package glib:x64-osx failed with: BUILD_FAILED
Elapsed time for package glib:x64-osx: 1.123 min
Which is... notably lacking in details.
But, the intl dependency lookup internally uses cc.find_library('intl')
so I'm quite confused why that would fail. Where is the full path to the library in question?
All I see from those logs is:
you have to actually download the failure logs (artifact): (failure logs are located here: https://dev.azure.com/vcpkg/public/_build/results?buildId=63612&view=artifacts&pathAsName=false&type=publishedArtifacts only osx matters currently.)
[181/1153] cc -o glib/gtester glib/gtester.p/gtester.c.o -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-undefined,error -Wl,-framework,CoreFoundation -Wl,-framework,Carbon -Wl,-framework,Foundation -Wl,-framework,AppKit glib/libglib-2.0.a -lintl /Users/vagrant/Data/installed/x64-osx/debug/lib/pkgconfig/../../lib/libpcre.a -lintl -liconv -lm
FAILED: glib/gtester
cc -o glib/gtester glib/gtester.p/gtester.c.o -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-undefined,error -Wl,-framework,CoreFoundation -Wl,-framework,Carbon -Wl,-framework,Foundation -Wl,-framework,AppKit glib/libglib-2.0.a -lintl /Users/vagrant/Data/installed/x64-osx/debug/lib/pkgconfig/../../lib/libpcre.a -lintl -liconv -lm
ld: library not found for -lintl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[182/1153] /Library/Developer/CommandLineTools/usr/bin/cc -Iglib/tests/string.p -Iglib/tests -I../src/glib-2-4bd644fcb2.clean/glib/tests -I. -I../src/glib-2-4bd644fcb2.clean -Iglib -I../src/glib-2-4bd644fcb2.clean/glib -I/Users/vagrant/Data/installed/x64-osx/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu99 -O0 -g -D_GNU_SOURCE -fno-strict-aliasing -DG_ENABLE_DEBUG -Wimplicit-fallthrough -Wmisleading-indentation -Wstrict-prototypes -Wunused -Wno-unused-parameter -Wno-bad-function-cast -Wno-pedantic -Wno-format-zero-length -Werror=declaration-after-statement -Werror=format=2 -Werror=implicit-function-declaration -Werror=init-self -Werror=missing-include-dirs -Werror=missing-prototypes -Werror=pointer-arith -fPIC -g '-DG_LOG_DOMAIN="GLib"' -UG_DISABLE_ASSERT -MD -MQ glib/tests/string.p/string.c.o -MF glib/tests/string.p/string.c.o.d -o glib/tests/string.p/string.c.o -c ../src/glib-2-4bd644fcb2.clean/glib/tests/string.c
[183/1153] cc -o glib/tests/array-test glib/tests/array-test.p/array-test.c.o -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-undefined,error -Wl,-framework,CoreFoundation -Wl,-framework,Carbon -Wl,-framework,Foundation -Wl,-framework,AppKit glib/libglib-2.0.a -lm -lintl /Users/vagrant/Data/installed/x64-osx/debug/lib/pkgconfig/../../lib/libpcre.a -lintl -liconv
FAILED: glib/tests/array-test
cc -o glib/tests/array-test glib/tests/array-test.p/array-test.c.o -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-undefined,error -Wl,-framework,CoreFoundation -Wl,-framework,Carbon -Wl,-framework,Foundation -Wl,-framework,AppKit glib/libglib-2.0.a -lm -lintl /Users/vagrant/Data/installed/x64-osx/debug/lib/pkgconfig/../../lib/libpcre.a -lintl -liconv
ld: library not found for -lintl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
[184/1153] cc -o glib/tests/asyncqueue glib/tests/asyncqueue.p/asyncqueue.c.o -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-undefined,error -Wl,-framework,CoreFoundation -Wl,-framework,Carbon -Wl,-framework,Foundation -Wl,-framework,AppKit glib/libglib-2.0.a -lm -lintl /Users/vagrant/Data/installed/x64-osx/debug/lib/pkgconfig/../../lib/libpcre.a -lintl -liconv
FAILED: glib/tests/asyncqueue
cc -o glib/tests/asyncqueue glib/tests/asyncqueue.p/asyncqueue.c.o -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -Wl,-undefined,error -Wl,-framework,CoreFoundation -Wl,-framework,Carbon -Wl,-framework,Foundation -Wl,-framework,AppKit glib/libglib-2.0.a -lm -lintl /Users/vagrant/Data/installed/x64-osx/debug/lib/pkgconfig/../../lib/libpcre.a -lintl -liconv
ld: library not found for -lintl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Where is the full path to the library in question?
The full path is:
/Users/vagrant/Data/installed/x64-osx/debug/lib/libintl.a
/Users/vagrant/Data/installed/x64-osx/lib/libintl.a
depending on configuration (you can also download a file list from the same artifact store but it will only show relativ paths starting from /Users/vagrant/Data/installed/x64-osx/
. )
You also get the meson native files from the failure artifacts which contain:
c_link_args = ['-L/Users/vagrant/Data/installed/x64-osx/debug/lib']
cpp_link_args = ['-L/Users/vagrant/Data/installed/x64-osx/debug/lib']
So what confuses me here is that the find_library()
lookup tests linking to -lintl
:
This apparently succeeded "without any -L dirs" (even though it is using -L dirs from the native file???) and then those -L dirs did not get added to the linker command line? Not sure why manually specified flags are being dropped all over the floor, much less if they get used for find_library.
much less if they get used for find_library.
since the configure output is:
Checking for function "ngettext" : NO <---- seems to be `cc.has_function('ngettext')`
Library intl found: YES <---- assuming this is libintl = cc.find_library('intl', required : false)
Checking for function "ngettext" with dependency -lintl: NO
Library iconv found: YES <---- `cc.find_library('iconv', required : false)`
Library pthread found: YES <------ `cc.find_library('pthread', required : false)`
Checking for function "ngettext" with dependencies -lintl, -liconv: NO <----- `cc.has_function('ngettext', dependencies : [libintl, libintl_iconv]`
Checking for function "ngettext" with dependencies -lintl, -liconv, -lpthread: NO <----- `cc.has_function('ngettext', dependencies : [libintl, libintl_iconv, libintl_pthread])`
Run-time dependency intl found: YES <---- patched in libintl = dependency('Intl', required : true)
I assume the flags are used by find_library but somehow dropped by has_function. Or the dependency object does not carry the -L flags with it.
Ah dependencies and meson are so a mess if the library is not using pkgconfig. If meson would just provide some tool to externally provide such dependencies......
however glib setups the tests like this:
exe = executable(test_name, source,
c_args : test_cargs + extra_args.get('c_args', []),
link_args : extra_args.get('link_args', []),
dependencies : test_deps + extra_args.get('dependencies', []),
install_dir: installed_tests_execdir,
install: install,
)
maybe the link_args
parameter overrides the setting from the native file? (which it obviously shouldn't do. )
There are two things I don't get here, I wrote the super obvious patch to just add cmake support,
DependencyFactory(
[..., DependencyMethods.CMAKE],
cmake_name='Intl',
...
)
Which doesn't work for reasons that make no sense to me.
I think what's happening is that self.links
is inserting default search paths, though I don't really have time ATM to dig into it.
just for completion: the cc.has_functions
checks fail because the compilation is missing -framework Foundation -framework AppKit
macOS provides the *gettext family of functions in a framework?
macOS provides the *gettext family of functions in a framework?
no but you need extra flags if gettext was build statically. These flags are added in glib 2.70.1 so I am also updating glib in vcpkg to that version to get rid of these errors.
@dcbaker : I used your approach in vcpkg (https://github.com/microsoft/vcpkg/blob/84ad50049e04cddbd339e993cf4df76faa54d296/ports/vcpkg-tool-meson/meson-intl.patch) and it works. Be aware though that vcpkg has a wrapper for intl/iconv which fixes what cmake normally does (e.g. it always adds iconv to the linkage if it is not builtin).
Needing extra framework flags on macOS in order to link statically seems like a definite problem we can fix.
However I still don't understand what self.links
is doing!
somewhere between meson 58.2 and 60.1 the previously working:
dependency('Intl', method: 'cmake')
(now reports only builtin and system are supported.) was removed.vcpkg needed it because glib does not search correctly for libintl on osx and patching in the above line just fixed the linkage issue.