libticables: usb_bulk_read (Unknown error) on FreeBSD 12.2-RELEASE amd64

[herrhotzenplotz]

After some discussions at nspire-emus/firebird#227 and some bug hunting I am (somewhat) surprised to see:

(tilp:92109): ticables-WARNING **: 16:58:22.966: usb_bulk_read (Unknown error).

whenever I try to interact with the TI nSpire CAS using TiLP.

For some details, see:
https://gist.githubusercontent.com/herrhotzenplotz/3ed5f0cb4df98f299feab8484c2d3972/raw/070f5d78fc5dda6156ef50799b684fff13d22837/gistfile1.txt

usbconfig dump at: https://gist.githubusercontent.com/herrhotzenplotz/3ed5f0cb4df98f299feab8484c2d3972/raw/070f5d78fc5dda6156ef50799b684fff13d22837/gistfile2.txt

I have no idea on how to debug this any further at the moment, so suggestions are very much appreciated.

[debrouxl]

Thanks for the detailed report.

Well, your logs show that libusb, libticables and libticalcs work well enough together to achieve a successful dirlist, which rules out multiple significant detection or communication issues. Therefore, I have no clear idea how to debug this further yet, either :)

What if you:

• comment out the call to the cable reset function at
  https://github.com/debrouxl/tilibs/blob/master/libticalcs/trunk/src/nsp_vpkt.cc#L199
  and initialize ret to 0 several lines above ?

and/or

• change https://github.com/debrouxl/tilibs/blob/master/libticables/trunk/src/linux/link_usb1.cc#L459 to #if !defined(__MACOSX__) || !defined(__BSD__) ?

EDIT: forgot to mention that the standard upstream build script is https://ti-pla.net/tilpinst , which redirects to a file from the tilp_and_gfm repo. It clones the repos to SRCDIR, defaulting to $HOME/lpg; you can modify the working copy and run make install as usual.

[herrhotzenplotz]

To follow up here: I've been going in circles trying to build all of this.
The ports version builds from tarballs off of sourceforge. I guess they are pretty much outdated. Therefore, what I suggest is that the issue lies within the communication with libusb.
Also, the above mentioned build script is not cross-platform and won't work by any chance on FreeBSD.

What I've so far is: try to build with autotools: libticables2, libtifiles2, libtifiles2
Issue is libticonv, which suffers from the usual iconv linker issues. I don't know autoconf that well in order to fix this. see: https://gist.githubusercontent.com/herrhotzenplotz/20b035aeaa18c41e2e56294bf8be11b1/raw/c370a9e460c0fbc607ac4c94f9659c24df082ff0/gistfile1.txt

Same goes for the CMake route, which fails even faster.

Also worth noting:

[nico@hades ~/src/tilibs/libticonv/trunk/src]$ pkg-config --modversion libusb-1.0
1.0.13
[nico@hades ~/src/tilibs/libticonv/trunk/src]$ pkg-config --modversion libusb-0.1
0.1.0
[nico@hades ~/src/tilibs/libticonv/trunk/src]$ pkg-config --modversion libusb-2.0
2.0.0
[nico@hades ~/src/tilibs/libticonv/trunk/src]$ 

which could be an actual issue bearing in mind that the ports Makefile straight-up seds the configure.ac to fix the minimum required version.
https://svnweb.freebsd.org/ports/head/comms/libticables2/Makefile?view=markup#l28

I will see what I can do and talk to a ports committer who might know all this weirdness.

[herrhotzenplotz]

Okay, correction: I've got it to build with autotools.

For those who have the same issue:

configure --without-iconv and make LDFLAGS=-liconv

[debrouxl]

The aforementioned build script is effectively cross-platform, as it works on both a wide range of Linux distros and MacOS X. If it doesn't work on FreeBSD, then it needs to be improved and fixed, and contributions to that effect are welcome :)

Adriweb has been making the runtime usage of iconv optional, because it's an issue on MacOS as well, but that commit remains on the experimental2 branch for now.

Due to the usage of libusb_strerror(), libticables now unconditionally depends on libusb >= 1.0.16, which is already a pretty old release. The workaround was removed during this development cycle.

[herrhotzenplotz]

After some hacking in libticables/trunk/configure.ac to make it pick up libusb 2.0 instead of anything else and configuring everything built and installed. Also, I changed the runpath to accomodate for the install prefix.

As I said above, it appears to be a version issue and the FreeBSD port is broken. Everything works just fine. I may go to the issue tracker for the FreeBSD ports and open another issue there.

Some logs:

[nico@hades ~/src/tilibs/libticables/trunk]$ git diff configure.ac
diff --git a/libticables/trunk/configure.ac b/libticables/trunk/configure.ac
index 0eee05dd..5754f9f2 100644
--- a/libticables/trunk/configure.ac
+++ b/libticables/trunk/configure.ac
@@ -85,9 +85,9 @@ AC_CACHE_CHECK([whether to enable USB through libusb 1.0.x],
 
 if [test "x$cab_cv_use_libusb" != xno]; then
   if [test "x$cab_cv_use_libusb10" != xno]; then
-    PKG_CHECK_MODULES([LIBUSB10], [ libusb-1.0 >= 1.0.0 ],
+    PKG_CHECK_MODULES([LIBUSB10], [ libusb-2.0 >= 2.0.0 ],
       [HAVE_LIBUSB10=yes
-       AC_CHECK_LIB([usb-1.0], [libusb_strerror],
+       AC_CHECK_LIB([usb], [libusb_strerror],
                     [AC_DEFINE([HAVE_LIBUSB10_STRERROR], [1], [libusb 1.0.x has libusb_strerror])],
                     [AC_ERROR([Use a version of libusb which provides libusb_strerror])])
       ])
[nico@hades ~/src/tilibs/libticables/trunk]$ autoreconf
[nico@hades ~/src/tilibs/libticables/trunk]$ cd ../build
[nico@hades ~/src/tilibs/libticables/build]$ ../trunk/configure --prefix=/opt/sn --enable-libusb10
[nico@hades ~/src/tilibs/libticables/build]$ make LDFLAGS='-liconv -Wl,-rpath=/opt/sn/lib'
[nico@hades ~/src/tilibs/libticables/build]$ su root -c "make install" 
[nico@hades ~/src/tilibs/libticables/build]$ 

I would suggest to add a special case for FreeBSD to check for libusb 2 and use that as it provides all the necessary functionality.

[adriweb]

In addition of the autotools build, If you can also check with CMake (the CMakeLists etc should work just fine) if it's better with different versions of the deps etc, thanks in advance :) (Maybe you'd have to be on the experimental2 branch for best results)

[debrouxl]

Definitely, some of your CMake changes are part of the master branch but the latest ones - including making the iconv runtime optional - aren't yet.

[herrhotzenplotz]

I am very much surprised by: https://gist.githubusercontent.com/herrhotzenplotz/43ff3fa2590c6bfc60126fc0cc3e6ac7/raw/be8d807bb3edcdc6c1154fd6b1f6fb02ab17be1c/gistfile1.txt

This is a no-go. A plain make should never install.

[debrouxl]

The autotools definitions do not install when just running make, but yup, it looks like the CMake definitions do, and I'd consider that a bug as well in this case.

[adriweb]

It was done on purpose actually because finding the built stuff is needed for the next steps (other libs needing each other as dependencies, and that's done via the pkg-config file). I'm no CMake expert so I'm assuming there's a proper/better way to do that. In the meantime, you can just configure the install directory to be wherever you want it to be (it's using the standard cmake variables). PRs welcome to improve this or at least the default behavior or path of installed if not specified.

[herrhotzenplotz]

On 1/1/21 9:53 PM, Adrien Bertrand wrote: It was done on purpose actually because finding the built stuff is needed for the next steps (other libs needing each other as dependencies). I'm no CMake expert so I'm assuming there's a proper/better way to do that.

That would require running the build step with root priviliges, which can, and in this particular case, would have been destructive because I haven't set a prefix. Thus: If the libraries depend on each other, they have to be built in seperate steps and installed in seperate steps. Otherwise one has to mess with the runpath to make the linking stage work. That is what I did in the autotools build. How to do that exactly in CMake is a different question and also why I did go with autotools in the first place.

…

-- Sent from Thunderbird@Hades / FreeBSD 12.2-RELEASE-p2 Please remember: https://useplaintext.email/#etiquette Do NOT send me Microsoft Office documents. I will and cannot open them.

[debrouxl]

The dependencies will soon get slightly more complex with the advent of tifileutil, which depends on libticonv and libtifiles, and will be a conditional dependency of libticalcs, to rebuild libticalcs' ROM dumpers if the corresponding switch is passed to libticalcs' configure (disabled by default). It currently lives on the experimental2 branch.

[adriweb]

It's certainly easy enough to *not* add a dependency on the install of libA to the build of libB. LibB just won't be able to be built until the user decided do build and install libA.