Add dyld_requires

[mwoehlke]

Add attributes to allow specifying requirements that are only needed to satisfy the dynamic library loader (or the linker, when operating in certain strict modes).

Because these are only needed by the build in limited cases (and arguably are only "needed" to work around broken environments), this is not being treated as a breaking schema change.

Fixes: #106

[mwoehlke]

Please note that the naming is proposed; the existence of this PR should not be taken as an indicator that my mind is made up and I will not budge. 🙂

Also, PLMK if the documentation seems adequate/correct. (Though we can always fix that editorially if needed.)

[dcbaker]

I think I understand the intention of dylib_libraries from the linked issue discussion, but the description in the proposed text reads to me as dylib_libraries as a deprecated synonym for dylib_requires

[mwoehlke]

@dcbaker , thanks for the review! I see your point, and link_libraries has the same issue. Fix incoming...

[nickelpro]

+1 for the names and general schema change.

The wording has room for improvement. While I'm happy with the names as fine, I think avoiding the discussion of ld.bfd -rpath-link in the description is too coy. We have a specific problem, this is a specific solution. We avoid canonizing the flags in the property names, which is good, but right now I would have no idea what these are for from the description. If I read these cold I would think I'm obligated to pass them to -Wl,rpath.

[nickelpro]

To be clear: description text is not a blocker for me

[mwoehlke]

I think avoiding the discussion of ld.bfd -rpath-link in the description is too coy.

I don't. To the extent this is also a runtime requirement, it definitely isn't limited to ld.bfd. And CMake (n.b. IMPORTED_LINK_DEPENDENT_LIBRARIES) doesn't say anything about even "rpath", much less specific linkers or link flags.

[nickelpro]

There's no linker besides ld.bfd which requires "linker searches for the dependent libraries of shared libraries they are including in the link" absent options like --no-undefined.

It's not a runtime requirement at all. That's what normal rpath is for. CMake doesn't do anything which affects runtime with IMPORTED_LINK_DEPENDENT_LIBRARIES.

[nickelpro]

The CMake documentation is for users of CMake, the CPS documentation is for build system implementors. It behooves us to be more technically specific about what fields are for in the implementation of build systems.

[dcbaker]

Meson doesn't have a public interface for setting -rpath-link, but we do it automatically for bfd (I think we do it for gold too even though it isn't necessary, but I digress). I agree with @nickelpro that adding notes about implementation details is appropriate, even if we want to couch them in an "implementation details" block or some such.

[mwoehlke]

It's not a runtime requirement at all. That's what normal rpath is for. CMake doesn't do anything which affects runtime with IMPORTED_LINK_DEPENDENT_LIBRARIES.

...and because it doesn't, trying to run the resulting executable will also fall flat on its face. If we have A, which (privately) links B... we need this in the case that B can't otherwise be found. If B is in A's rpath, the linker doesn't need us to hold its hand, and neither does the dynamic loader. If B is in a default search path, same thing. If neither of those is the case, both the linker (ld.bfd at least) and the dynamic loader need to be told how to find B. Thus: run time (and sometimes link time) requirement.

[mwoehlke]

an "implementation details" block or some such

I'd be okay with this. Actually, I can think of other reasons we might want it, e.g. nothing talks about how the various [*_]requires ought to be disjoint. However, I think I'd prefer to punt on that so we can get the schema change landed. I'm already a bit uncomfortable with how long this attribute's immediate description is compared to others.

[mwoehlke]

@memsharded, @nickelpro, if you're okay with the current state, can one of you actually approve this? (A "+1" comment doesn't count; please leave a Review.)

[nickelpro]

If B is in A's rpath, the linker doesn't need us to hold its hand, and neither does the dynamic loader.

It does need us to hold its hand, BFD does not expand $ORIGIN at build link like ld.so does, so normal usage requires -rpath-link even for libraries that would otherwise work at runtime. That's the entire reason build systems do this dance with BFD.

That said I don't have any actual problems with the PR.

[nickelpro]

For posterity:

BFD does not expand $ORIGIN at build link like ld.so does, so normal usage requires -rpath-link even for libraries that would otherwise work at runtime

This knowledge is out-of-date, it turns out this was fixed in binutils 2.28, so this field is barely needed anymore, and is mostly a legacy novelty.

[memsharded]

Good for me, sorry I am late to the review.

Approved from my side.

[memsharded]

It would be good to clarify here that the paths doesn't need to be absolute, and that a possible intended use case, if I understood it correctly, is linkage to system libraries such as typical -lm -lpthread or w_sock32 in Win, that are necessary to be specified, so link_libraries = ["wsock32"] would be a valid entry?

[memsharded]

Good to me, though would have been nice to have a explicit reference to the -rpath-link ld flag as a motivator and example of the need for this item.