diff mbox series

[v6,01/19] configure, meson: override C compiler for cmake

Message ID 4bef7bdd7309e128eca140a2324a126346c9f1f1.1645079934.git.jag.raman@oracle.com (mailing list archive)
State New, archived
Headers show
Series vfio-user server in QEMU | expand

Commit Message

Jag Raman Feb. 17, 2022, 7:48 a.m. UTC
The compiler path that cmake gets from meson is corrupted. It results in
the following error:
| -- The C compiler identification is unknown
| CMake Error at CMakeLists.txt:35 (project):
| The CMAKE_C_COMPILER:
| /opt/rh/devtoolset-9/root/bin/cc;-m64;-mcx16
| is not a full path to an existing compiler tool.

Explicitly specify the C compiler for cmake to avoid this error

Signed-off-by: Jagannathan Raman <jag.raman@oracle.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
---
 configure | 2 ++
 1 file changed, 2 insertions(+)

Comments

Peter Maydell Feb. 17, 2022, 12:09 p.m. UTC | #1
On Thu, 17 Feb 2022 at 07:56, Jagannathan Raman <jag.raman@oracle.com> wrote:
>
> The compiler path that cmake gets from meson is corrupted. It results in
> the following error:
> | -- The C compiler identification is unknown
> | CMake Error at CMakeLists.txt:35 (project):
> | The CMAKE_C_COMPILER:
> | /opt/rh/devtoolset-9/root/bin/cc;-m64;-mcx16
> | is not a full path to an existing compiler tool.
>
> Explicitly specify the C compiler for cmake to avoid this error

This sounds like a bug in Meson. Is there a Meson bug report
we can reference in the commit message here ?

thanks
-- PMM
Jag Raman Feb. 17, 2022, 3:49 p.m. UTC | #2
> On Feb 17, 2022, at 7:09 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> On Thu, 17 Feb 2022 at 07:56, Jagannathan Raman <jag.raman@oracle.com> wrote:
>> 
>> The compiler path that cmake gets from meson is corrupted. It results in
>> the following error:
>> | -- The C compiler identification is unknown
>> | CMake Error at CMakeLists.txt:35 (project):
>> | The CMAKE_C_COMPILER:
>> | /opt/rh/devtoolset-9/root/bin/cc;-m64;-mcx16
>> | is not a full path to an existing compiler tool.
>> 
>> Explicitly specify the C compiler for cmake to avoid this error
> 
> This sounds like a bug in Meson. Is there a Meson bug report
> we can reference in the commit message here ?

Hi Peter,

I’ll try to locate the bug report and the meson version which has the fix,
and get back to you.

Thank you!
--
Jag

> 
> thanks
> -- PMM
Jag Raman Feb. 18, 2022, 3:40 a.m. UTC | #3
> On Feb 17, 2022, at 7:09 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> On Thu, 17 Feb 2022 at 07:56, Jagannathan Raman <jag.raman@oracle.com> wrote:
>> 
>> The compiler path that cmake gets from meson is corrupted. It results in
>> the following error:
>> | -- The C compiler identification is unknown
>> | CMake Error at CMakeLists.txt:35 (project):
>> | The CMAKE_C_COMPILER:
>> | /opt/rh/devtoolset-9/root/bin/cc;-m64;-mcx16
>> | is not a full path to an existing compiler tool.
>> 
>> Explicitly specify the C compiler for cmake to avoid this error
> 
> This sounds like a bug in Meson. Is there a Meson bug report
> we can reference in the commit message here ?

Hi Peter,

This issue reproduces with the latest meson [1] also.

I noticed the following about the “binaries” section [2]. The manual
says meson could pass the values in this section to find_program [3].
As such I’m wondering if it’s OK to set compiler flags in this section
because find_program doesn’t seem to accept any compiler flags.

The compiler flags could be set in the “built-in options” section using
options such as “c_args”, “cpp_args” and “objc_args” [4]. When I
moved CPU_CFLAGS from the binaries section to the built-in-options
section in “configure", I don’t see the issue anymore. 

[1]: https://github.com/mesonbuild/meson.git
[2]: https://mesonbuild.com/Machine-files.html#binaries
[3]: https://cmake.org/cmake/help/latest/command/find_program.html
[4]: https://github.com/mesonbuild/meson/blob/master/docs/markdown/Reference-tables.md (section “Language arguments parameter names")

