Page MenuHome GnuPG

scute: Build failure with slibtool
Open, NormalPublic

Description

When building scute with slibtool (https://dev.midipix.org/cross/slibtool) it fails.

rdlibtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -Wall -Wno-pointer-sign -Wpointer-arith -O2 -pipe -march=native -fno-diagnostics-color -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -o t-link t-link.o ../src/scute.la

rdlibtool: lconf: {.name="libtool"}.
rdlibtool: fdcwd: {.fdcwd=AT_FDCWD, .realpath="/var/tmp/portage/app-crypt/scute-1.6.0/work/scute-1.6.0/tests"}.
rdlibtool: lconf: fstatat(AT_FDCWD,".",...) = 0 {.st_dev = 84, .st_ino = 765700}.
rdlibtool: lconf: openat(AT_FDCWD,"libtool",O_RDONLY,0) = -1 [ENOENT].
rdlibtool: lconf: openat(AT_FDCWD,"../",O_DIRECTORY,0) = 3.
rdlibtool: lconf: fstat(3,...) = 0 {.st_dev = 84, .st_ino = 765537}.
rdlibtool: lconf: openat(3,"libtool",O_RDONLY,0) = 4.
rdlibtool: lconf: found "/var/tmp/portage/app-crypt/scute-1.6.0/work/scute-1.6.0/libtool".
rdlibtool: link: x86_64-pc-linux-gnu-gcc t-link.o -Wall -Wno-pointer-sign -Wpointer-arith -O2 -pipe -march=native -fno-diagnostics-color -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -Wl,-rpath -Wl,/usr/lib64/pkcs11 -L../src/.libs -lte -L/usr/lib64 -lassuan -lgpg-error -o .libs/t-link
/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lte
collect2: error: ld returned 1 exit status
rdlibtool: exec error upon slbt_exec_link_create_executable(), line 1731: (see child process error messages).
rdlibtool: < returned to > slbt_exec_link(), line 2051.
make[2]: *** [Makefile:773: t-link] Error 2
make[2]: Leaving directory '/var/tmp/portage/app-crypt/scute-1.6.0/work/scute-1.6.0/tests'
make[1]: *** [Makefile:448: all-recursive] Error 1
make[1]: Leaving directory '/var/tmp/portage/app-crypt/scute-1.6.0/work/scute-1.6.0'
make: *** [Makefile:380: all] Error 2

This is because scute creates scute.la instead of the canonical library name libscute.la which is required with slibtool while GNU libtool is much more permissive and hides bugs. Unfortunately slibtool has a misleading error message that should probably be also fixed.

Please see this downstream issue: https://bugs.gentoo.org/782097

Details

External Link
https://bugs.gentoo.org/782097
Version
Commit: 49ad2b0e05e3fcb8c8c2e23bb1c6063b390dee02

Event Timeline

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.

werner triaged this task as Normal priority.Apr 13 2021, 8:13 AM
werner edited projects, added Feature Request, toolchain; removed patch, Bug Report.

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.

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.