Re: Debian glibc symbol version stuff
Thomas Schwinge, le Tue 25 Oct 2011 00:31:43 +0200, a écrit :
> On Mon, 24 Oct 2011 23:44:27 +0200, Samuel Thibault <sthibault@debian.org> wrote:
> > Thomas Schwinge, le Fri 21 Oct 2011 10:27:03 +0200, a écrit :
> > > > > If building with EGLIBC_PASSES=libc (more specifically, without xen)
> > > >
> > > > I don't use EGLIBC_PASSES, but it shouldn't matter either.
> > >
> > > During development, you build all flavors all the time?
> >
> > No, I just run "make lib" in build/hurd-i386-libc/
>
> After first building it completely once, I guess?
Yes.
> And then you manually test in-tree or copy the various .so files,
> etc.?
I test in-tree.
> > > > __dir_unlink@Base 2.11
> > > > __exec_exec@Base 2.11
> > > > + __exec_exec_file_name@Base 2.13-21+ts.0
> >
> > Ah, do your changes add some RPCs? Then that part is expected. The
> > symbols stuff is precisely meant to catch such changes.
>
> (Does dh_makeshlibs run dpkg-gensymbols with -c2? Otherwise it wouldn't
> stop due to this, as I understand its documentation?)
I don't think it does.
> But, that's exactly what I meant with ``the RPC user stubs [in glibc]
> [...] are simply a best-effort thing'' -- their content isn't defined by
> the glibc source package that is being built, but instead by Hurd RPC
> definition files that are already installed.
Ah, yes.
> I don't really like
> libmachuser and libhurduser. All code using these should instead
> explicitly create these as needed and link against its own copies.
Well, that'd be a tedious thing to integrate in all applications which
we port to native interfaces of the Hurd.
> Perhaps you're still having an older gnumach-dev package installed on
> your hosts? (Again, ``RPC user stubs best effort'' issue...)
Most probably.
> > > Now, the question is whether the RPC user stubs should get Debian symbol
> > > versioning at all, or if they're simply a best-effort thing?
> >
> > Making them a best-effort would mean that some programs using them would
> > get broken when they are removed. We don't really want that :)
>
> Then we really have to revert dd48e23f43730038df4bb191e7acc47a4ab73c69?
Why?
> But I really hope (and expect) that nobody has been using these functions
> anymore (with their bogus names), for years already.
Then that's fine.
> Should we perhaps
> add something like ``ENOSYS'' stubs to Debian glibc, weak aliases for all
> the removed functions?
Debian is a binary distribution. We can check, but I doubt any Debian
binary package uses these symbols, so we can simply drop them entirely.
Samuel
Reply to: