Bruno Haible via Gnulib discussion list <[email protected]> writes: > Simon Josefsson wrote: >> I think both 'yes' and 'no' is reasonable, and possibly even a third >> mode: it will depend on the linker. > > Looking at the packages that use this module: > - crypto modules of yours (libidn, libidn2, libtasn1, gnutls, gsasl, > shishi, OATH, gss), > - guile, > - libu2f-host, > > I attempted to build two of these packages with CFLAGS="-fuse-ld=lld -O2 -g" > and gl_cv_sys_ld_version_script=yes.
Wow, thank you for testing! > * guile 3.0.10 gets a build failure: > CCLD libguile-3.0.la > ld.lld: error: version script assignment of 'GUILE_2.0' to symbol > 'gdb_options' failed: symbol not defined Isn't that just a bug in guile? It looks like Andy forgot to remove those symbols from the map file when removing the implementation long time ago. https://codeberg.org/guile/guile/issues/58 Generally, is there any valid use to include non-existing symbols in a map file? I can think of some situations (e.g., optional symbols) but those are possible to solve in other ways (e.g., pre-processing the map file depending on iff the symbol is intended to be included or not). >> Maybe the simplest is to >> fix the ld-version-script.m4 test to actually define 'syms' so the test >> works better? > > That would break the guile configuration. So, it's not simple as that. guile > apparently needs '-Wl,--undefined-version' if gl_cv_sys_ld_version_script=yes. I think breaking guile here may not be a bad thing, it looks like this exposed a bug. I think it would be fine if ld-version-script had the behavior that undefined symbols trigger linker failures with lld>=16 but are ignored with other linkers. Is there even any way to get non-lld>=16 linkers to reject unknown symbols? If there is a need to enforce a particular behaviour, couldn't that be done in a separate module or code snippet? /Simon
signature.asc
Description: PGP signature
