mesonbuild / wrapdb

New wrap requests
https://mesonbuild.com/Adding-new-projects-to-wrapdb.html
MIT License
77 stars 195 forks source link

libarchive-3.7.3: meson.build:452:8: Exception: Dependencies must be external dependencies #1511

Open kasper93 opened 4 months ago

kasper93 commented 4 months ago

This fails, because dependency is internal https://github.com/mesonbuild/wrapdb/blob/c3a8a5124fbdc4fc23d14d2540c4dd90b849bd0b/subprojects/packagefiles/libarchive/meson.build#L452 This will also fail https://github.com/mesonbuild/wrapdb/blob/c3a8a5124fbdc4fc23d14d2540c4dd90b849bd0b/subprojects/packagefiles/libarchive/meson.build#L564

Internal dependencies shouldn't be checked and assumed to be well formed, they will be built anyway.

benoit-pierre commented 4 months ago

AFAIK, cc.has_header(…) is fine, and cc.has_function(…) could be replaced with cc.has_symbol(…) (if a simple dependency version check cannot be used).

eli-schwartz commented 4 months ago

As a general comment on such checks: not all autoconf checks for symbols in a dependency are just checking if the dependency is functional. Sometimes they are checking which version of the dependency is available, because the symbol was introduced in XXX version.

In such a scenario, the symbol checks should of course be replaced by dep.version().version_compare()

neheb commented 4 months ago

As an aside, the GCC14 bump introduced implicit-function-declerations as an error. I was expecting this to make has_function() fail as headers are now needed. Looks like that didn't happen.

benoit-pierre commented 4 months ago

That's because the code run by those checks look like this:

#define locale_charset meson_disable_define_of_locale_charset

#include <limits.h>
#undef locale_charset

#ifdef __cplusplus
extern "C"
#endif
char locale_charset (void);

#if defined __stub_locale_charset || defined __stub___locale_charset
fail fail fail this function is not going to work
#endif

int main(void) {
  return locale_charset ();
}
eli-schwartz commented 4 months ago

Meson has never required headers for has_function to work because proper build systems intentionally smooth this over in order to guarantee compilers won't have an issue either way. You can specify which header is needed if you want though.

By proper build systems, I mean the ones that didn't have incredible issues during the porting work to make the OSS landscape work with GCC 14 / clang 16. Having build system checks return false information about the system and as a result make incorrect selections for system interfaces is... bad.