1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Re: Does removal of global variables from a library break C ABI?

    From Russ Allbery@21:1/5 to Scott Talbert on Wed Jan 18 05:10:01 2023
    Scott Talbert <[email protected]> writes:

    In one of the library packages I maintain (hidapi), upstream removed a
    couple of global variables (my .symbols file noticed this). See
    abipkgdiff below.

    Does this break ABI? My assessment is that it does NOT, but I would
    like to confirm. These variables were not declared in a header file, so
    I can't see how external user code would have referenced them.

    It does technically, but if the variables were never declared in a header
    file, it's equivalent to hiding private functions that were previously
    exposed by mistake but never prototyped for users. Traditionally, we
    don't consider that an ABI break worth bumping the soname unless we have
    some reason to believe that software is using those symbols.

    --
    Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Talbert@21:1/5 to All on Wed Jan 18 04:50:01 2023
    In one of the library packages I maintain (hidapi), upstream removed a
    couple of global variables (my .symbols file noticed this). See
    abipkgdiff below.

    Does this break ABI? My assessment is that it does NOT, but I would like
    to confirm. These variables were not declared in a header file, so I
    can't see how external user code would have referenced them.

    Thanks,
    Scott

    ================ changes of 'libhidapi-hidraw.so.0.0.0'===============
    Functions changes summary: 0 Removed, 0 Changed, 0 Added function
    Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
    Function symbols changes summary: 0 Removed, 1 Added function symbol not referenced by debug info
    Variable symbols changes summary: 2 Removed, 0 Added variable symbols
    not referenced by debug info

    1 Added function symbol not referenced by debug info:

    [A] hid_get_device_info

    2 Removed variable symbols not referenced by debug info:

    [D] device_string_names
    [D] last_global_error_str

    ================ end of changes of 'libhidapi-hidraw.so.0.0.0'===============

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peter Pentchev@21:1/5 to Russ Allbery on Wed Jan 18 12:10:01 2023
    On Tue, Jan 17, 2023 at 08:03:18PM -0800, Russ Allbery wrote:
    Scott Talbert <[email protected]> writes:

    In one of the library packages I maintain (hidapi), upstream removed a couple of global variables (my .symbols file noticed this). See
    abipkgdiff below.

    Does this break ABI? My assessment is that it does NOT, but I would
    like to confirm. These variables were not declared in a header file, so
    I can't see how external user code would have referenced them.

    It does technically, but if the variables were never declared in a header file, it's equivalent to hiding private functions that were previously exposed by mistake but never prototyped for users. Traditionally, we
    don't consider that an ABI break worth bumping the soname unless we have
    some reason to believe that software is using those symbols.

    JFTR (I'm pretty sure that both Scott and Russ know this), https://sources.debian.org/ can help one figure out whether some other
    Debian package uses them.

    G'luck,
    Peter

    --
    Peter Pentchev [email protected] [email protected] [email protected]
    PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
    Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAmPH0gcACgkQZR7vsCUn 3xOzew/+MTrt5JWRdYzQngToIdOaNjJ4xNAC7SryF5B4BDPMfi6xCQPxhqxixwb4 7Rg7AsS0t3H3Sg+Almtvg+hqEeUklKEr9tDA7lsE9iDFZjH28dno1oECZkqy56ZR xdpQNO6EbrciTAW1oo1uUlcWQ1/RhCKQS/ManjQ6pCzntsctq23awyJUt4/Yp2sP r5ZQNgURWSEMn/8aEmenheCP7XnUTrK31ErN0ID7H6YiJE8q8P67QbXa6ItWPj0z kImlAT3BLCdIQ1ix7eT0UnLI5o/QqUaLAwUR1m2F6653E3Y7587fiMk40PylmG+E mVDOz0nc8CneyZO6WnvCBSzNf29v2kMDJh1U430hBxWb712REcFQBIZNozp8BMbi KDGn3n8mdk1s7BIjvEYXa6EhAKzcUx7lb9CzbhKPcMVCfGRrtuazuglMs8cpLY7m 5LIjB7V36Tp5sDSzkRjP11gqHQa/hIJIyr4fGmY4kOrEx82hpaPjERbYdkWBmJSD SEyFHeFXu88u7JRjXgk4B0pqyaeZFiDaQr0BK7z1G6/qZIzs95FXjj/r4YZbHWIK j3qVCUvtUihZ/dVVbIR+kzOV8bWR6eaHJWFWQ58p/1LY/kibrXk3xncSVINS2Tof VxgGoEC19k7RnY1KUiS29N6RtYa4mCptq2fG86+7ZCOjU8c4gzE=
    =eslU
    -
  • From Scott Talbert@21:1/5 to Peter Pentchev on Wed Jan 18 15:40:01 2023
    On Wed, 18 Jan 2023, Peter Pentchev wrote:

    On Tue, Jan 17, 2023 at 08:03:18PM -0800, Russ Allbery wrote:
    Scott Talbert <[email protected]> writes:

    In one of the library packages I maintain (hidapi), upstream removed a
    couple of global variables (my .symbols file noticed this). See
    abipkgdiff below.

    Does this break ABI? My assessment is that it does NOT, but I would
    like to confirm. These variables were not declared in a header file, so >>> I can't see how external user code would have referenced them.

    It does technically, but if the variables were never declared in a header
    file, it's equivalent to hiding private functions that were previously
    exposed by mistake but never prototyped for users. Traditionally, we
    don't consider that an ABI break worth bumping the soname unless we have
    some reason to believe that software is using those symbols.

    JFTR (I'm pretty sure that both Scott and Russ know this), https://sources.debian.org/ can help one figure out whether some other
    Debian package uses them.

    Thanks Russ and Peter. I didn't find any usage of these symbols, but I
    did sadly find a lot of bundled copies of this library in the archive. :(

    Scott

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to Scott Talbert on Thu Jan 19 02:50:01 2023
    On Wed, 2023-01-18 at 09:33 -0500, Scott Talbert wrote:

    Thanks Russ and Peter.  I didn't find any usage of these symbols, but I
    did sadly find a lot of bundled copies of this library in the archive.  :(

    It might be worth asking the upstreams to remove the copies and
    registering the existing copies with the Debian security team.

    https://wiki.debian.org/EmbeddedCopies

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmPIoRgACgkQMRa6Xp/6 aaM5Xg//YzueuUjunGNx/U29/jB+0CVK/ykXIPETncf80ARwGkfAJ7r2BBXwik4u 88QKL6YCRJW89aHoP0DM+UwCyxfos83qORsnYKnolhBksI90dO1JkRo6/2eVhqZ6 2VUMBJICGXzmTHBHwNX7Yt2dpg+7yoMomfkRGWNVYCoAzVKIgWgSTgGIMqGqsSmm ZvbjvLJcUIc5HmCvkdRuoyGmYHMrtOK88Gl4+wG84H5Qi5iE4Oms+tuZTjrDacms Q8qJ6QKFhNFqXNRPkKAaJmSU+cT1Hw29qQs9tOyuQU9YWKwPVLd8nC0R8pXNrapb x+uGvksFVeVUdgq+66waW47KLy2ZO+Cn99rsrfaEwrq47beCBacFzsVC6E7V0Uu5 iiV61azO5elpTRg3Tcz7wTZNWAywTmbW3QHTsxVnWXC/H5DrFxpn8P0t/SYJUK4b X5icwP7sCvmX9EAvH3pCsdnidLda0hcpKCcjWZE7JwFDUg4KOUUIlckspd8MScvP KP1Ci2ubAwy1WkFOq6K61JioYmxN5TeVD5K/LI5oKquNHjoYHdzGKgfROUWipXHB rDrtRHLYc1kvrlm6VBjOOl3E3ThGfwAFSeTJ8LWTNoPGSVWN3S6cZW+0t5gJE+aJ zNtBSNuLH9fbNh9niN2t5Syf01/ZAoR60QumKy+aUnO3Jm2UriU=
    =SK3f
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)