Hi! 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? And then you manually test in-tree or copy the various .so files, etc.? > > > __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?) This change must be because I had Jérémie's hurd-dev 20110519-4~jk4 installed, which contains Emilio's exec server patch. 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. 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. > > > __vm_statistics@Base 2.11 > > > __vm_wire@Base 2.11 > > > __vm_write@Base 2.11 > > > - __xxx_cpu_control@Base 2.11 > > I guess this is also due to changes? Same answer: dropping symbols in a > lib is something of high importance that symbol lists help to catch. (Yes, I understand the importance.) This change is due to what I mean with ``it's your fault'' ;-) -- you did the commit: <http://anonscm.debian.org/gitweb/?p=pkg-hurd/gnumach.git;a=commit;h=dd48e23f43730038df4bb191e7acc47a4ab73c69>. (But I support that commit.) Perhaps you're still having an older gnumach-dev package installed on your hosts? (Again, ``RPC user stubs best effort'' issue...) > > 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? But I really hope (and expect) that nobody has been using these functions anymore (with their bogus names), for years already. Should we perhaps add something like ``ENOSYS'' stubs to Debian glibc, weak aliases for all the removed functions? Grüße, Thomas
Attachment:
pgpxUxiJxOVQz.pgp
Description: PGP signature