[bug] invalid libcxx options with CMakeToolchain on QNX if CC has been overridden about conan HOT 3 OPEN

Hi @dsche - thank you for reporting this.

Please bear in mind that Conan 1.x is no longer actively maintained, although we would only look at critical bug fixes. It would be good to see if this also happens using the CMakeDeps generator, rather than the legacy unsupported ones.

On the other hand, Conan works under the assumption that the qcc frontend is invoked, as recommended by the QNX SDK documentation: https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.utilities/topic/g/gcc.html - that does not recommend invoking the gcc executables directly. My recommendation would be to follow the recommended approach in the documentation, and invoke qcc with the relevant -V to specify your desired target.

if you really need to completely bypass the qcc frontend, assuming you take care of all the things that the frontend would otherwise take care of for you, you could perhaps try changing compiler=qcc to compiler=gcc in the profile, as that more accurately reflects that's happening (the os is still Neutrino).

from conan.

Hi @jcar87 , thanks for the quick reply! Some comments on that:

• The issue persists also in Conan 2.x.
• It is possible to circumvent it by hacking the recipe eg via cmake.blocks.remove("libcxx"). It might do something awful to our build, but for now it seems to work.
• AFAIK switching the compiler would trigger the change to all the dependencies, which is not what we want

from conan.

I'm not sure I would consider this a bug, since we are abiding to the QNX documentation recommendations, and by expressing qcc as the compiler, then I think it makes sense for Conan to assume that it is actually the qcc frontend rather than gcc.

Is there any specific reason why gcc -V[targetname] is not a valid solution, rather than resorting to invoking the gcc frontend directly? There may be a case to raise an issue with QNX support.

from conan.