On Mon Sep 14 2009 at 12:04:18 +0100, Nick Hudson wrote: > > rump hasn't relied on linksets since August 2008 (and even then there was > > only a few day window of linkset use after introducing dynamic linking > > to rump). The only thing that matters is the entry point, which, > > incidentally, is what binutils 2.19 chaged. > > I believe you've analysed this completely incorrectly. afaict, librumnet has > always had unresolved references to {__start,__stop)_link_set_domains. The > change from binutils 2.16 to 2.19 is, I believe, that 2.19 is less forgiving > to this error.
>From NEWS in the ld distribution: === SNIP === Changes in version 2.6: * When an ELF section name is representable as a C identifier (this is not true of most ELF section names), the linker will automatically define symbols __start_SECNAME and __stop_SECNAME, where SECNAME is the section name, at the beginning and the end of the section. This is used by glibc. Addendum: Current versions of the linker (at least for version 2.18 onwards and possibly much earlier as well) place two restrictions on this feature: The symbols are only implemented for orphaned sections, not for explicitly placed sections and they are PROVIDEd rather than being defined. === SNIP === As you can easily check from even our cvs tree, "Addendum" was not present in binutils 2.16. The issue is not with unresolved symbols in libraries which are going to be linked (*sheesh*!). The problem is that the linker suddenly changed behaviour and no longer provided the symbols which used to satisfy those unresolved symbols. I have convinced the linker to once again provide those symbols hence fixing the build. (No, those symbols are not even used by rump. But what this build error told me is that __start_link_set_modules was no longer generated either and hence dlsym() for it does not work, and hence rump component dynamic loading would fail. That is why it is important to not just sweep stuff like this under the carpet.)