glibc 2.32 breaks fpc (autopkgtest)

[Balint Reczey]

Some tests started failing with glibc 2.32:

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/f/fpc/20200917_160746_c05e1@/log.gz :
Difference between expected failures and current failures:
--- debian/tests/ref_fail_x86_64-linux 2020-08-20 20:30:47.000000000 +0000
+++ fpcsrc/tests/output/x86_64-linux/faillist 2020-09-17 16:07:31.315038977 +0000
@@ -1,32 +1,21 @@
...
+test/tlibrary2
...
+test/tweaklib2
...
+webtbs/tw12704b
+webtbs/tw16949b
...
+webtbs/tw3964b
...
+webtbs/tw8730c
+webtbs/tw9089c
+webtbs/tw9089d
...

I have not finished triaging them, first is:

root@autopkgtest-lxd-lxfrwn:/tmp/autopkgtest.D7JmBK/build.HJw/src/fpcsrc/tests/output/x86_64-linux/test/chunk000000011test# ./tlibrary2
./tlibrary2: symbol lookup error: ./tlibrary2: undefined symbol: calloc, version GLIBC_2.2.5
root@autopkgtest-lxd-lxfrwn:/tmp/autopkgtest.D7JmBK/build.HJw/src/fpcsrc/tests/output/x86_64-linux/test/chunk0000000

which seems to be a result of this glibc change:
commit 3a0ecccb599a6b1ad4b149dc569c0080e92d057b
Author: Florian Weimer <email address hidden>
Date: Sat Feb 8 19:58:43 2020 +0100

    ld.so: Do not export free/calloc/malloc/realloc functions [BZ #25486]

    Exporting functions and relying on symbol interposition from libc.so
    makes the choice of implementation dependent on DT_NEEDED order, which
    is not what some compiler drivers expect.

    This commit replaces one magic mechanism (symbol interposition) with
    another one (preprocessor-/compiler-based redirection). This makes
    the hand-over from the minimal malloc to the full malloc more
    explicit.

    Removing the ABI symbols is backwards-compatible because libc.so is
    always in scope, and the dynamic loader will find the malloc-related
    symbols there since commit f0b2132b35248c1f4a80f62a2c38cddcc802aa8c
    ("ld.so: Support moving versioned symbols between sonames
    [BZ #24741]").

    Reviewed-by: Carlos O'Donell <email address hidden>

[Balint Reczey (rbalint)]

I'm rebuilding the reverse build dependency chain in at test PPA to see if the breakage in fpc has any effect on them:
https://launchpad.net/~rbalint/+archive/ubuntu/scratch2/+packages

[Steve Langasek (vorlon)]

The rebuild test looks fine, the only failures are of ppc64el packages which are not built in groovy.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael Van Canneyt (7-michael-z)]

Any news on this ?

This effectively prevents the Free Pascal compiler from creating & loading pascal dynamic libraries.

The supposition that "libc is always in scope" is incorrect:

The Free Pascal compiler does not link to libc at all by default and produces binaries that make direct kernel calls. The users can of course opt to use libc by explicitly linking to it, but this is by no means a requirement, and it never has been.

Till this change, it was also possible to have a pascal program link in a pascal library (in which case neither has the calloc/malloc/free etc. symbols. With this change, the bug as reported here has effectively blocked us from creating dynamic libraries.

In absence of a solution in the dynamic linker, what are the possible solutions for the Free Pascal compiler to fix the possibility to create dynamic libraries that do not link to libc ?