• Re: Perl problem - loadable library and perl binaries are mismatched

    From Niko Tyni@21:1/5 to John Paul Adrian Glaubitz on Tue Mar 5 23:10:01 2024
    On Tue, Mar 05, 2024 at 09:17:17PM +0100, John Paul Adrian Glaubitz wrote:

    I am getting strange Perl error after rebuilding Perl for the time64_t transition on powerpc:

    loadable library and perl binaries are mismatched (got first handshake key 0xb600080, needed 0xb700080)

    See: https://buildd.debian.org/status/fetch.php?pkg=libdevice-usb-perl&arch=powerpc&ver=0.38-3&stamp=1709663348&raw=0

    I have already rebuilt Perl once again against the new time64_t libraries, but that didn't help although the package builds fine locally.

    Does anyone knowledgeable with Perl know what's going on?

    (You're in somewhat uncharted territory unfortunately, as none of this
    was tested beforehand.)

    Looks like it's built with dpkg-dev_1.22.4 but the time64 build flags are
    only activated with 1.22.5.

    I think there was talk about making them the default in gcc too, not
    sure if they got there yet.

    I suppose Perl could/should store them in its configuration so they'd be
    passed to all XS module builds regardless of what dpkg-buildflags says.
    But currently things from dpkg-buildflags get explicitly filtered away [1].

    IIRC the rationale for this was that packages could opt in/out of security hardening flags independently. That doesn't seem desirable here as they
    make the XS module ABI incompatible as you've noticed.

    [1] see https://sources.debian.org/src/perl/5.38.2-3.1/debian/rules/#L188
    I think -fstack-protector gets passed through there as an exception,
    so doing the same with the relevant time64 flags should do the trick.

    --
    Niko Tyni ntyni@debian.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Niko Tyni@21:1/5 to John Paul Adrian Glaubitz on Tue Mar 5 23:30:02 2024
    (Oops, forgot the Cc you asked for. So resending. Apologies for the
    duplicate on the list.)

    On Tue, Mar 05, 2024 at 09:17:17PM +0100, John Paul Adrian Glaubitz wrote:

    I am getting strange Perl error after rebuilding Perl for the time64_t transition on powerpc:

    loadable library and perl binaries are mismatched (got first handshake key 0xb600080, needed 0xb700080)

    See: https://buildd.debian.org/status/fetch.php?pkg=libdevice-usb-perl&arch=powerpc&ver=0.38-3&stamp=1709663348&raw=0

    I have already rebuilt Perl once again against the new time64_t libraries, but that didn't help although the package builds fine locally.

    Does anyone knowledgeable with Perl know what's going on?

    (You're in somewhat uncharted territory unfortunately, as none of this
    was tested beforehand.)

    Looks like it's built with dpkg-dev_1.22.4 but the time64 build flags are
    only activated with 1.22.5.

    I think there was talk about making them the default in gcc too, not
    sure if they got there yet.

    I suppose Perl could/should store them in its configuration so they'd be
    passed to all XS module builds regardless of what dpkg-buildflags says.
    But currently things from dpkg-buildflags get explicitly filtered away [1].

    IIRC the rationale for this was that packages could opt in/out of security hardening flags independently. That doesn't seem desirable here as they
    make the XS module ABI incompatible as you've noticed.

    [1] see https://sources.debian.org/src/perl/5.38.2-3.1/debian/rules/#L188
    I think -fstack-protector gets passed through there as an exception,
    so doing the same with the relevant time64 flags should do the trick.

    --
    Niko Tyni ntyni@debian.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gregor herrmann@21:1/5 to John Paul Adrian Glaubitz on Wed Mar 6 14:10:02 2024
    On Tue, 05 Mar 2024 23:55:28 +0100, John Paul Adrian Glaubitz wrote:

    Also, I noticed that libxs-parse-keyword-perl build-depends on libextutils-cbuilder-perl
    which is apparently obsolete and also still depends on the old Perl API [1] which makes
    me wonder how libxs-parse-keyword-perl was built for armhf and armel [2].

    Adrian

    [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060712
    [2] https://buildd.debian.org/status/package.php?p=libxs-parse-keyword-perl&suite=sid

    libextutils-cbuilder-perl is (not only a separate package but also)
    Provided by perl.

    Cheers,
    gregor

    --
    .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
    : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
    `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
    `-

    -----BEGIN PGP SIGNATURE-----

    iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmXoaYlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ qgYbxRAAlTFF0gus3RYHBDXmOwQnpHODr4otEY6kVcy8wcqW7wcWmunmHCPwNovR VVffs7GT1rJDZB5o1NVqpLtR3UaFE55hI/mxc74Bt6S9EOHkdEqwU0tP0kk8KPYO D8iy0edzmaP3JIGVclyPDZTsJCbYgFHXqAsCeSVvcb65OGhLgUZ6j8P5ZSVWOCcX hLEqMpageN9h/IZHdG3KqvsCs9fmpRxybJ17r8YFPR/0BxwzIYPsSBvGQC058tPm YE012t7RL98bpMWEre7yDAqGT/dmU6vcfcBl3iW/969Jxs5x5meGzMxNiK/B8Bs+ 7F0AWKvOa6zwJXSkRYi7+Y5kaPZ2OfYq2T4cMImxpswnB5Z9U10cOSKvw+xywGrO EES5XBolfpzG4xSMR8S7huGzo0FezWdP9aN5HRbBwGIobc2Ad3ZlmMl27yG72Afh 7QDe68+0PORl6yhaqvue0N1DF+TIFtBrVjH1FhSThneGUlfL+IcglptJ+NqFaJ2r FNc8zsEXmHYC/6J04GVjAwqPhTEA8HtMG9dTojd80hKmpI4m6ALFuF6bNPQjmcZz vAt4V4seZ2TbCG4ZpfIK1DxdYrjMloARRu8h0ZtKlBy0ynl6ikeL4rflSN//elHK LyYU3B8GaaL3YTnO4vAcOtkcbjSvhKAylRMetJD31MX/vlFf21k=
    =tnXw
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Langasek@21:1/5 to John Paul Adrian Glaubitz on Wed Mar 6 22:10:01 2024
    On Tue, Mar 05, 2024 at 11:55:28PM +0100, John Paul Adrian Glaubitz wrote:
    Thanks! You saved me a lot of headaches!

    FWIW to do a bootstrap build of perl I had to:

    - disable libdb and libgdbm build-deps
    - disable build-time tests, which would pick up old ndbm module from
    on-disk and break as a result

    Not sure if your bootstrap path was similar.

    I have run into this issue again trying to rebuild libxs-parse-keyword-perl with a src:perl that was built with dpkg_1.22.5:

    powerpc-linux-gnu-gcc -Isrc/ -I/usr/lib/powerpc-linux-gnu/perl/5.38/CORE -DVERSION="0.39" -DXS_VERSION="0.39" -fPIC -I. -Ihax -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe
    -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=. -fstack-
    protector-strong -Wformat -Werror=format-security -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=. -fstack-protector-strong -
    Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -o lib/XS/Parse/Keyword.o lib/XS/Parse/Keyword.c
    ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/XS/Parse/Keyword/Keyword.bs')
    powerpc-linux-gnu-gcc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/home/glaubitz/perl-modules/libxs-parse-keyword-perl-0.39=. -fstack-protector-strong -Wformat -Werror=format-
    security -Wl,-z,relro -Wl,-z,now -shared -L/usr/local/lib -fstack-protector-strong -o blib/arch/auto/XS/Parse/Keyword/Keyword.so lib/XS/Parse/Keyword.o src/infix.o src/keyword.o
    Parser.c: loadable library and perl binaries are mismatched (got first handshake key 0xb600080, needed 0xb700080)
    dh_auto_build: error: /usr/bin/perl Build returned exit code 1
    make: *** [debian/rules:6: binary-arch] Error 1
    dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit status 2

    I did not run into this. Do you have a mix of old and new packages from
    perl source installed?

    Also, I noticed that libxs-parse-keyword-perl build-depends on libextutils-cbuilder-perl which is apparently obsolete and also still
    depends on the old Perl API [1] which makes me wonder how libxs-parse-keyword-perl was built for armhf and armel [2].

    When modules are incorporated into perl, perl declares a provides: for them. There's no reason to install the libextutils-cbuilder-perl package anymore. (which, btw, was an arch: all package, so in any case it wouldn't be
    affected by the ABI transition.)

    --
    Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEErEg/aN5yj0PyIC/KVo0w8yGyEz0FAmXo2YgACgkQVo0w8yGy Ez2GThAAx2wUHWPXs4O5xYnxdU5tfeSVgBMYl6+Nx3gw/97i3Ct8RVjO0k9jmYxb OZyWdO/IjMg6QjMnfyxwyeG0WfTS1Q4V+LJKujxw2fOJmhzE3cQoBWGrEC9VoC1+ pjeWxu7UwSji8x4Q2rrf1i/L6Q4TmlbDIgMMC+nFBjVoJVzJhJQVzT9lkM+CijVw UhgYGyHXtVN7c8Jkq3vGDMgGZSiqyZVoIC/sv3lzeJ8zRfwadHxGQKxsxiIpQecZ iSEZF097EA6HiMJ3U/e0XIP5AXSVSJLB//xU8GCySMUMq8U3Eb4ipeHKa2j77hoA k+o9+wAou5a+pk0u4vQiBs6fZNYmsfC0c9G8MuF7A1tNUMPZ2hINTprXuLVKuGs7 35VoAySmjVZG0zjN1h1AWnV6Oy1wYBaEnDqDVQSCjOD+Dm7udPaTWB3ajwkxuFWA S19q1OJ3ju0nq2iapjyAMV+RLGuG8ZG5RK+0b2c1UTwbXrNmlQZZtor183e7cd5Z Fm7Jk6Ix12eDMPaa3sDhBJffGZhX1g2ibUTa0qM4vRJnMFQQ1MSCEfNY4hHnJAef hGg2KEu6dnmfpiTyvw2l