[question] Profiles and setting additional tools with the compiler

[maitrey]

Dear Conan Folks,

I have this use-case: I am generating the elf files and need to use some tools from the compiler for further processing of the elf files. In profiles I specify it like this: target_host=C:/Tricore/v4.7.3/bin/ppc-vle [env] OBJVARED=$target_host-vared.exe

But I am unable to see this variable in CMakeCache.txt and unable to use it. Could anyone please help?

• [x] I've read the CONTRIBUTING guide.

[memsharded]

Hi @maitrey

CMake does not listen to most env-vars. It will just use CC/CXX and a few others, but in general env-vars are not a way to pass information to CMake, and they will not end in the CMakeCache.txt.

If you want, you need to pass in your recipes the info, using something like CMakeToolchain.variables or CMakeToolchain.cache_variables.

[maitrey]

Hi @memsharded , Thanks for answering. One more question if I may: I have component packages but I have to link them in the Project Package with additional linker flags. Linker flags have to be given in the order: ld -Wl,--start-group -Wl,--end-group -o elf file. What is the best way to achieve this?

[memsharded]

I am not fully sure what you mean, but maybe adding self.cpp_info.sharedlinkflags = ["....."] and self.cpp_info.exelinkflags = ["....."] defined in package_info() will propagate those flags to the consumers of that package.

[maitrey]

Sorry for not being explicit. I have components in their own packages(10 components) which generate libraries. These libraries I am consuming in another package along with other libraries generated in this package. But the linking should be done in this way: -Wl, --start-group ComponentA/lib ComponentB/lib ComponentC/lib ComponentD/lib ComponentE/.a ComponentF/.a ComponentG/.a Project/ComponentX/.obj Project/ComponentY/.obj -Wl, --end-group self.cpp_info.sharedlinkflags/self.cpp_info.exelinkflags can be added generally for extending the linker options of the package. But when the linking has to be done in groups, What is the best way to achieve the linking order? Not having the order leads to undefined reference.

[jcar87]

Hi @maitrey -

I'm assuming that due to the use of --start-group and --end-group these are static libraries, correct? Are there any circular dependencies between the static libraries? That's typically the reason one would use the group flags during linking.

Provided there are no circular dependencies between the static libraries, and each component is on a separate package (as you describe), and the package_info() correctly populating the cpp_info.libs attribute, the link order as generated by Conan should already be correct, without the need for --start-group or --end-group - is this not the case?

[maitrey]

Hi @jcar87 , These are 3rd party deliverables. We donot know if there are circular dependencies, without start group end group it doesnot work .

[maitrey]

I am not fully sure what you mean, but maybe adding self.cpp_info.sharedlinkflags = ["....."] and self.cpp_info.exelinkflags = ["....."] defined in package_info() will propagate those flags to the consumers of that package.

Hi @memsharded , The component packages deliver objects .Could I use this self.cpp_info.objects for object libraries and for the consuming package , ${mypkg_OBJECTS_RELEASE} ?

[maitrey]

This issue is also solved as of now. Closing this issue.