This script is interesting because it requires that a relative path to libxul be passed, and recursively reads from the shared libs libxul depends on, both of which cause failures right now in the tup backend. I have a hackaround that puts all our shared libs in a group that dependentlibs.list lists as an input as a special case, but we may be able to do better.

Actually, now that we have all the linkage information in the emitter, couldn't we just magic up the list of shared libs that libxul links to, and make this a `CONFIGURE_SUBST_FILE` or something like that?

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #1) > Actually, now that we have all the linkage information in the emitter, > couldn't we just magic up the list of shared libs that libxul links to, and > make this a `CONFIGURE_SUBST_FILE` or something like that? Possibly, if we take `SONAME` into account. I haven't dug into this yet but there seem to be some dependent libs listed on windows our build system doesn't know about.

Ah yeah, the CRT libs wind up in there and they're implicitly linked in. We do have *some* knowledge of them in the build system, but only as `FINAL_TARGET_FILES`: https://dxr.mozilla.org/mozilla-central/rev/071ee904485e21e19ca08456d32bce6825b77a26/build/win32/moz.build#18

Just for reference, I have the same hack as Chris available at https://github.com/layus/gecko-dev/commits/tup-backend-2. I had to add a group of all the shared objects because linking programs to libxul.so also tried to access the dependencies of these libs. This is available at https://github.com/layus/gecko-dev/commit/648c8a33b2f31fac9ea5cc8215637b35d2743e50. The particular case of programs depending on xul is managed in this line https://github.com/layus/gecko-dev/commit/648c8a33b2f31fac9ea5cc8215637b35d2743e50#diff-6706204b29a944832534fc2c33e7efd4R386. To pass a relative path to the dependentlibs.list generator, I found out that you can just pass files in objdir in a relative fashion, and files in srcdir as absolute paths. Passing topsrcdir files in a relative fasion crashes some python scripts with an issue mentionning "topobjdir boundray". See https://github.com/layus/gecko-dev/commit/3057aa89175e65a0a213d821267301e23f0f8283 I think that a group containing all the shared libraries may turn out to be useful anyway if you want to run tests.

This can improve once bug 1459764 lands, but I want to wait on Tup improvements to allow us to write rules out of order for that. For now I have a patch that I'll land as part of bug 1319228, since rust/libxul/dependentlibs.list are mostly intertwined for our purposes.