Control: tags 1012825 -patch
Control: clone 1012789 -1
Control: reassign -1 libtk-img
Control: retitle -1 libtk-img: add _TIFFsetString to its internal tiff library
Control: tags -1 +patch
On Sat, Jun 25, 2022 at 5:07 PM Petter Reinholdtsen <p...@hungry.com> wrote:
> While it might sound sensible on the surface, the realities is that the
> libraries binary interface (aka ABI) changed, removing a public symbol
> from the library. Such API change require a no major SONAME number to
> avoid breaking programs using the library.
You are right that removing public symbols from a library interface
is an ABI break and requires a SONAME change. Per coding standards
function names starting with underscore are part of the private API
and a) not to be used outside of the library, b) if used nevertheless,
it's accepted that the other code can break anytime.
> It is not linuxcnc-uspace that is using it. It is the tcl/tk Img
> library. To test for yourself, try running 'wish' and give it the
> 'package require Img' command to load the Img library. linuxcnc do the
> equivalent loading, but using the python Tk library.
Yup, I was tricked by the bug reports. . In this case, the Python Tk
library must follow the internal change of tiff.
> Removing the symbol without bumping the SONAME made it impossible for
> programs using the symbol to keep the old working library version. This
> was the ratinale for my severity setting critical. Given that the
> symbol removal without bumping SONAME broken libtk-img and linuxcnc,
> what is your argument for lowering the severity to normal?
First of all, critical is used for several issues like making the
system unbootable or causing huge data loss. That's not the case. Then
as noted above, projects using others internal structures and/or
functions must follow that when the latter changes.
What you proposed is to diverge from tiff upstream and adding back the
mentioned function, then forcing a SONAME change, doing a transition
with over two hundred code rebuilds on fourteen architectures. This
makes no sense.
As noted above, the Python Tk library copies an internal tiff function
and probably not just one but a whole set of those (just check its
compat/libtiff/libtiff source directory). It must accept to follow
tiff development and act on such changes. Especially that the
mentioned removed function is a one liner, being a wrapper for another
function. If libtk-img needs that function, right. Copy it to their
code like it copied others already.
See the attached patch, basically it's a one liner. Sergei just needs
to add it to the libtk-img package source.
Regards,
Laszlo/GCS
Description: add _TIFFsetString function for being removed from tiff
The _TIFFsetString private function was internal of tiff and removed in
tiff 4.4.0+ versions. As Tk library used it in its source, copy the function
to its source.
Author: Laszlo Boszormenyi (GCS) <g...@debian.org>
Forwarded: no
Last-Update: 2022-06-25
---
--- libtk-img-1.4.13+dfsg.orig/compat/libtiff/libtiff/tif_unix.c
+++ libtk-img-1.4.13+dfsg/compat/libtiff/libtiff/tif_unix.c
@@ -352,6 +352,12 @@ _TIFFmemcmp(const void* p1, const void*
return (memcmp(p1, p2, (size_t) c));
}
+void
+_TIFFsetString(char** cpp, char* cp)
+{
+ _TIFFsetByteArray((void**) cpp, (void*) cp, strlen(cp)+1);
+}
+
static void
unixWarningHandler(const char* module, const char* fmt, va_list ap)
{
