After reconfiguring old object files are still linked in

Describe the bug

After removing a source file in the Meson build definition, Meson reconfigures and then that source file is not compiled, but the corresponding object file (available from previous compilations) is still passed as input to the linker.

To Reproduce I have created a very simple branch from the master branch that adds a source file to GdkWin32. That source file uses a function from cabinet.dll so it adds a new dependency on a system DLL.

So I can run Meson and build that branch just fine. But then if I checkout the master branch and try a rebuild I get:

Build targets in project: 114
gtk 4.5.0
Option buildtype is: debug [default: debugoptimized]
Found ninja-1.10.2 at D:\msys64\mingw64\bin/ninja.EXE
[1/41] Generating demo-header with a custom command (wrapped by meson to capture output)
[2/36] Compiling C object gdk/win32/libgdk-win32.a.p/gdkdisplay-win32.c.obj
[3/36] Linking static target gdk/win32/libgdk-win32.a
[4/36] Linking static target gdk/libgdk.a
[5/36] Linking target tools/gtk4-update-icon-cache.exe
[6/36] Linking target gtk/libgtk-4-1.dll
FAILED: gtk/libgtk-4-1.dll
"cc"  -o gtk/libgtk-4-1.dll  "-Wl,--allow-shlib-undefined" "-shared" "-Wl,--start-group" "-Wl,--out-implib=gtk/libgtk-4.dll.a" "-Wl,--whole-archive" "gtk/libgtk.a" "gtk/css/libgtk_css.a" "gdk/libgdk.a" "gsk/libgsk.a" "-Wl,--no-whole-archive" "gdk/win32/libgdk-win32.a" "gsk/libgsk_f16c.a" "-Wl,-Bsymbolic" "D:/msys64/mingw64/lib/libgmodule-2.0.dll.a" "-pthread" "D:/msys64/mingw64/lib/libglib-2.0.dll.a" "D:/msys64/mingw64/lib/libintl.dll.a" "D:/msys64/mingw64/lib/libgobject-2.0.dll.a" "D:/msys64/mingw64/lib/libgio-2.0.dll.a" "D:/msys64/mingw64/lib/libpangocairo-1.0.dll.a" "D:/msys64/mingw64/lib/libpango-1.0.dll.a" "D:/msys64/mingw64/lib/libharfbuzz.dll.a" "D:/msys64/mingw64/lib/libcairo.dll.a" "D:/msys64/mingw64/lib/libfribidi.dll.a" "D:/msys64/mingw64/lib/libcairo-gobject.dll.a" "D:/msys64/mingw64/lib/libgdk_pixbuf-2.0.dll.a" "D:/msys64/mingw64/lib/libepoxy.dll.a" "-lm" "D:/msys64/mingw64/lib/libgraphene-1.0.dll.a" "D:/msys64/mingw64/lib/libpangoft2-1.0.dll.a" "D:/msys64/mingw64/lib/libfontconfig.dll.a" "D:/msys64/mingw64/lib/libfreetype.dll.a" "D:/msys64/mingw64/lib/libpangowin32-1.0.dll.a" "-ladvapi32" "-lcomctl32" "-lcrypt32" "-ldwmapi" "-limm32" "-lsetupapi" "-lwinmm" "-lintl" "D:/msys64/mingw64/lib/libpng16.dll.a" "D:/msys64/mingw64/lib/libz.dll.a" "D:/msys64/mingw64/lib/libtiff.dll.a" "D:/msys64/mingw64/lib/libjpeg.dll.a" "-lhid" "-lcairo-script-interpreter" "-ladvapi32" "-lcomctl32" "-lcrypt32" "-ldwmapi" "-limm32" "-lsetupapi" "-lwinmm" "-lintl" "-lhid" "-lcairo-script-interpreter" "-lhid" "-lhid" "-lcairo-script-interpreter" "-lhid" "-lcairo-script-interpreter" "-lhid" "-lkernel32" "-luser32" "-lgdi32" "-lwinspool" "-lshell32" "-lole32" "-loleaut32" "-luuid" "-lcomdlg32" "-Wl,--end-group"
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: gdk/libgdk.a(gdkfoo-win32.c.obj): in function `gdk_foo_win32_do_work':
D:\gtk4-test-build/../gtk4/gdk/win32/gdkfoo-win32.c:9: undefined reference to `FCICreate'
D:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:\gtk4-test-build/../gtk4/gdk/win32/gdkfoo-win32.c:15: undefined reference to `FCIDestroy'
collect2.exe: error: ld returned 1 exit status
[7/36] Linking target tools/gtk4-encode-symbolic-svg.exe
[8/36] Linking target gtk/compose/compose-parse.exe
ninja: build stopped: subcommand failed.

But gdkfoo-win32.c does not exist at all in the master branch!

Links

• new-feature branch: https://gitlab.gnome.org/lb90/gtk/-/commits/new-feature

Step by step

1. git clone https://gitlab.gnome.org/lb90/gtk.git --branch new-feature
2. mkdir gtk-build && cd gtk-build
3. meson ../gtk --buildtype=debug -Dintrospection=disabled -Dbuild-tests=false && ninja
4. (Everythin builds) Now checkout the master branch
5. Run ninja again

Expected behavior The master branch is built just fine

What happens Building the libgdk-3-0.dll target fails at the link stage because gdkfoo-win32.c.o is still linked-in, though there’s no reference of it anymore in the meson.build file.

system parameters

• native build
• Windows 10
• Python 3.9.7
• Meson 0.59.1
• Ninja 1.10.2

[eli-schwartz]

It’s not a security issue in the general case, at least on unix the actual command line that gets run is single-quoted and thus treated as a string literal.

It’s also a solvable problem on Windows too, e.g. python’s subprocess module with shell=False has a security promise that you don’t need to worry about shell injection vulnerabilities, since it will safely handle everything for you when given a list of command+argv. As for Meson itself, we should be safe there, as we implement this specially in a cross-platform way by using shlex.quote on unix and a custom implementation at mesonbuild.mesonlib.universal.quote_arg which should follow documented Microsoft practice.

That being said, this is a build system, it runs arbitrary commands arbitrarily, by design. I don’t think allowing shell metacharacter injection is a security danger, merely a robustness danger.

[eli-schwartz]

That’s fascinating. On my machine, this rule looks like this:

# Rules for linking.

rule STATIC_LINKER
 command = rm -f $out && gcc-ar $LINK_ARGS $out $in
 description = Linking static target $out

It turns out the problem is that this got explicitly disabled on Windows in #1527 due to #1517