On 18/03/15 21:13, Martin Lucina wrote:
[email protected] said:
One string we could pull from in the future is the fact that we're
crosscompiling, and the build system doesn't know how to run the
resulting binary. So we could pseudo-link the target, and then have
rumprun actually link it (and cache the result). That approach
should also solve cases where we'd want to crunch multiple binaries
into a single image. I'm sure there are examples and experiences of
this type of approach floating about, just need to survey them for
the drawbacks.
How would such pseudo-linking work? Please point me to the examples you
mention, so that I can get an idea of what would be required.
"I'm sure there are examples" != "I know what the examples are". For
some reason I imagine Apple does something like that, but not sure,
didn't check yet.
We can't use "ld -r" as a pseduo-link step, since that just treats
undefined symbols as "will be resolved later".
I don't think there's any reason for pseudo-linking to use -r. It can
just link the userspace bits much like cc.configure does now. That
takes care of testing that the "userspace" part of the configuration
works, which is an important part of the "compile-tested" feedback loop
for the user. The pseudo-linker can then record the names of the
objects and libs and other ld command line parameters into the target
file, from where rumprun picks them up when it does the actual linking.
This mail is not a specification, in case that wasn't clear.
