Skip to content
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.

Sign up for GitHub

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

Jump to bottom

dependency('Intl', method: 'cmake') has no method 'cmake' #9618

Open
Neumann-A opened this issue Nov 23, 2021 · 13 comments
Open

dependency('Intl', method: 'cmake') has no method 'cmake' #9618

Neumann-A opened this issue Nov 23, 2021 · 13 comments

Comments

@Neumann-A
Copy link
Contributor

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.
@Neumann-A Neumann-A mentioned this issue Nov 23, 2021
Merged
1 task
@eli-schwartz
Copy link
Member

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...

@Neumann-A
Copy link
Contributor Author

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

@Neumann-A
Copy link
Contributor Author

@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.

@eli-schwartz
Copy link
Member

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?

@Neumann-A
Copy link
Contributor Author

Neumann-A commented Nov 24, 2021 •
edited

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']

@eli-schwartz
Copy link
Member

So what confuses me here is that the find_library() lookup tests linking to -lintl:

meson/mesonbuild/compilers/mixins/clike.py

Lines 1057 to 1069 in bd9d981

# First try if we can just add the library as -l.
# Gcc + co seem to prefer builtin lib dirs to -L dirs.
# Only try to find std libs if no extra dirs specified.
# The built-in search procedure will always favour .so and then always
# search for .a. This is only allowed if libtype is LibType.PREFER_SHARED
if ((not extra_dirs and libtype is LibType.PREFER_SHARED) or
libname in self.internal_libs):
cargs = ['-l' + libname]
largs = self.get_linker_always_args() + self.get_allow_undefined_link_args()
extra_args = cargs + self.linker_to_compiler_args(largs)
if self.links(code, env, extra_args=extra_args, disable_cache=True)[0]:
return cargs

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.

@Neumann-A
Copy link
Contributor Author

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. )

@Neumann-A Neumann-A mentioned this issue Nov 24, 2021
Closed
@dcbaker
Copy link
Member

dcbaker commented Nov 24, 2021

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.

@Neumann-A
Copy link
Contributor Author

just for completion: the cc.has_functions checks fail because the compilation is missing -framework Foundation -framework AppKit

@eli-schwartz
Copy link
Member

macOS provides the *gettext family of functions in a framework?

@Neumann-A
Copy link
Contributor Author

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.

@Neumann-A
Copy link
Contributor Author

@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).

@eli-schwartz
Copy link
Member

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dcbaker @eli-schwartz @Neumann-A