Check for working C compiler: C:/HighTec/TriCore_v3_4_7_3/bin/tricore-gcc.exe - broken

[himansu2906]

Hello All,

I am new to conan and currently trying to create library package and I am using tricore-gcc compiler.

whenever I am trying to create package it is giving following error

but if I am building this library with cmake command, it is building perfectly fine.

I am not able to set cross compile setting for tricore with Conan.

if anyone can guild how can cross compile with tricore-gcc with Conan.

[memsharded]

Hi @himansu2906

Can you please try sharing your conanfile.py and your CMakeLists.txt? Another thing to try is to start with a "hello world" simple package, created with conan new hello/0.1 -m=cmake_lib, and see if you are able to build with that compiler. It is possible that such compiler has something specific (like gcc 3.4 is really old and the Conan toolchain is producing some incompatible flag, because it is designed and tested with more modern compilers.

Also, please, do not share the output as images, but copy and paste the whole output as text (Github has utilities to hide it, so it doesn't clutter the whole issue), not trimming it, but the whole command output. Thanks!

[memsharded]

Ok, I start to understand where the issues could be. Let me explain them:

• First, the toolchain is not to be written in the file. The lines:

  set (CMAKE_TOOLCHAIN_FILE=~/tricore-gcc.cmake)
  set (CMAKE_C_COMPILER "C:/HighTec/TriCore_v3_4_7_3/bin/tricore-gcc.exe")
  

  Shoudn't be in your CMakeLists.txt. This is not related to Conan, but good CMake practices
• Then, if the tricore-gcc.cmake toolchain is necessary to build, then you can pass it your profile, defining it as a conf tools.cmake.cmaketoolchain:user_toolchain=tricore-gcc.cmake file. The idea is that it is something external to the build files and the packages. Some builds/binaries will be using that profile, and some builds can be using a different compilers, but the configuration for compiler, etc, should not be hardcoded in recipes or CMakeLists.txt, but external, as configuration (in this case, Conan profile files is the recommended way)
• Finally, the information you are putting in package_info() is useless. That is information for the consumers, about your own package, not about setting the environment for yourself.

[memsharded]

As a general recommendation, if you haven't yet I would recommended learning first a bit of the basics. Creating simple Conan packages, for different variants, but for mainstream, native compilers like Visual Studio or regular gcc. Reuse those packages. Use profile files to define configurations, etc. Then when you grasp the basics, you can then start more advanced stuff, as defining other non mainstream compilers, etc. If you like videos, then this free course might help a bit: https://academy.jfrog.com/path/conan

[memsharded]

Is it possible to get this tricore-gcc.exe compiler from somewhere to be able to test it?

A couple of further notes:

• generators = "cmake_find_package_multi", "gcc", "txt" are useles, you shouldn't be using them here. If anything, try with the new CMakeDeps, when you have dependencies (not this case).
• Your package_info() can be removed, according to the above comments.
• Need to confirm if you removed the definition of toolchain from your CMakeLists.txt or not.

[himansu2906]

@memsharded : do you have any update for me on the issue?

[memsharded]

I am trying to reproduce this, but due to not knowing about this specific compiler, it is being very complex.

I would need to reproduce, first the basic CMake example, without Conan:

• A very simple, the very minimal CMakeLists.txt that builds the very minimal executable from a very simple source code.
• The exact command line that you are using with CMake to build it.
• The full output of the build (as text, not image)
• If the build and the command line require any other file, like a toolchain file, that file is also needed (as reduced and minimal as possible)

Then, for Conan, I would need specification of the full profile, for example:

• os (of the target system, is it Linux?)
• arch (the architecture of the target system)

[memsharded]

Hi @himansu2906

I have managed to make it work, indeed the toolchain was the piece that I was missing. Find attached a working example: tricore-example.zip

Need to:

• In the tricore profile, need to specify the full path to the tricore-gcc.cmake toolchain instead of tools.cmake.cmaketoolchain:user_toolchain=["<path-to-toolchain>/tricore-gcc.cmake"] (there could be ways to make this relative, using jinja syntax, but lets keep it simple.
• Have tricore tools and mingw in the path. I hadn't them so I also used a [buildenv] section in the profile to add it to the path with the PATH=+(path)<path-to-tricore> syntax, and also I did the same to put Mingw in the path. If you have them, no need to do this
• conan create . -pr=tricore

That should run the creation of a package (a library), and also the "consuming" and testing of that library by an executable application inside the test_package folder.

The changes I had to to are:

• I added "3.4" to the possible settings.yml (this file is in the Conan cache, in your <userhome>/.conan (this file can be managed in production with conan config install, so it is not necessary to do this manual change)
• The piece that the tricore compiler was not liking that Conan was defining in the conan_toolchain.cmake was the flags. I discarded them from the conan toolchain with:

      def generate(self):
        tc = CMakeToolchain(self)
        tc.blocks.remove("arch_flags")
        tc.generate()
  

• I added the generators = "VirtualBuildEnv" in the recipe, to make sure the environment (from my [buildenv] section) is injected correctly.
• As it is not possible to run the binary in Windows, I just check in test_package/conanfile.py the existence of the file:

  def test(self):
        # we cannot run it
        cmd = os.path.join(self.cpp.build.bindirs[0], "example.elf")
        # Just check its existence
        assert os.path.isfile(cmd)
  

Just a note, the profile that is being passed with -pr=tricore should be the "host" profile (the one the binary will run). As it has the ELF extension, maybe it shouldnt be Windows, but Linux?

Please try it and let me know. Thanks!

[himansu2906]

Hi @memsharded,

do you have any update on above question regarding no ".a files" being generated in package folder.

[memsharded]

yes, the build executed by the build() method happens in a "build" folder in the cache. The package() method has the responsibility of copying the desired package artifacts from the "build" folder to the "package" folder. This can be done in different ways:

• With something like CMake() install method cmake.install() in the package() method, if the CMakeLists.txt contains correct install instructions
• With from conan.tools.files import copy and explicit copy(self, ...) calls inside package() method.

[maitrey]

Hello @memsharded , Sorry for hijacking your issue. We use the same compiler , Do you see any potential issues if we define the profiles like this: `target_host=C:/hightec_ifx/bin/tricore standalone_toolchain=C:/hightec_ifx/ cc_compiler=tricore-gcc

[settings] os=RTAOS arch=tc39xx arch_build=x86_64 compiler=tricore-gcc build_type=Release

[env] PATH=[$standalone_toolchain/bin] CC=$target_host-gcc.exe LD=$target_host-gcc.exe AR=$target_host-ar.exe AS=$target_host-as RANLIB=$target_host-ranlib STRIP=$target_host-strip CFLAGS=-O2 -g -W -Wall -Wcast-align -Wcast-qual -Wmissing-noreturn -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wfloat-equal -Wredundant-decls -Wstrict-prototypes -Wundef -Wunsuffixed-float-constants -mversion-info -Wmissing-declarations -Winline -Werror-implicit-function-declaration -Wno-bad-function-cast -Wsign-compare -finline -mcpu=tc39xx -maligned-data-sections -fmessage-length=0 -fno-builtin-memcpy -fno-builtin-memcmp -fno-builtin-memset -fno-builtin-strlen -fno-common LDFLAGS=-lgcc -mcpu=tc39xx -mfixed-sda -Wl,-r -nostdlib -Wl,--cref -Wl,-no-demangle,-demangle=none -Wl,--extmap=a -ferror-numbers

[conf] tools.cmake.cmaketoolchain:generator=MinGW Makefiles`

One more additional question would be : How are profiles handling absolute and relative linking ? Thanks in advance for answering my question. Its probably even a cmake question as LDFLAGS is an environment variable in cmake.

[memsharded]

I don't see any apparent issue, if it works for you, besides using the legacy [env] management instead of the new integrations, that you should use to be 2.0 ready:

• New environment management via [buildenv] and VirtualBuildEnv
• New passing of flags to new generators like CMakeToolchain, there is new conf like tools.build:cflags. In this case if only using this compiler, the environment [buildenv] could work.

Check https://docs.conan.io/en/latest/reference/conanfile/tools.html for more info

[maitrey]

It so far works for me . Actually sometime back in another issue, I requested to update the documentation for build env and runtime env which was mentioned as new feature in 2.0. See here: https://github.com/conan-io/conan/issues/11499#issuecomment-1165447155 . And I still cannot find it. Perhaps I am missing checking , could you please be kind to forward me the exact link ?

[memsharded]

Yes, we are going to add some more docs for exactly this in 1.52 release soon.

[maitrey]

Sorry to bother you again : One more additional question would be : How are profiles handling absolute and relative linking ? Thanks in advance for answering my question. Its probably even a cmake question as LDFLAGS is an environment variable in cmake. We have both absolute linking and relative linking as we have execute in place microcontroller.

[memsharded]

How are profiles handling absolute and relative linking ? Thanks in advance for answering my question. Its probably even a cmake question as LDFLAGS is an environment variable in cmake. We have both absolute linking and relative linking as we have execute in place microcontroller.

This is not something handled by profiles, it depends on compiler, build systems, etc. Note that CMake does not necessarily always listen to env-vars (maybe only with Makefiles generators?). You can define user conf if you need it, or maybe it is something that you want to create custom settings to model it, and then pass that setting to your build scripts. But Conan doesn't have anything built-in for it.