Thank you!
--
Jag

> 
> thanks
> -- PMM
Paolo Bonzini Feb. 18, 2022, 12:13 p.m. UTC | #4
On 2/18/22 04:40, Jag Raman wrote:
> 
> 
>> On Feb 17, 2022, at 7:09 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On Thu, 17 Feb 2022 at 07:56, Jagannathan Raman <jag.raman@oracle.com> wrote:
>>>
>>> The compiler path that cmake gets from meson is corrupted. It results in
>>> the following error:
>>> | -- The C compiler identification is unknown
>>> | CMake Error at CMakeLists.txt:35 (project):
>>> | The CMAKE_C_COMPILER:
>>> | /opt/rh/devtoolset-9/root/bin/cc;-m64;-mcx16
>>> | is not a full path to an existing compiler tool.
>>>
>>> Explicitly specify the C compiler for cmake to avoid this error
>>
>> This sounds like a bug in Meson. Is there a Meson bug report
>> we can reference in the commit message here ?
> 
> Hi Peter,
> 
> This issue reproduces with the latest meson [1] also.

0.60.0 or more recent versions should have a fix, which would do exactly 
what this patch does: do not define CMAKE_C_COMPILER_LAUNCHER, and place 
the whole binaries.c variable in CMAKE_C_COMPILER.  What are the 
contents of the genrated CMakeMesonToolchainFile.cmake and 
CMakeCache.txt files, without and with your patch?

> I noticed the following about the “binaries” section [2]. The manual
> says meson could pass the values in this section to find_program [3].
> As such I’m wondering if it’s OK to set compiler flags in this section
> because find_program doesn’t seem to accept any compiler flags.

The full quote of the manual is "These can be used internally by Meson, 
or by the find_program function", and the C compiler variable "c" is in 
the former category.

There is an important difference between the flags in "binaries" and 
those in "built-in options". What is in "binaries" is used when 
requesting e.g. the compiler search path, while what is in "built-in 
options" is not.  So options like "-m32" are definitely part of 
"binaries", not "built-in options":

     $ gcc --print-multi-os-directory
     ../lib64
     $ gcc -m32 --print-multi-os-directory
     ../lib

Paolo
Jag Raman Feb. 18, 2022, 2:49 p.m. UTC | #5
> On Feb 18, 2022, at 7:13 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On 2/18/22 04:40, Jag Raman wrote:
>>> On Feb 17, 2022, at 7:09 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>> 
>>> On Thu, 17 Feb 2022 at 07:56, Jagannathan Raman <jag.raman@oracle.com> wrote:
>>>> 
>>>> The compiler path that cmake gets from meson is corrupted. It results in
>>>> the following error:
>>>> | -- The C compiler identification is unknown
>>>> | CMake Error at CMakeLists.txt:35 (project):
>>>> | The CMAKE_C_COMPILER:
>>>> | /opt/rh/devtoolset-9/root/bin/cc;-m64;-mcx16
>>>> | is not a full path to an existing compiler tool.
>>>> 
>>>> Explicitly specify the C compiler for cmake to avoid this error
>>> 
>>> This sounds like a bug in Meson. Is there a Meson bug report
>>> we can reference in the commit message here ?
>> Hi Peter,
>> This issue reproduces with the latest meson [1] also.
> 
> 0.60.0 or more recent versions should have a fix, which would do exactly what this patch does: do not define CMAKE_C_COMPILER_LAUNCHER, and place the whole binaries.c variable in CMAKE_C_COMPILER.  What are the contents of the genrated CMakeMesonToolchainFile.cmake and CMakeCache.txt files, without and with your patch?

I’ll checkout what’s going on at my end. But the issue reproduces with
meson 0.61 from what I can tell:
# ../configure --target-list=x86_64-softmmu --enable-debug --enable-vfio-user-server;
The Meson build system
Version: 0.61.2
…
…
| /opt/rh/devtoolset-9/root/usr/bin/cc;-m64;-mcx16

| is not a full path to an existing compiler tool.


