src: Port Go build wrapper from Shell to Python & support externaly defined build options #1031
Conversation
HarryMichal
added
6. Minor Change
HarryMichal
changed the title
There was a problem hiding this comment.
Yes, this will be good to have. I once thought of it, but the shell script started giving me nightmares.
Maybe this is be a good time to add some tests to sanity check the built binary?
The go-build-wrapper script encapsulates a lot of subtle, but crucial, details and we don't want to regress anything. eg., the path to the dynamic linker, the rpath, etc.. Ideally we would add the test first to test the old script, and then introduce the new script -- that way we can trivially verify (through git bisect, etc.) that everything is good.
src/go-build-wrapper.py
Outdated
| output_dir = sys.argv[2] | ||
| version = sys.argv[3] | ||
| cc = sys.argv[4] | ||
| dyn_linker = sys.argv[5] |
There was a problem hiding this comment.
Would be better to use terms like dynamic_linker, dynamic-linker everywhere. They are easier to grep for (eg., searching for dynamic will get you better results), and can defend against typos by making them stand out.
|
Build failed.
|
HarryMichal
force-pushed
the
build-script-update
branch
from
531cf4b to
a29ac02
Compare
|
Build failed.
|
Toolbx requires some binary-level adjustments to accomplish its job. Potential regressions in the wrapper build script need to be caught to prevent breakage.
HarryMichal
force-pushed
the
build-script-update
branch
from
a29ac02 to
74cb8e7
Compare
|
Build failed.
|
HarryMichal
force-pushed
the
build-script-update
branch
from
74cb8e7 to
704e1d0
Compare
Some downstreams (e.g., Fedora) set additional flags while building software in their repositories. This also applies to software written in Go. This work removes the need for manually patching the 'go build' wrapper script, needed for integrating 'go build' into Meson, to add the desired build options. This introduces a new build option 'go_build_flags'.
HarryMichal
force-pushed
the
build-script-update
branch
from
704e1d0 to
d0b7a84
Compare
|
Build succeeded.
|
| package binary | ||
|
|
||
| import ( | ||
| "debug/elf" |
There was a problem hiding this comment.
How does Go's debug/elf compare with other implementations like GNU Binutils, in terms of architecture support and the ability to handle a diverse variety of ELFs?
There was a problem hiding this comment.
Overall I'd say the support is lower than of readelf from GNU Binutils. From what I understood though, debug/elf supports both 32-bit and 64-bit architectures and recognizes many machine types and many OS ABIs. Though, am not sure how the last two parts translate into "architecture support". Most likely didn't answer your question in full.
Probably is noteworthy that the tool is for checking the Toolbx binary and not an arbitrary binary. My presumption is that whether Go is capable of producing a binary on a certain architecture, the created binary also has to be processable by the debug/elf package.
No description provided.