Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/usr.sbin/puffs/rump_smbfs



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


Home | Main Index | Thread Index | Old Index