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.ku...@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
