Re: Help with attempt to update devel/gdb (currently in wip/gdb)

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Am Wed, 23 Apr 2025 00:00:14 +0200
schrieb Thomas Klausner <wiz%gatalith.at@localhost>:

> On Tue, Apr 22, 2025 at 11:58:17PM +0200, Dr. Thomas Orgis wrote:
> > libtool: link: unable to infer tagged configuration
> > libtool: link: specify a tag with `--tag'  
> 
> This error can often be fixed by rebuilding and reinstalling the
> libtool packages.
>  Thomas

Sadly, not in this case. This also is happening in my semi-pbulk-like
setup, where I build my pkgsrc stack from scratch. There are no updates
involved. I just reinstalled libtool in the tree, anyway. Doesn't
change anything. How does pkgsrc's libtool actually influence this build?


$ cd /path/to/workdir/devel/gdb/work/build/gdb
$ make V=1
rm -f gdb
/bin/bash ./libtool --mode=link g++  -march=native -O2 -fno-math-errno \
  -ftree-vectorize -I/usr/include […] -o gdb gdb.o […] \
  ../readline/readline/libreadline.a ../opcodes/libopcodes.la […] \
  -lncursesw -lm   -lpython3.12 -lintl -ldl -lm  \
  /pkgsrc-prefix/lib/libexpat.so -lm -Wl,-rpath -Wl,/pkgsrc-prefix/lib \
  ../gnulib/import/libgnu.a   -lmpfr -lgmp   -lpthread -lrt \
  -ldl -Wl,--dynamic-list=/path/to/workdir/devel/gdb/work/gdb-16.2/gdb/proc-service.list
libtool: link: unable to infer tagged configuration
libtool: link: specify a tag with `--tag'
make: *** [Makefile:2236: gdb] Error 1

Is the generated ./libtool influenced by the pkgsrc install?


Looking at the script …

#! /bin/bash

# libtool - Provide generalized library-building support services.
# Generated automatically by config.status (gdb) 
[…]

# The names of the tagged configurations supported by this script.
available_tags="CXX "

# ### BEGIN LIBTOOL CONFIG

# Which release of libtool.m4 was used?
macro_version=2.2.7a
macro_revision=1.3134


Pkgsrc installs libtool 2.4.7. Does that rule into the build somehow?
_should_ I try to re-libtoolize the thing?



Anyhow, this code fails to infer a tag:

# func_infer_tag arg
# Infer tagged configuration to use if any are available and
# if one wasn't chosen via the "--tag" command line option.
# Only attempt this if the compiler in the base compile
# command doesn't match the default compiler.
# arg is usually of the form 'gcc ...'
func_infer_tag ()
{
    $opt_debug
    if test -n "$available_tags" && test -z "$tagname"; then
      CC_quoted=
      for arg in $CC; do
        func_quote_for_eval "$arg"
        CC_quoted="$CC_quoted $func_quote_for_eval_result"
      done
      CC_expanded=`func_echo_all $CC`
      CC_quoted_expanded=`func_echo_all $CC_quoted`
      case $@ in
      # Blanks in the command may have been stripped by the calling shell,
      # but not from the CC environment variable when configure was run.
      " $CC "* | "$CC "* | " $CC_expanded "* | "$CC_expanded "* | \
      " $CC_quoted"* | "$CC_quoted "* | " $CC_quoted_expanded "* | "$CC_quoted_expanded "*) ;;
      # Blanks at the start of $base_compile will cause this to fail
      # if we don't check for them as well.
      *)
        for z in $available_tags; do
          if $GREP "^# ### BEGIN LIBTOOL TAG CONFIG: $z$" < "$progpath" > /dev/null; then
            # Evaluate the configuration.
            eval "`${SED} -n -e '/^# ### BEGIN LIBTOOL TAG CONFIG: '$z'$/,/^# ### END LIBTOOL TAG CONFIG: '$z'$/p' < $progpath`"
            CC_quoted=
            for arg in $CC; do
              # Double-quote args containing other shell metacharacters.
              func_quote_for_eval "$arg"
              CC_quoted="$CC_quoted $func_quote_for_eval_result"
            done
            CC_expanded=`func_echo_all $CC`
            CC_quoted_expanded=`func_echo_all $CC_quoted`
            case "$@ " in
            " $CC "* | "$CC "* | " $CC_expanded "* | "$CC_expanded "* | \
            " $CC_quoted"* | "$CC_quoted "* | " $CC_quoted_expanded "* | "$CC_quoted_expanded "*)
              # The compiler in the base compile command matches
              # the one in the tagged configuration.
              # Assume this is the tagged configuration we want.
              tagname=$z
              break
              ;;
            esac
          fi
        done
        # If $tagname still isn't set, then no tagged configuration
        # was found and let the user know that the "--tag" command
        # line option must be used.
        if test -z "$tagname"; then
          func_echo "unable to infer tagged configuration"
          func_fatal_error "specify a tag with \`--tag'"
#       else
#         func_verbose "using $tagname tagged configuration"
        fi
        ;;
      esac
    fi
}


So it's searching in the CXX tag definition for a compiler of the same name
as CC? It turns out empty for me.

# ### BEGIN LIBTOOL TAG CONFIG: CXX
[…]
# A language specific compiler.
CC=""

The working build with Ubuntu's system gcc has

CC="c++"

there. So the generation of that libtool script doesn't get my compiler
baked in. Just hacking the tag config is not enough, though, some other
variable settings seem to play a role  … Can this be a specific issue
with pkgsrc toolchain handling? Please note that I can build lots of
other packages just fine with my toolchain + pkgsrc setup. So it cannot
be something really basic being broken. Maybe gdb does funky things to
generate its libtool files that collide with my world when using a
provided toolchain not in /usr/?

Are/were there similar cases where only specific packages have broken
libtool in such a way?


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg