[Feature Request] : Object Libraries (again)

[aydinmercan]

Currently, meson, despite being amazing, is currently not very ergonomic with tools that work with object files. While most requests for an object "library" wanted something else so far, there are some situations where this is really needed:

• Adding userspace probing DTrace uses the object file to create a new object file with probes added. (SystemTap works directly but is Linux-only)
• Dumping symbols in a .def file

The current workarounds add more complexity, have a performance hit and reusing the object file needs extra care.

For example, to add DTrace probes, you first have to compile the library unprobed, extract the objects for DTrace and re-link everything in a probed library. Apart from the extra work itself, the additional linking also amplifies LTO slowdowns without any benefit. Being able to create object files would greatly help fixing these issues and be way more readable.

I can try to pick up adapt the similar work in https://github.com/mesonbuild/meson/pull/8151 if the capability to do so isn't rejected. 🙂‍↕️

[eli-schwartz]

We essentially have this already:

stlib = static_library(..., build_by_default: false)

object_library = stlib.extract_all_objects()

It's just a terribly counterintuitive UI and having a dedicated object library type would probably be a lot less awkward.

Note that this approach would create a link rule that runs the static archiver, but you would simply never run that rule because nothing depends on it. Everything depends on the collected objects instead.

there are some situations where this is really needed:

• Adding userspace probing DTrace uses the object file to create a new object file with probes added. (SystemTap works directly but is Linux-only)

I've heard that use case suggested before and it would indeed be nice. Note that extracted objects don't work here because we don't support specifying them as inputs to a custom_target I think! An object library functionality would have to be designed with this historical lesson in mind.

• Dumping symbols in a .def file

This isn't a good reason to add object libraries, becJse that's basically a terrible UX for users to manually dump the symbols. :) The real answer is that we already have a feature request for an option to library() to have meson implement and run its own dumper. This would allow implementing compatibility with both cmake's "export all symbols" and also libtool's considerably more elegant -export-symbols-regex (which is almost always just used for prefix-based globbing, and I'm not convinced we want to directly support regex due to the proliferation of regex dialects).

A bunch of people want this, it's just that no one ever got around to implementing it. First step is, someone would need to write a python implementation of a symbol dumper that only uses the VS provided utilities.

[aydinmercan]

Note that this approach would create a link rule that runs the static archiver, but you would simply never run that rule because nothing depends on it. Everything depends on the collected objects instead.

Aha! I didn't knew build_by_default would work like that, thanks! That got rid of the extra linking/archiving work.

Note that extracted objects don't work here because we don't support specifying them as inputs to a custom_target I think! An object library functionality would have to be designed with this historical lesson in mind.

Nope, I tested it just now and works well! Either way, if someone doesn't do it before, I'll see what can I do when I am less busy.

This isn't a good reason to add object libraries, because that's basically a terrible UX for users to manually dump the symbols. :)

Fair enough, I don't have a need for this but I thought I'd include it since they use the same workaround. 😝