1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL.MENTOR

  • Linker problem in safecat

    From Andreas Tille@21:1/5 to All on Thu Aug 22 22:20:01 2024
    Hi,

    I intended to fix bugs #1066354 and #836007 of safecat as Bug of the
    Day[1]. While #1066354 gcc-14 error seemed to be a low hanging fruit
    it turns out I need help to solve some linker issue[2]:

    ./load safecat getln.a str.a stralloc.a strerr.a substdio.a \
    alloc.o alloc_re.o byte_copy.o byte_cr.o envread.o error.o \
    error_str.o fmt_uint64.o hostname.o sig.o stat_dir.o str_diffn.o \
    str_len.o substdi.o substdio.o substdio_copy.o taia_fmtfrac.o \
    taia_now.o taia_tai.o tempfile.o writefile.o
    /usr/bin/ld: errno: TLS definition in /lib/x86_64-linux-gnu/libc.so.6 section .tbss mismatches non-TLS reference in strerr.a(strerr_sys.o)
    /usr/bin/ld: /lib/x86_64-linux-gnu/libc.so.6: error adding symbols: bad value collect2: error: ld returned 1 exit status
    make[1]: *** [Makefile:226: safecat] Error 1

    Its connected to the obscure, manually written build system of upstream.
    Any idea how to convince the linker to behave nicely? You can find the
    full build log in Salsa CI of safecat[2].

    Thanks a lot for any help
    Andreas.

    [1] https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks
    [2] https://salsa.debian.org/salvage-team/safecat/-/jobs/6164554

    --
    https://fam-tille.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Fri Aug 23 08:00:01 2024
    Hi Antonio,

    Am Thu, Aug 22, 2024 at 08:48:55PM -0600 schrieb Antonio Russo:
    I noticed the change of upstream to [1], but there's no import of any of
    the work done in there. It looks like @aperezdc has already gone about porting the package to meson, presumably solving this problem. Looking through the rest of the minimal work done on the package since the 1.13 import, there are a handful that make use of modern standard C libraries,
    a few that add or remove documentation, and two commits that might be controversial: 185e8bf and 6c14784.

    Thanks a lot for that hint.

    The first removes the maildir.sh script and a no-op warn-auto.sh file
    which seems to have only been used as part of its bespoke build system.
    The second changes the behavior if DTLINE and RPLINE are defined, which apparently has something to with qmail---I didn't bother to investigate. Maybe these commits can be safely reverted if we want that "old" behavior?

    Seems it took even over one of our Debian patches which I was able to
    remove.

    My point is that either the new upstream should be used, or we should
    admit that Debian is now acting as upstream of the package. Maybe it's
    worth it to just cherry pick the build system changes? It really seems unlikely it's worth someone's time it to maintain an abandoned, single-purpose
    build system designed in the late 20th century with ~1400 lines of code
    for a ~1800 LOC project!

    We will *definitely* not become upstream. I pointed the watch file to
    the latest Git commit and filed an ITS bug.

    (PS: Thank you so much for caring about these old packages. I'm sure someone's workflow depends on these, and they may not realize how
    precarious that is.)

    You are welcome and thanks a lot for your hint. I added the comment to
    the Bug of the Day matrix channel[2] that contacting debian-mentors@l.d.o
    helps over night. ;-)

    Kind regards
    Andreas.

    [1] https://github.com/aperezdc/safecat
    [2] https://matrix.to/#/#debian-tiny-tasks:matrix.org

    --
    https://fam-tille.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)