Simon Josefsson wrote: > > * 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
Indeed. When I rebuild guile 3.0.10 with the 'ld' linker, $ nm -D libguile/.libs/libguile-3.0.so.1.7.0 | grep -v ' U ' | grep gdb shows empty output. This means, these gdb* symbols are already absent from libguile. Therefore it is useless to have them listed in the linker script. > 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). The situation I can think of is an API that is platform dependent. For instance, some symbols may have a '_64' variant on 32-bit platforms but no such variant on 64-bit platforms. But most packages that provide libraries have a platform independent set of exported symbols, and they can deal with them a. as you say, by filtering the list of symbols, or b. by passing -Wl,--undefined-version to the compiler. > 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. I agree. Let's go with this (simple) solution. > If there is a need to enforce a particular behaviour, couldn't that be > done in a separate module or code snippet? We can document how to deal with it, in doc/lib-symbol-visibility.texi. No need for supporting it directly in Gnulib, since we don't know of any package which will need this. Bruno
