Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation? I installed the package from respository with sudo apt-get install
   * What exactly did you do (or not do) that was effective (or
     ineffective)? Tried to understand from the error message if there was a missing package, but could not find one.
   * What was the outcome of this action? It did not help
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

Thanks for tryting LinuxCNC on aarch64. I don't know of anyone presently
using such a configuration.

As far as the "undefined symbol" message:

Please check whether in "wish", it works to "package require Img" or
whether the same error occurs. If it's the same error then may point to a
general problem between libtk-img and libtiff.

As far as the "LIBGL: Error while gathering supported extension
(eglInitialize: EGL_BAD_DISPLAY), default to none" message:

Most UIs for LinuxCNC require working OpenGL. You can try a different UI
such as tklinuxcnc, it doesn't use OpenGL and probably also doesn't use
Img. However, it's much less friendly (IMO)

Jeff

This looks to be a dependency (hard coded?) on the version of libtiff
that shipped with Buster (4.1).

But it also seems to be in a package that LinuxCNC depends on, but
doesn't control?
https://sourceforge.net/projects/tkimg/files/tkimg/1.4/tkimg%201.4.13/
(From the file path being searched)

For me, the trail dries up there. I guess this is due to a Tcl/Tk dependency?

Thank you for looking at this!

(My purpose reporting here is the understanding that we're trying to debug
to get sid into stable Bookworm with LinuxCNC, and I also want LinuxCNC
working on my little SBC.)

This is potentially helpful, but doesn't immediately clear things up for
me...

Here's what I did after getting this email:

I found the following libtiff packages on my SBC:
libtiff-dev  4.4.0-2
libtiff5 4.4.0-2
libtiffxx5  4.4.0-2

When I search the debian repository, it lists these as unstable (I presume
because we're on sid).
But it also lists them as the most recent releases, not the releases from
Buster (4.2.0-1).

Trying to follow the threads further, I went after the error message you
pointed out and saw it's trying to get:   libtifftcl4.1.0.so

I searched the debian repository and nothing by the name of libtiffcl4
exists:

"You have searched for packages that names contain libtifftcl in all
suites, all sections, and all architectures.
Sorry, your search gave no results"

Interestingly, the Sourceforge branches for tkImg does not have a *branch*
for 1.4 (which appears to be what the line above is looking for)
https://sourceforge.net/p/tkimg/code/HEAD/tree/branches/

But there *is* a version 1.4.13 under tags:
https://sourceforge.net/p/tkimg/code/HEAD/tree/tags/1.4.13/

I downloaded that 1.4.13 source and used MS Code to search the downloaded
source and found a piece of code compat/libtiff/libtiff/libtiff.map that
has the string " LIBTIFF_4.0" in it.

I found 8 files that have _TIFFsetString in it.

But I don't understand the compiling setup well enough to see how those
files get compiled to create an object named libtifftcl4.1.0.so  (??)

(there is no string in the source for libtifftcl4)

I'm happy to try and dig further, but I'm also at a stop point.

Vector Hasting

I started wish from the Terminal.
It brings up a % prompt and launches a small grey window
Typed linuxcnc  (inside the terminal, at the % prompt)
The initial configuration selection window opens, I chose the "axis_mm"
configuration and clicked OK.
It thinks for a while, and then sends the same error message ending in
"undefined symbol: _TIFFsetString, version LIBTIFF_4.0"

Thanks again for your time.



Vector Hasting

I started wish from the Terminal.
It brings up a % prompt and launches a small grey window
Typed linuxcnc  (inside the terminal, at the % prompt)
The initial configuration selection window opens, I chose the "axis_mm"
configuration and clicked OK.
It thinks for a while, and then sends the same error message ending in
"undefined symbol: _TIFFsetString, version LIBTIFF_4.0"

Thanks again for your time.

Vector Hasting

Thank you Jeff for suggesting this is an OpenGL issue.

Indeed, I went looking and I cannot run glxgears on my system, so I think
it would be fair to say that OpenGL is a dependency beyond the 'package
dependencies,' and that without it I can't run the plain vanilla, prettier
interface of LinuxCNC.

It was particularly helpful for you to mention tklinuxcnc, because I had no
idea it was there.

I followed the instructions at
http://linuxcnc.org/docs/2.7/html/gui/tklinuxcnc.html

(one finds the ini files, as of this writing, located at
~/linuxcnc/configs/sim.axis, and modifies/copies one to have a line DISPLAY
= tklinuxcnc  )

Therefore, by using the tklinuxcnc interface, my problem is solve: I have a
working copy of LinuxCNC!

This is as Jeff said an unusual attempt to get a Single Board Computer to
run LinuxCNC, but it may become a more common problem for folks
onceLinuxCNC becomes available in Debian Bookworm.

Therefore, a more fulsome message would probably reduce support work
downstream, but I'm not sure how to implement that myself. I'm happy to be
pointed in the right direction, either on this board or off.

Thanks again for everyone's help.

The same error is triggered from within Tcl/Tk. LinuxCNC I do not think
to be to blame.

$ wish
% package require Img
couldn't load file
"/usr/lib/tcltk/x86_64-linux-gnu/Img1.4.13/libtifftcl4.1.0.so":
/usr/lib/tcltk/x86_64-linux-gnu/Img1.4.13/libtifftcl4.1
.0.so: undefined symbol: _TIFFsetString, version LIBTIFF_4.0^

The problem is with the tiff library. On
https://github.com/LinuxCNC/linuxcnc/pull/1700 it is explained how to
install an earlier version from snapshot.debian.org

To trigger the problem independently from linuxcnc, try

$ wish
% package require Img

Control: block =1 by 1012825
Control: affects 1012825 - linuxcnc
Control: affects 1012825 + linuxcnc-uspace

The issue is reported against the tiff library as bug #1012825, and also
upstream as <URL: https://gitlab.com/libtiff/libtiff/-/issues/437 >.

Control: tags 1012825 patch
Control: severity 1012825 normal
Control: unblock 1012789 by 1012825
 As noted by libtiff upstream as well, this function was internal of
tiff and its declaration was in a header file that was not installed
publicly. They could change that without prior notice.
If linuxcnc-uspace still wants to use it, then copy that function[1]
and its details to their source tree. They already done copying with
the _TIFFsetString() function declaration.
Then I can add a break for its older versions for tiff.

Regards,
Laszlo/GCS
[1] https://gitlab.com/libtiff/libtiff/-/blob/master/libtiff/tif_dir.c#L43

[László Böszörményi]

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.

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.

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?

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
 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.
 Yup, I was tricked by the bug reports. . In this case, the Python Tk
library must follow the internal change of tiff.
 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

[László Böszörményi]

Which coding standards?  I believe the Debian policy require SONAME
changes when the ABI break.  Did I misunderstand?

I base my understanding on
<URL: https://www.debian.org/Bugs/Developer#severities >, which state
the following for critical:

  * critical - makes unrelated software on the system (or the whole
    system) break, or causes serious data loss, or introduces a security
    hole on systems where you install the package.

My observation is that the libtiff change 'made unreleated software on
the system break', making this a bug with severity 'critical'.

To me it is the only approach that make sense when the ABI is broken.

Note, I do not try to defend the libtk-img developers.  To me their
behaviour is beside the point, which is that the tiff ABI broke (a
public symbol was removed) and the SONAME as not bumped.

Upstream worked around this problem by dropping the use of libtk-img in
<URL: https://github.com/LinuxCNC/linuxcnc/commit/98a847899ee6bc59406bcee9fc79bac310e2bdd8 >.
Thus this will be fixed in the next upload from upstream master, or
Debian can fetch the patch.