• Bug#1059223: Workaround for rustc toolchain bug

    From Mate Kukri@21:1/5 to All on Tue Feb 13 15:40:01 2024
    Hello,

    We have a similar issue in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/2049904

    To me this seems like a rust linking issue, the same C library
    compiled with cc, then linked against a C stub program links just fine
    for me.

    In comparison rustc tries to be annoyingly clever and calls `cc` to
    link with `-nodefaultlibs` and tries to manually provide all the
    required libraries, which makes it fail.

    The direct cause of the error is a library ordering issue, `-lc`
    should always come after all C static libs and object files in a link
    command, but it does not.

    It seems that meson doesn't pass `-Clink-arg=-lc` to `rustc` at all by
    default (which it probably shouldn't need to), and it's rustc itself
    that emits `-lc` at the wrong location.

    A workaround is as follows:
    ```
    dep_libc = declare_dependency(link_args : '-lc')

    l = static_library(
    'c_accessing_zlib',
    'c_accessing_zlib.c',
    dependencies: [dep_zlib, dep_libc],
    )
    ```

    It is rather unweildly to read, but here's an example of an offending
    link invocation by rustc:
    ```
    LC_ALL="C" PATH="/usr/lib/rustlib/aarch64-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
    VSLANG="1033" "cc" "/tmp/rustcqxuAcC/symbols.o" "prog.p/prog.prog.3a9e8efe5d7989d1-cgu.0.rcgu.o" "prog.p/prog.2valzr4aprd78wdd.rcgu.o" "-Wl,--as-needed" "-L" "." "-L" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-3f505df5bf7b6973.rlib" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libpanic_unwind-f7bbfb2a4f0106ba.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libobject-799d4aa6228550fd.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libmemchr-817c1781430e6007.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libaddr2line-ad8936af23d8ece8.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgimli-fa9ccab1157705c6.rlib" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_demangle-0f0344f8af442a24.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd_detect-f1d03073262366fd.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libhashbrown-d2b728fe429f73fd.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-78f4eeade0e7b3f3.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libminiz_oxide-386abc7d4431b549.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libadler-f2fbe97df215d47a.rlib" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libunwind-1b9c021e2652ca95.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcfg_if-a31e7b8703ef1917.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-67315dfc1c311b62.rlib" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/liballoc-6f13ad92e9ef28f1.rlib" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_core-4647df6db5bfc191.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcore-7ca28360f44e13c1.rlib" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcompiler_builtins-bda26fded9d4fbc7.rlib"
    "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl"
    "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-o" "prog" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "libc_accessing_zlib.a" "-lz"
    ```

    Which was produced by the following rustc invocation:
    ```
    rustc -C linker=cc --color=always -C debug-assertions=yes -C
    overflow-checks=no --crate-type bin -g --crate-name prog --emit
    dep-info=prog.d --emit link=prog --out-dir prog.p -C metadata=prog@exe -Clink-arg=libc_accessing_zlib.a -Clink-arg=-lz -L. ../prog.rs
    ```

    As a note, same issue repros on the latest nightly rustc also.

    Fixing rustc instead of meson is the real solution, but I don't think
    this should be holding up meson migrating, as such I am attaching a
    workaround patch similar to the one I have proposed for Ubuntu.

    Mate Kukri

    ZGlmZiAtTnJ1IG1lc29uLTEuMy4xL2RlYmlhbi9jaGFuZ2Vsb2cgbWVzb24tMS4zLjEvZGViaWFu L2NoYW5nZWxvZwotLS0gbWVzb24tMS4zLjEvZGViaWFuL2NoYW5nZWxvZwkyMDIzLTEyLTI2IDE3 OjMxOjAxLjAwMDAwMDAwMCArMDAwMAorKysgbWVzb24tMS4zLjEvZGViaWFuL2NoYW5nZWxvZwky MDI0LTAyLTEzIDE0OjMyOjEwLjAwMDAwMDAwMCArMDAwMApAQCAtMSwzICsxLDExIEBACittZXNv biAoMS4zLjEtMS4xKSB1bnN0YWJsZTsgdXJnZW5jeT1tZWRpdW0KKworICAqIE5vbi1tYWludGFp bmVyIHVwbG9hZC4KKyAgKiBkL3AvbHAyMDQ5OTA0LXdvcmthcm91bmQucGF0Y2g6IEFkZCB3b3Jr YXJvdW5kIGZvciBydXN0YyBlbWl0dGluZyBsaW5rCisgICAgZmxhZ3MgaW4gdGhlIHdyb25nIG9y ZGVyIChMUDogIzIwNDk5MDQpICgjMTA1OTIyMykKKworIC0tIE1hdGUgS3VrcmkgPG1hdGUua3Vr cmlAY2Fub25pY2FsLmNvbT4gIFR1ZSwgMTMgRmViIDIwMjQgMTQ6MzI6MTAgKzAwMDAKKwogbWVz b24gKDEuMy4xLTEpIHVuc3RhYmxlOyB1cmdlbmN5PW1lZGl1bQogCiAgICogTmV3IHVwc3RyZWFt IHJlbGVhc2UuCmRpZmYgLU5ydSBtZXNvbi0xLjMuMS9kZWJpYW4vY29udHJvbCBtZXNvbi0xLjMu MS9kZWJpYW4vY29udHJvbAotLS0gbWVzb24tMS4zLjEvZGViaWFuL2NvbnRyb2wJMjAyMy0xMi0x MSAxOTo1MjowNS4wMDAwMDAwMDAgKzAwMDAKKysrIG1lc29uLTEuMy4xL2RlYmlhbi9jb250cm9s CTIwMjQtMDItMTMgMTM6MjM6MzMuMDAwMDAwMDAwICswMDAwCkBAIC0xLDUgKzEsNiBAQAogU291 cmNlOiBtZXNvbgotTWFpbnRhaW5lcjogSnVzc2kgUGFra2FuZW4gPGpwYWtrYW5lQGdtYWlsLmNv bT4KK01haW50YWluZXI6IFVidW50dSBEZXZlbG9wZXJzIDx1YnVudHUtZGV2ZWwtZGlzY3Vzc0Bs aXN0cy51YnVudHUuY29tPgorWFNCQy1PcmlnaW5hbC1NYWludGFpbmVyOiBKdXNzaSBQYWtrYW5l biA8anBha2thbmVAZ21haWwuY29tPgogU2VjdGlvbjogZGV2ZWwKIFByaW9yaXR5OiBvcHRpb25h bAogU3RhbmRhcmRzLVZlcnNpb246IDQuNi4yCmRpZmYgLU5ydSBtZXNvbi0xLjMuMS9kZWJpYW4v cGF0Y2hlcy9scDIwNDk5MDQtd29ya2Fyb3VuZC5wYXRjaCBtZXNvbi0xLjMuMS9kZWJpYW4vcGF0 Y2hlcy9scDIwNDk5MDQtd29ya2Fyb3VuZC5wYXRjaAotLS0gbWVzb24tMS4zLjEvZGViaWFuL3Bh dGNoZXMvbHAyMDQ5OTA0LXdvcmthcm91bmQucGF0Y2gJMTk3MC0wMS0wMSAwMTowMDowMC4wMDAw MDAwMDAgKzAxMDAKKysrIG1lc29uLTEuMy4xL2RlYmlhbi9wYXRjaGVzL2xwMjA0OTkwNC13b3Jr YXJvdW5kLnBhdGNoCTIwMjQtMDItMTMgMTM6MjM6MzMuMDAwMDAwMDAwICswMDAwCkBAIC0wLDAg KzEsMjggQEAKK0Rlc2NyaXB0aW9uOiBXb3JrYXJvdW5kIGZvciBMUDogIzIwNDk5MDQgYXV0b3Br Z3Rlc3QgZmFpbHVyZQorICBJbiBgdGVzdCBjYXNlcy9ydXN0LzEzIGV4dGVybmFsIGMgZGVwZW5k ZW5jaWVzL21lc29uLmJ1aWxkYCBtYXJrIGxpYnoKKyAgYXMgZXhwbGljdGx5IGRlcGVuZGVudCBv biBsaWJjLiAoV2hpY2ggaXMgdHJ1ZSBidXQgcHJvYmFibHkgc2hvdWxkbid0IGJlCisgIG5lY2Vz c2FyeSkuCitBdXRob3I6IE1hdGUgS3VrcmkgPG1hdGUua3VrcmlAY2Fub25pY2FsLmNvbT4KK0J1 Zy1VYnVudHU6IGh0dHBzOi8vYnVncy5sYXVuY2hwYWQubmV0L3VidW50dS8rc291cmNlL3J1c3Rj LytidWcvMjA0OTkwNAorRm9yd2FyZGVkOiBubworTGFzdC1VcGRhdGU6IDIwMjQtMDItMTMKKy0t LQorVGhpcyBwYXRjaCBoZWFkZXIgZm9sbG93cyBERVAtMzogaHR0cDovL2RlcC5kZWJpYW4ubmV0 L2RlcHMvZGVwMy8KK0luZGV4OiBtZXNvbi0xLjMuMS90ZXN0IGNhc2VzL3J1c3QvMTMgZXh0ZXJu YWwgYyBkZXBlbmRlbmNpZXMvbWVzb24uYnVpbGQKKz09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KKy0tLSBtZXNvbi0xLjMu MS5vcmlnL3Rlc3QgY2FzZXMvcnVzdC8xMyBleHRlcm5hbCBjIGRlcGVuZGVuY2llcy9tZXNvbi5i dWlsZAkKKysrKyBtZXNvbi0xLjMuMS90ZXN0IGNhc2VzL3J1c3QvMTMgZXh0ZXJuYWwgYyBkZXBl bmRlbmNpZXMvbWVzb24uYnVpbGQKK0BAIC05LDEwICs5LDEyIEBAIGlmIG5vdCBkZXBfemxpYi5m b3VuZCgpCisgICBlcnJvcignTUVTT05fU0tJUF9URVNUOiBDb3VsZCBub3QgZmluZCBhIEAwQCB6 bGliJy5mb3JtYXQoZ2V0X29wdGlvbignc3RhdGljJykgPyAnc3RhdGljJyA6ICdzaGFyZWQnKSkK KyBlbmRpZgorIAorK2RlcF9saWJjID0gZGVjbGFyZV9kZXBlbmRlbmN5KGxpbmtfYXJncyA6ICct bGMnKQorKworIGwgPSBzdGF0aWNfbGlicmFyeSgKKyAgICdjX2FjY2Vzc2luZ196bGliJywKKyAg ICdjX2FjY2Vzc2luZ196bGliLmMnLAorLSAgZGVwZW5kZW5jaWVzOiBbZGVwX3psaWJdLAorKyAg ZGVwZW5kZW5jaWVzOiBbZGVwX3psaWIsIGRlcF9saWJjXSwKKyApCisgCisgZSA9IGV4ZWN1dGFi bGUoCmRpZmYgLU5ydSBtZXNvbi0xLjMuMS9kZWJpYW4vcGF0Y2hlcy9zZXJpZXMgbWVzb24tMS4z LjEvZGViaWFuL3BhdGNoZXMvc2VyaWVzCi0tLSBtZXNvbi0xLjMuMS9kZWJpYW4vcGF0Y2hlcy9z ZXJpZXMJMjAyMy0wMy0yOCAxMToxMzoyNS4wMDAwMDAwMDAgKzAxMDAKKysrIG1lc29uLTEuMy4x L2RlYmlhbi9wYXRjaGVzL3NlcmllcwkyMDI0LTAyLTEzIDEzOjIzOjMzLjAwMDAwMDAwMCArMDAw MApAQCAtMSwyICsxLDMgQEAKIDEtZGlzYWJsZS1vcGVubXBpLnBhdGNoCiAyLWRpc2FibGUtcm9v dGRpci10ZXN0LnBhdGNoCitscDIwNDk5MDQtd29ya2Fyb3VuZC5wYXRjaAo=

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mate Kukri@21:1/5 to mate.kukri@canonical.com on Tue Feb 13 16:50:01 2024
    Unfortunately this patch was rather optimistic, there are 7 or so more
    tests failing similarly, so more is needed to workaround this.

    On Tue, Feb 13, 2024 at 2:33 PM Mate Kukri <mate.kukri@canonical.com> wrote:

    Hello,

    We have a similar issue in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/2049904

    To me this seems like a rust linking issue, the same C library
    compiled with cc, then linked against a C stub program links just fine
    for me.

    In comparison rustc tries to be annoyingly clever and calls `cc` to
    link with `-nodefaultlibs` and tries to manually provide all the
    required libraries, which makes it fail.

    The direct cause of the error is a library ordering issue, `-lc`
    should always come after all C static libs and object files in a link command, but it does not.

    It seems that meson doesn't pass `-Clink-arg=-lc` to `rustc` at all by default (which it probably shouldn't need to), and it's rustc itself
    that emits `-lc` at the wrong location.

    A workaround is as follows:
    ```
    dep_libc = declare_dependency(link_args : '-lc')

    l = static_library(
    'c_accessing_zlib',
    'c_accessing_zlib.c',
    dependencies: [dep_zlib, dep_libc],
    )
    ```

    It is rather unweildly to read, but here's an example of an offending
    link invocation by rustc:
    ```
    LC_ALL="C" PATH="/usr/lib/rustlib/aarch64-unknown-linux-gnu/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"
    VSLANG="1033" "cc" "/tmp/rustcqxuAcC/symbols.o" "prog.p/prog.prog.3a9e8efe5d7989d1-cgu.0.rcgu.o" "prog.p/prog.2valzr4aprd78wdd.rcgu.o" "-Wl,--as-needed" "-L" "." "-L" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd-3f505df5bf7b6973.rlib" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libpanic_unwind-f7bbfb2a4f0106ba.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libobject-799d4aa6228550fd.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libmemchr-817c1781430e6007.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libaddr2line-ad8936af23d8ece8.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libgimli-fa9ccab1157705c6.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_demangle-0f0344f8af442a24.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libstd_detect-f1d03073262366fd.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libhashbrown-d2b728fe429f73fd.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-78f4eeade0e7b3f3.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libminiz_oxide-386abc7d4431b549.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libadler-f2fbe97df215d47a.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libunwind-1b9c021e2652ca95.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcfg_if-a31e7b8703ef1917.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/liblibc-67315dfc1c311b62.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/liballoc-6f13ad92e9ef28f1.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/librustc_std_workspace_core-4647df6db5bfc191.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcore-7ca28360f44e13c1.rlib"
    "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib/libcompiler_builtins-bda26fded9d4fbc7.rlib"
    "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl"
    "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/usr/lib/rustlib/aarch64-unknown-linux-gnu/lib" "-o" "prog" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "libc_accessing_zlib.a" "-lz"
    ```

    Which was produced by the following rustc invocation:
    ```
    rustc -C linker=cc --color=always -C debug-assertions=yes -C overflow-checks=no --crate-type bin -g --crate-name prog --emit dep-info=prog.d --emit link=prog --out-dir prog.p -C metadata=prog@exe -Clink-arg=libc_accessing_zlib.a -Clink-arg=-lz -L. ../prog.rs
    ```

    As a note, same issue repros on the latest nightly rustc also.

    Fixing rustc instead of meson is the real solution, but I don't think
    this should be holding up meson migrating, as such I am attaching a workaround patch similar to the one I have proposed for Ubuntu.

    Mate Kukri

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