-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a binutils module #6063
Comments
Which features are those? IIRC the name-prefixed versions have (most of) the settings already so specifying objcopy in your cross file's executable section makes |
in particular the o = binutils.objcopy(
output : 'foo.o',
input : 'input.file',
target : 'host' | 'build' # target?
args : ['some', 'other' args'],
) would be much nicer than what I have now, which is: if host_machine.system() == 'linux' # TODO: solaris, bsd, etc
if host_machine.cpu_family() == 'x86_64'
b_arch = 'i386:x86_64'
b_type = 'elf64-x86-64'
elif host_machine.cpu_fmaily() == 'x86'
b_arch = 'i386'
b_type = 'elf32-i386'
endif
endif
# TODO: all the other things
p = find_program('objcopy')
o = custom_target(
...
command : [
p, '--input', 'binary', '--output', b_type, '--binary-architecture', b_arch, '@INPUT@', '@OUTPUT@'
]
) At least on my system there is no |
Would there be some way to specify the binutils, like llvm vs. gnu? |
For comparison, Debian does have an |
I believe Meson doesn't let the user invoke the assembler or the linker directly, correct? The only two options are
Meson is still relatively new to me, sorry if I missed something here. While C and C++ are highly portable languages, assembly and linker code are very far from it (and will probably never be). Consider the EDK2 project for instance: it supports a large and diverse set of operating systems and toolchains. However for x86 assembly it supports only one assembler, which I think rules out option 1. So I hope this "Add a binutils module" issue #6063 is among others about adding new (and of course optional) |
You can already do that. The binaries entry overrides all lookups via |
Was this an answer to "Would there be some way to specify the binutils, like llvm vs. gnu" ? |
This proved easier than I thought, not the least thanks to # This library is not used, this is just a convenient way to
# compile everything in one step.
fake_lib = static_library(...
'1.c', '2.S', ... ,
c_args: [ '-fno-pic', ....]
)
# fake_lib also solves this circular dependency problem \o/
# https://github.com/mesonbuild/meson/pull/6061#issuecomment-547138357
#
# '@' is not allowed in linker scripts;
# search and replace 'fakelib@sta' with 'fakelib?sta'
# https://github.com/mesonbuild/meson/pull/291
lib_dir = '?'.join(fake_lib.get_id().split('@'))
very_not_portable_linker_script = configure_file(...
configuration : { 'OBJSDIR': lib_dir }
)
very_specific_linker = find_program('my-ld')
bare_metal = custom_target(...
input: fake_lib.extract_all_objects(),
# [2019-11-12 comment]
# Ideally, linker scripts should be part of the "input:", however:
# 1. prefixing files("myscript.lds")[n] with '--script=' doesn't seem
# possible: "error: can only concatenate str (not "File") to str"
# 2. prefixing only _some_ of the @INPUTn@ and not the object files
# seems difficult too.
# So let's pretend linker scripts are "depend_files:" not part of the
# "command:" and then sneak them into the command: behind
# meson's back.
depend_files: very_not_portable_linker_script,
command: [ very_specific_linker ] + [ '@INPUT@' ]
+ [ '--script=' + very_not_portable_linker_script ]
+ [ '-o', '@OUTPUT@' ]
...
) |
I tried this with XCode 11 (clang v10) and it was a disaster. At first sight Granted this is just one front-end example, however I suspect most low-level / bare metal development requires invoking the linker directly because of the fine level of control required. I mean I suspect the front-end layer of indirection typically assumes too much and that gets in the way. I'm of course not considering targets that depend on a single, vendor-specific toolchain. Who cares about those :-) Curious how high is "bare-metal" on the list of Meson requirements/priorities? Found these:
|
Bare metal is important to us. There are in fact commercial products that ship with firmwares built with Meson (or, at least, this seems very strongly to be the case given certain bugs and discussions I have had with people, but sadly there is no public info I can point people to). |
Thanks! However it's more subtle and took me some time to figure it out. While powerful, I think it's very unusual for a string in any language to be both a symbol and a literal!
|
In theory, @dcbaker of |
Seems related to |
When invoked by clang the linker will do what it thinks is correct. For native macos builds, it has macos things:
For cross builds, it removes the macos things. For example,
Cheers, |
I think having a module for dealing with the tools provided by gnu binutils (and alternate implementations like the llvm ones) would be pretty useful.
In my case I'm using
objcopy
, and being able to have some of the arguments about the host and build machine populated automatically would be pretty handy.There's also #5995, and having some sort of
binutils.configure_linker_script
seems useful.I'm planning to get around to this myself, but there are some other things I need to get to first, including fixing regressions in 0.50. The main purpose of this issue is to collect other ideas that should be added to this module and solicit feedback.
The text was updated successfully, but these errors were encountered: