[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] Things to consider regarding *versioning*. The provider and user of any interface need to agree about how to interpret the data being exchanged. Internal-only interfaces can be changed easily, because you can change the provider and user at the same time. Interfaces that are exposed externally require more attention, for obvious reasons. To *change* interfaces means to either remove, or add, or modify an existing interface. Modify basically means to remove and then re-add a variant, re-using the former name/identifier. [[!toc]] # [[RPC]]s ## [[microkernel/mach/message/msgh_id]] # Shared Libraries * [[!wikipedia soname]] * ELF symbol versioning * [[!wikipedia "GNU Libtool"]] ## Hurd Transition to "normal" ELF symbol versioning/libtool? For all libraries, the SONAME is currently set to *0.3*. [[!message-id desc="Not changed" "87ob7cxbu6.fsf@kepler.schwinge.homeip.net"]] when doing the [[Hurd 0.5 release|news/2013-09-27]]. ## glibc Bump the glibc SONAME to some point, or can do everything with symbol versioning? There are some comments in the sources, for example `hurd/geteuids.c`: `XXX Remove this alias when we bump the libc soname.` ### IRC, freenode, #hurd, 2012-12-14 [[!tag open_issue_glibc open_issue_libpthread]] In context of [[packaging_libpthread]]/[[libpthread]]. once libc is switched internally from cthreads to pthreads (thus breaking its BC), may be worth cleanup the hurd-specific exported symbols pinotree: Yes. If you already have ideas about what to clean up, feel free to add a new page or a section on open_issues/glibc. we're gonna break backwards compatibility in glibc on hurd? that could be the perfect moment to fix the /dev/fd/N problem without adding new RPCs, though we'd probably have to break backwards-compatibility in the exec server IIRC... [[glibc#execve_relative_paths]]. ### `time_t` -- Unix Epoch vs. 2038 #### IRC, freenode, #hurd, 2013-12-12 because it gets discussed in #debian-devel for the Linux i386 architecture right now: what's the deal with hurd-i386 and the 32bit epoch overflow in 2038? what do you mean ? braunr: http://lwn.net/Articles/563285/ ok but what do you mean ? i don't think there is anything special with the hurd about that well, time_t is 64bit on amd64 AIUI it's a signed long so maybe the Hurd guys were clever from the start k, k our big advantage is that we can afford to break things a little without too much trouble in a system at work, we use unsigned 32-bit words which overflows in 2106 and we already include funny comments that predict our successors, if any, will probably fail to deal with the problem until short before the overflow :> luckily, no nuclear reactors are running the Hurd sofar i wonder how the problem will be dealt with though ah, openbsd decided to break their abi yeah that's probably the simplest solution "just recompile" and they can afford it too yeah good to see people actually worry about it I guess people are getting worried about where Linux embedded is being put into they're right about that "Please, don't fix the 2038 year issue. I also want to have some job security :)" haha