Concerning the generated files, I see the following in CMakeMesonToolchainFile.cmake:
Without patch: set(CMAKE_C_COMPILER "/opt/rh/devtoolset-9/root/usr/bin/cc" "-m64" "-mcx16”)
With patch: set(CMAKE_C_COMPILER "cc" "-m64" "-mcx16")

> 
>> I noticed the following about the “binaries” section [2]. The manual
>> says meson could pass the values in this section to find_program [3].
>> As such I’m wondering if it’s OK to set compiler flags in this section
>> because find_program doesn’t seem to accept any compiler flags.
> 
> The full quote of the manual is "These can be used internally by Meson, or by the find_program function", and the C compiler variable "c" is in the former category.
> 
> There is an important difference between the flags in "binaries" and those in "built-in options". What is in "binaries" is used when requesting e.g. the compiler search path, while what is in "built-in options" is not.  So options like "-m32" are definitely part of "binaries", not "built-in options":
> 
>    $ gcc --print-multi-os-directory
>    ../lib64
>    $ gcc -m32 --print-multi-os-directory
>    ../lib

Do you know if the “host_machine” section in cross build
definition file [1] would be any help here?

[1]: https://mesonbuild.com/Cross-compilation.html#machine-entries

--
Jag

> 
> Paolo
Jag Raman Feb. 18, 2022, 3:16 p.m. UTC | #6
> On Feb 18, 2022, at 9:49 AM, Jag Raman <jag.raman@oracle.com> wrote:
> 
> 
> 
>> On Feb 18, 2022, at 7:13 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> 
>> On 2/18/22 04:40, Jag Raman wrote:
>>>> On Feb 17, 2022, at 7:09 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>> 
>>>> On Thu, 17 Feb 2022 at 07:56, Jagannathan Raman <jag.raman@oracle.com> wrote:
>>>>> 
>>>>> The compiler path that cmake gets from meson is corrupted. It results in
>>>>> the following error:
>>>>> | -- The C compiler identification is unknown
>>>>> | CMake Error at CMakeLists.txt:35 (project):
>>>>> | The CMAKE_C_COMPILER:
>>>>> | /opt/rh/devtoolset-9/root/bin/cc;-m64;-mcx16
>>>>> | is not a full path to an existing compiler tool.
>>>>> 
>>>>> Explicitly specify the C compiler for cmake to avoid this error
>>>> 
>>>> This sounds like a bug in Meson. Is there a Meson bug report
>>>> we can reference in the commit message here ?
>>> Hi Peter,
>>> This issue reproduces with the latest meson [1] also.
>> 
>> 0.60.0 or more recent versions should have a fix, which would do exactly what this patch does: do not define CMAKE_C_COMPILER_LAUNCHER, and place the whole binaries.c variable in CMAKE_C_COMPILER. What are the contents of the genrated CMakeMesonToolchainFile.cmake and CMakeCache.txt files, without and with your patch?
> 
> I’ll checkout what’s going on at my end. But the issue reproduces with
> meson 0.61 from what I can tell:
> # ../configure --target-list=x86_64-softmmu --enable-debug --enable-vfio-user-server;
> The Meson build system
> Version: 0.61.2
> …
> …
> | /opt/rh/devtoolset-9/root/usr/bin/cc;-m64;-mcx16
> 
> | is not a full path to an existing compiler tool.
> 
> 
> Concerning the generated files, I see the following in CMakeMesonToolchainFile.cmake:
> Without patch: set(CMAKE_C_COMPILER "/opt/rh/devtoolset-9/root/usr/bin/cc" "-m64" "-mcx16”)
> With patch: set(CMAKE_C_COMPILER "cc" "-m64" "-mcx16")

I’m not sure if you’re interested in the contents of the whole file. But they’re here:

Without patch: https://pastebin.com/sbwtvHy0 (also has error log at the end)
With patch: https://pastebin.com/buRYSp2R

Thank you!
--
Jag

> 
>> 
>>> I noticed the following about the “binaries” section [2]. The manual
>>> says meson could pass the values in this section to find_program [3].
>>> As such I’m wondering if it’s OK to set compiler flags in this section
>>> because find_program doesn’t seem to accept any compiler flags.
>> 
>> The full quote of the manual is "These can be used internally by Meson, or by the find_program function", and the C compiler variable "c" is in the former category.
>> 
>> There is an important difference between the flags in "binaries" and those in "built-in options". What is in "binaries" is used when requesting e.g. the compiler search path, while what is in "built-in options" is not.  So options like "-m32" are definitely part of "binaries", not "built-in options":
>> 
>>   $ gcc --print-multi-os-directory
>>   ../lib64
>>   $ gcc -m32 --print-multi-os-directory
>>   ../lib
> 
> Do you know if the “host_machine” section in cross build
> definition file [1] would be any help here?
> 
> [1]: https://mesonbuild.com/Cross-compilation.html#machine-entries
> 
> --
> Jag
> 
>> 
>> Paolo
Paolo Bonzini Feb. 20, 2022, 8:27 a.m. UTC | #7
On 2/18/22 15:49, Jag Raman wrote:
> 
> Concerning the generated files, I see the following in CMakeMesonToolchainFile.cmake:
> Without patch: set(CMAKE_C_COMPILER "/opt/rh/devtoolset-9/root/usr/bin/cc" "-m64" "-mcx16”)
> With patch: set(CMAKE_C_COMPILER "cc" "-m64" "-mcx16")

I don't understand why it works at all with the latter, but the right solution
could be

set(CMAKE_C_COMPILER "/opt/rh/devtoolset-9/root/usr/bin/cc")
set(CMAKE_C_COMPILER_ARG1 "-m64")
set(CMAKE_C_COMPILER_ARG2 "-mcx16")

Perhaps you can try the following patch to meson (patch it in qemu's build
directory and make sure to use --meson=internal):

diff --git a/mesonbuild/cmake/toolchain.py b/mesonbuild/cmake/toolchain.py
index 316f57cb5..9756864ee 100644
--- a/mesonbuild/cmake/toolchain.py
+++ b/mesonbuild/cmake/toolchain.py
@@ -191,11 +191,14 @@ class CMakeToolchain:
                  continue
  
              if len(exe_list) >= 2 and not self.is_cmdline_option(comp_obj, exe_list[1]):
-                defaults[prefix + 'COMPILER_LAUNCHER'] = [make_abs(exe_list[0])]
+                defaults[f'{prefix}COMPILER_LAUNCHER'] = [make_abs(exe_list[0])]
                  exe_list = exe_list[1:]
  
              exe_list[0] = make_abs(exe_list[0])
-            defaults[prefix + 'COMPILER'] = exe_list
+            defaults[f'{prefix}COMPILER'] = [exe_list[0]]
+            for i in range(1, len(exe_list)):
+                defaults[f'{prefix}COMPILER_ARG{i}'] = [exe_list[i]]
+
              if comp_obj.get_id() == 'clang-cl':
                  defaults['CMAKE_LINKER'] = comp_obj.get_linker_exelist()
  


Thanks,

Paolo
Paolo Bonzini Feb. 20, 2022, 1:27 p.m. UTC | #8
On 2/20/22 09:27, Paolo Bonzini wrote:
> On 2/18/22 15:49, Jag Raman wrote:
>>
>> Concerning the generated files, I see the following in 
>> CMakeMesonToolchainFile.cmake:
>> Without patch: set(CMAKE_C_COMPILER 
>> "/opt/rh/devtoolset-9/root/usr/bin/cc" "-m64" "-mcx16”)
>> With patch: set(CMAKE_C_COMPILER "cc" "-m64" "-mcx16")
> 
> I don't understand why it works at all with the latter, but the right 
> solution
> could be
> 
> set(CMAKE_C_COMPILER "/opt/rh/devtoolset-9/root/usr/bin/cc")
> set(CMAKE_C_COMPILER_ARG1 "-m64")
> set(CMAKE_C_COMPILER_ARG2 "-mcx16")

Anyhow it seems to be a cmake bug, because what QEMU/Meson are doing is 
exactly what is in the manual at 
https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER.html#variable:CMAKE_%3CLANG%3E_COMPILER:

   Note: Options that are required to make the compiler work correctly
   can be included as items in a list; they can not be changed.

   #set within user supplied toolchain file
   set(CMAKE_C_COMPILER /full/path/to/qcc --arg1 --arg2)

Paolo
Jag Raman Feb. 22, 2022, 7:05 p.m. UTC | #9
> On Feb 20, 2022, at 3:27 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On 2/18/22 15:49, Jag Raman wrote:
>> Concerning the generated files, I see the following in CMakeMesonToolchainFile.cmake:
>> Without patch: set(CMAKE_C_COMPILER "/opt/rh/devtoolset-9/root/usr/bin/cc" "-m64" "-mcx16”)
>> With patch: set(CMAKE_C_COMPILER "cc" "-m64" "-mcx16")
> 
> I don't understand why it works at all with the latter, but the right solution
> could be
> 
> set(CMAKE_C_COMPILER "/opt/rh/devtoolset-9/root/usr/bin/cc")
> set(CMAKE_C_COMPILER_ARG1 "-m64")
> set(CMAKE_C_COMPILER_ARG2 "-mcx16")
> 
> Perhaps you can try the following patch to meson (patch it in qemu's build
> directory and make sure to use --meson=internal):
> 
> diff --git a/mesonbuild/cmake/toolchain.py b/mesonbuild/cmake/toolchain.py
> index 316f57cb5..9756864ee 100644
> --- a/mesonbuild/cmake/toolchain.py
> +++ b/mesonbuild/cmake/toolchain.py
> @@ -191,11 +191,14 @@ class CMakeToolchain:
>                 continue
>              if len(exe_list) >= 2 and not self.is_cmdline_option(comp_obj, exe_list[1]):
> -                defaults[prefix + 'COMPILER_LAUNCHER'] = [make_abs(exe_list[0])]
> +                defaults[f'{prefix}COMPILER_LAUNCHER'] = [make_abs(exe_list[0])]
>                 exe_list = exe_list[1:]
>              exe_list[0] = make_abs(exe_list[0])
> -            defaults[prefix + 'COMPILER'] = exe_list
> +            defaults[f'{prefix}COMPILER'] = [exe_list[0]]
> +            for i in range(1, len(exe_list)):
> +                defaults[f'{prefix}COMPILER_ARG{i}'] = [exe_list[i]]
> +
>             if comp_obj.get_id() == 'clang-cl':
>                 defaults['CMAKE_LINKER'] = comp_obj.get_linker_exelist()

This fix works at my end.

Thank you!
--
Jag

> 
> 
> Thanks,
> 
> Paolo
Paolo Bonzini Feb. 24, 2022, 5:52 p.m. UTC | #10
On 2/22/22 20:05, Jag Raman wrote:
>> -            defaults[prefix + 'COMPILER'] = exe_list
>> +            defaults[f'{prefix}COMPILER'] = [exe_list[0]]
>> +            for i in range(1, len(exe_list)):
>> +                defaults[f'{prefix}COMPILER_ARG{i}'] = [exe_list[i]]
>> +
>>              if comp_obj.get_id() == 'clang-cl':
>>                  defaults['CMAKE_LINKER'] = comp_obj.get_linker_exelist()
> This fix works at my end.

Would you please check that -m64 and -mcx16 are passed indeed to the 
compiler?

Paolo
Jag Raman Feb. 25, 2022, 4:03 a.m. UTC | #11
> On Feb 24, 2022, at 12:52 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On 2/22/22 20:05, Jag Raman wrote:
>>> -            defaults[prefix + 'COMPILER'] = exe_list
>>> +            defaults[f'{prefix}COMPILER'] = [exe_list[0]]
>>> +            for i in range(1, len(exe_list)):
>>> +                defaults[f'{prefix}COMPILER_ARG{i}'] = [exe_list[i]]
>>> +
>>>             if comp_obj.get_id() == 'clang-cl':
>>>                 defaults['CMAKE_LINKER'] = comp_obj.get_linker_exelist()
>> This fix works at my end.
> 
> Would you please check that -m64 and -mcx16 are passed indeed to the compiler?

Hi Paolo,

Yes, I’m able to see that -m64 and -mcx16 are passed to the compiler.

# cat ./subprojects/libvfio-user/__CMake_build/CMakeMesonToolchainFile.cmake
…
set(CMAKE_C_COMPILER "/opt/rh/devtoolset-9/root/usr/bin/cc")
set(CMAKE_C_COMPILER_ARG1 "-m64")
set(CMAKE_C_COMPILER_ARG2 "-mcx16")
…

Full log here: https://pastebin.com/PEwNSWMn

Thank you!
--
Jag

> 
> Paolo
Paolo Bonzini Feb. 28, 2022, 6:12 p.m. UTC | #12
On 2/25/22 05:03, Jag Raman wrote:
> 
> 
>> On Feb 24, 2022, at 12:52 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> On 2/22/22 20:05, Jag Raman wrote:
>>>> -            defaults[prefix + 'COMPILER'] = exe_list
>>>> +            defaults[f'{prefix}COMPILER'] = [exe_list[0]]
>>>> +            for i in range(1, len(exe_list)):
>>>> +                defaults[f'{prefix}COMPILER_ARG{i}'] = [exe_list[i]]
>>>> +
>>>>              if comp_obj.get_id() == 'clang-cl':
>>>>                  defaults['CMAKE_LINKER'] = comp_obj.get_linker_exelist()
>>> This fix works at my end.
>>
>> Would you please check that -m64 and -mcx16 are passed indeed to the compiler?
> 
> Hi Paolo,
> 
> Yes, I’m able to see that -m64 and -mcx16 are passed to the compiler.
> 
> # cat ./subprojects/libvfio-user/__CMake_build/CMakeMesonToolchainFile.cmake
> …
> set(CMAKE_C_COMPILER "/opt/rh/devtoolset-9/root/usr/bin/cc")
> set(CMAKE_C_COMPILER_ARG1 "-m64")
> set(CMAKE_C_COMPILER_ARG2 "-mcx16")
> …

I reproduced this with CMake 3.17.x and it's fixed by 3.19.x.  I'll send 
the fix to Meson, but for now I recommend requiring a newer CMake and 
just dropping this patch.

Paolo
Jag Raman Feb. 28, 2022, 7:55 p.m. UTC | #13
> On Feb 28, 2022, at 1:12 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On 2/25/22 05:03, Jag Raman wrote:
>>> On Feb 24, 2022, at 12:52 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> 
>>> On 2/22/22 20:05, Jag Raman wrote:
>>>>> -            defaults[prefix + 'COMPILER'] = exe_list
>>>>> +            defaults[f'{prefix}COMPILER'] = [exe_list[0]]
>>>>> +            for i in range(1, len(exe_list)):
>>>>> +                defaults[f'{prefix}COMPILER_ARG{i}'] = [exe_list[i]]
>>>>> +
>>>>>             if comp_obj.get_id() == 'clang-cl':
>>>>>                 defaults['CMAKE_LINKER'] = comp_obj.get_linker_exelist()
>>>> This fix works at my end.
>>> 
>>> Would you please check that -m64 and -mcx16 are passed indeed to the compiler?
>> Hi Paolo,
>> Yes, I’m able to see that -m64 and -mcx16 are passed to the compiler.
>> # cat ./subprojects/libvfio-user/__CMake_build/CMakeMesonToolchainFile.cmake
>> …
>> set(CMAKE_C_COMPILER "/opt/rh/devtoolset-9/root/usr/bin/cc")
>> set(CMAKE_C_COMPILER_ARG1 "-m64")
>> set(CMAKE_C_COMPILER_ARG2 "-mcx16")
>> …
> 
> I reproduced this with CMake 3.17.x and it's fixed by 3.19.x.  I'll send the fix to Meson, but for now I recommend requiring a newer CMake and just dropping this patch.

OK, got it.

Thank you!
--
Jag

> 
> Paolo
diff mbox series

Patch

diff --git a/configure b/configure
index 3a29eff5cc..9a326eda1e 100755
--- a/configure
+++ b/configure
@@ -3726,6 +3726,8 @@  if test "$skip_meson" = no; then
   echo "cpp_args = [$(meson_quote $CXXFLAGS $EXTRA_CXXFLAGS)]" >> $cross
   echo "c_link_args = [$(meson_quote $CFLAGS $LDFLAGS $EXTRA_CFLAGS $EXTRA_LDFLAGS)]" >> $cross
   echo "cpp_link_args = [$(meson_quote $CXXFLAGS $LDFLAGS $EXTRA_CXXFLAGS $EXTRA_LDFLAGS)]" >> $cross
+  echo "[cmake]" >> $cross
+  echo "CMAKE_C_COMPILER = [$(meson_quote $cc $CPU_CFLAGS)]" >> $cross
   echo "[binaries]" >> $cross
   echo "c = [$(meson_quote $cc $CPU_CFLAGS)]" >> $cross
   test -n "$cxx" && echo "cpp = [$(meson_quote $cxx $CPU_CFLAGS)]" >> $cross