Florian Weimer <[email protected]> wrote on Tuesday, September 24, 2019 1:55 PM > * Cem F. Karan: <<SNIP>> > > That said, I for one would find it *highly* amusing if gcc/clang added > > a switch to embed the complete project into the binary (or even a git > > bundle, so you can do a pull from an executable). > > It's not unreasonable to do this for link-time optimization purposes. > Source code is more compact than compiler IR and also stable across minor > (and hopefully) major versions of the compiler. But that > would only apply to code that can be re-linked. > > That being said, there is a huge difference in low-evel debugging on Fedora > and downstreams, where debugging information and source > code is readily available, and the reset. So there is something to be said > for shipping corresponding source code that was actually > compiled, and not just upstream tarballs plus downstream patches.
This is actually starting to sound like an interesting/good idea. For GPL compliance, you can't get much better than having the source artifacts stored with the binary itself. So, the question is, what is the easiest way to test storing all artifacts within a binary? I did an extremely fast perusal of what 'apt search' would give me for editing ELF files, but haven't installed or tested anything. Is there a command-line tool that already exists that would let us store arbitrary data in an ELF binary? I'd like to see how far we can push the concept... Thanks, Cem Karan --- Other than quoted laws, regulations or officially published policies, the views expressed herein are not intended to be used as an authoritative state of the law nor do they reflect official positions of the U.S. Army, Department of Defense or U.S. Government. _______________________________________________ License-discuss mailing list [email protected] http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
