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