Ubuntu
fpc package

glibc 2.32 breaks fpc (autopkgtest)

Bug #1896293 reported by Balint Reczey
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
fpc (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

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>

Revision history for this message
Balint Reczey (rbalint) wrote :

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

Revision history for this message
Steve Langasek (vorlon) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in fpc (Ubuntu):
status: New → Confirmed
Revision history for this message
Michael Van Canneyt (7-michael-z) wrote :

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 ?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.