Discussion:
Revert "meson: use the host architecture compiler/linker for src/boot/efi" #10217
(too old to reply)
Helmut Grohne
2018-09-30 17:57:05 UTC
Permalink
Hi,
This reverts commit df7caca.
If you reverts df7caca, please also revert b710072 as that breaks cross
builds.
The patch df7caca breaks normal build. Let's revert this, as I do not want to revert this every time when setting up a new build directory to test some branch.
No, it doesn't. It only breaks the normal build if you supply a cc that
consists of multiple words (such as "ccache gcc"). As a workaround, you
can simply prepend /usr/lib/ccache to $PATH on most distributions.

Worse, without df7caca, the build wasn't using the compiler you asked
for. It was using plain "gcc". Reverting just gets you a build failure
in the best case and a miscompilation in the worst. You must also revert
b710072 to get a sane build.
@helmutg If you can fix the issue soon, then I will close this. But if you have not enough time to fix the issue, then I think it is reasonable to revert the commit.
I filed this build failure almost two months ago, see
https://bugs.debian.org/905381. And the meson maintainer had me wait
since April (close to when the breaking commit was introduced) to add
the relevant tools to the cross file generator (see
https://bugs.debian.org/895636). If a reported build problem with
systemd can remain unfixed for almost half a year, then surely there is
not the slightest need to rush this. Please hold off.

Now getting to the actual failure: efi_cc gets used in two distinct
ways. It gets interpolated into strings that are passed to the shell,
which performs word splitting and that's all fine (e.g. line 60). It is
also used to construct an argument vector for a custom_target command
(https://github.com/systemd/systemd/blob/df7cacae696/src/boot/efi/meson.build#L152)
and run_command
(https://github.com/systemd/systemd/blob/df7cacae696/src/boot/efi/meson.build#L163).

So the proper fix involves changing these two lines to split efi_cc at
spaces before interpolating it into the argument vectors.

That should be doable with efi_cc.split(' ') and array concatentation
seems to be +.

So line 152 should likely become

command : efi_cc.split(' ') + ['-c', '@INPUT@', '-o', '@OUTPUT@']

For line 163, this is not as easy as run_command does not expect an
array. We can use the same workaround as in line 61 though and run it
through a shell.

libgcc_file_name = run_command('sh', '-c' , '@0@ -print-libgcc-file-name'.format(efi_cc)).stdout().strip()

Could you check whether that solves your issue?

Helmut
Michael Biebl
2018-09-30 18:04:00 UTC
Permalink
Post by Helmut Grohne
I filed this build failure almost two months ago, see
https://bugs.debian.org/905381. And the meson maintainer had me wait
since April (close to when the breaking commit was introduced) to add
the relevant tools to the cross file generator (see
https://bugs.debian.org/895636). If a reported build problem with
systemd can remain unfixed for almost half a year, then surely there is
not the slightest need to rush this. Please hold off.
To be fair, you filed the "Debian" bug report 2 months ago and I told
you to file this upstream, which you did not do.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Mike Gilbert
2018-10-01 03:47:49 UTC
Permalink
Post by Helmut Grohne
Hi,
This reverts commit df7caca.
If you reverts df7caca, please also revert b710072 as that breaks cross
builds.
The patch df7caca breaks normal build. Let's revert this, as I do not want to revert this every time when setting up a new build directory to test some branch.
No, it doesn't. It only breaks the normal build if you supply a cc that
consists of multiple words (such as "ccache gcc"). As a workaround, you
can simply prepend /usr/lib/ccache to $PATH on most distributions.
meson automatically sets the C compiler ['ccache', 'cc'] if ccache is
in PATH. This happens by default unless CC is set in the environment.

Anyway, I submitted a pull request that fixes the issue, so no revert
will be necessary here.

https://github.com/systemd/systemd/pull/10220

Also, it would be much nicer if you would keep the discussion in one
place (github) instead of spreading it onto the mailing list. I did
not see this thread for several hours after having already fixed the
problem myself.

Loading...