This is a patch that fixes the build, I am not sure why -module is not used when HAVE_DARWIN_SYSTEM is defined, but I preserved that behavior. If its not intentional it could be added directly to libscute_la_LDFLAGS instead.

The built file is called scute instead of libscute because it is considered to be a *module*, not a *library*. That’s apparently a Debian thing, see commit dc2211179ea7f63434d726eefbc425390c4c6427.

As for why -module is not used when HAVE_DARWIN_SYSTEM is defined, it’s because on MacOS X the -module flag causes libtool to produce a .so file instead of a .dylib file (see T4703). I am not familiar enough with MacOS X to even know the difference between the two types of file, but Firefox on MacOS X would not load a .so file, only a .dylib file.

Regarding your patch, I am personally not opposed to it, but apparently Debian’s policy says the library/module should be called scute while Gentoo’s policy says it should be called libscute… What should an upstream developer do?

Regarding slibtool: I would actually like to have an easier to maintain tool than libtool (of which we use our own version) for GnuPG related software. However, its requirement "the compiler should support -std=c99" is currently a no-starter for libgcrypt and some other libs.

Regarding your patch, I am personally not opposed to it, but apparently Debian’s policy says the library/module should be called scute while Gentoo’s policy says it should be called libscute… What should an upstream developer do?

The canonical name for libraries is not gentoo policy so much as autotools documentation, but now that I looked it up again I found this.

Ordinarily, Automake requires that a library’s name start with lib. However, when building a dynamically loadable module you might wish to use a "nonstandard" name. Automake will not complain about such nonstandard names if it knows the library being built is a libtool module, i.e., if -module explicitly appears in the library’s _LDFLAGS variable (or in the common AM_LDFLAGS variable when no per-library _LDFLAGS variable is defined).

https://www.gnu.org/software/automake/manual/html_node/Libtool-Modules.html

Meaning that slibtool should consider also allowing this when -module is used and perhaps my patch is not required. I will bring this up with the slibtool maintainer and get back to you.

In T5394#145082, @werner wrote:

Regarding slibtool: I would actually like to have an easier to maintain tool than libtool (of which we use our own version) for GnuPG related software. However, its requirement "the compiler should support -std=c99" is currently a no-starter for libgcrypt and some other libs.

There are three parts to the question of supporting legacy or otherwise rarely used systems in slibtool, pertaining to the compiler features, host system interfaces (_XOPEN_SOURCE), and target-support logic (as implemented in slibtool). For the vast majority of legacy systems (which includes all systems that use '/' as a directory component separator and ':' as a path separator), porting of slibtool should be rather easy.

• compiling with -std=c89:
  • that's the easiest one, and can be done with the help of -Dinline=inline -Drestrict=

• compiling with _XOPEN_SOURCE=600 (as opposed to _XOPEN_SOURCE=700):
  • slibtool relies on the various ____at files-system interfaces to be available, but is otherwise rather spartan with respect to the interfaces that it requires. Even more so, missing interfaces could be easily provided by a downstream integrator via a libcompat.a of sorts. At the outset, a system running slibtool needs to provide _either_ posix_spawnp _or_ fork+execve, as well as the following interfaces:
    • _exit, calloc, chmodat, close, dup2, environ, faccessat, free, fstat, fstatat, getcwd, getenv, isatty, malloc, memcpy, mkdirat, mkstemp, mmap, munmap, openat, pipe, read, readlinkat, renameat, snprintf, sprintf, sscanf, strchr, strcmp, strcpy, strdup, strerror_r, strncat, strncmp, strrchr, strstr, symlinkat, unlinkat, vsnprintf, vsprintf, waitpid, and write.

• target support logic, as implemented in slibtool:
  • target characteristics are defined in a struct slbt_flavor_settings. In addition to the default (linux-style) flavor, slibtool currently has settings for midipix, mingw, cygwin, and darwin. Adding additional flavors should be extremely simple (most likely just a single constant array member), but I'll need someone who knows the target to provide the information and then verify that everything works as desired.
  • See also https://dev.midipix.org/cross/slibtool/blob/main/f/src/driver/slbt_driver_ctx.c#_46

I hope you find the above information helpful. Feel free to follow-up either here or on the #midipix freenode irc channel.

For what it's worth, scute is in violation of gnu libtool's documentation. Building with gnu libtool:

/bin/sh ../libtool  --tag=CC   --mode=link gcc  -Wall -Wno-pointer-sign -Wpointer-arith -g -O2   -o t-link t-link.o ../src/scute.la

*** Warning: Linking the executable t-link against the loadable module
*** scute.so is not portable!
libtool: link: gcc -Wall -Wno-pointer-sign -Wpointer-arith -g -O2 -o .libs/t-link t-link.o  ../src/.libs/scute.so -L/usr/lib64 -L/usr/local/lib64 -lassuan -lgpg-error

Ideally, this is something that should be addressed in scute in one of the following ways:

• if building scute.so as a loadable module is required, then the t-link test should dlopen scute.so in runtime rather than link against it in build-time.
• otherwise, change the link target name from scute.la to libscute.la and and remove the -module argument.

For enhanced compatibility with gnu libtool, I'll modify slibtool so that it correctly handles scute's non-portable usage as outlined above.

As of slibtool commit 9c5ba5eb, scute now builds out of the box. I'd still recommend taking the above into consideration, though.

• slibtool commit: https://git.foss21.org/slibtool/commit/?id=9c5ba5eba6c7c5274d7e9e6203ee5aad2fb438fb
• issue tracker: https://dev.midipix.org/cross/slibtool/issue/44

the t-link test should dlopen scute.so in runtime rather than link against it in build-time.

@werner What are your thoughts about that? I don’t believe it’s a big deal that the tests are non-portable, but I can work on that if you think it is worthwhile.

t-link does not do antthing useful, anyway. I don't think it is justified to add dlopen stuff. Running real test is anyway a manual action; for a full test automation we would need to emulate all supported cards.