[[!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]].

    <pinotree> once libc is switched internally from cthreads to pthreads (thus
      breaking its BC), may be worth cleanup the hurd-specific exported symbols
    <tschwinge> 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.
    <pochu> 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

    <azeem> 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?
    <braunr> what do you mean ?
    <azeem> braunr: http://lwn.net/Articles/563285/
    <braunr> ok but what do you mean ?
    <braunr> i don't think there is anything special with the hurd about that
    <azeem> well, time_t is 64bit on amd64 AIUI
    <braunr> it's a signed long
    <azeem> so maybe the Hurd guys were clever from the start
    <azeem> k, k
    <braunr> our big advantage is that we can afford to break things a little
      without too much trouble
    <braunr> in a system at work, we use unsigned 32-bit words
    <braunr> which overflows in 2106
    <braunr> 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 :>
    <azeem> luckily, no nuclear reactors are running the Hurd sofar
    <braunr> i wonder how the problem will be dealt with though
    <braunr> ah, openbsd decided to break their abi
    <azeem> yeah
    <braunr> that's probably the simplest solution
    <azeem> "just recompile"
    <braunr> and they can afford it too
    <azeem> yeah
    <braunr> good to see people actually worry about it
    <azeem> I guess people are getting worried about where Linux embedded is
      being put into
    <braunr> they're right about that
    <azeem> "Please, don't fix the 2038 year issue. I also want to have some
      job security :)"
    <braunr> haha