[question] build_type set to Release, but binary is not stripped

[diogomatos3]

What is your question?

Hello community,

When using build_type as release for build and host profile, for the same time, the generated binaries are not stripped.

On build logs, during configure step: -- files: -- Compiler : /home/user/.conan/data/armv8_linux_gcc8/0.12.0/aos/dev/package/0b9087fa2e697f5753918ed600436dc0f93f8994/armv8_linux_gcc8/usr/bin/aarch64-linux-gnu-g++-8 -- C flags: -fdiagnostics-color=auto -Wextra -Wconversion -Wall -Wcast-align -Wsign-conversion -Wshadow -Wformat-security -Wstack-protector -Wstringop-overflow -g -g -- C++ flags: -fdiagnostics-color=auto -Wextra -Wconversion -Wall -Wcast-align -Wsign-conversion -Wshadow -Wformat-security -Wstack-protector -Wstringop-overflow -g -std=c++11

I also double checked some cmake variables

- CMAKE_CXX_FLAGS_DEBUG: -g -O0 -D_DEBUG -- CMAKE_CXX_FLAGS_RELEASE: -O2 -DNDEBUG -D_FORTIFY_SOURCE=2 -- CMAKE_C_FLAGS_DEBUG: -g -O0 -D_DEBUG -- CMAKE_C_FLAGS_RELEASE: -O2 -DNDEBUG -D_FORTIFY_SOURCE=2 -- CMAKE_C_FLAGS: -fdiagnostics-color=auto -Wextra -Wconversion -Wall -Wcast-align -Wsign-conversion -Wshadow -Wformat-security -Wstack-protector -Wstringop-overflow

But then, checking the binary, with file command parse: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=98477e8589febcda8e1434c77ec61585ed30a1cd, for GNU/Linux 3.7.0, not stripped

Shouldn't CMAKE_C_FLAGS_RELEASE be append to CMAKE_C_FLAGS? On my setup, it seems build_type release request is ignored. Any recommendation, where to check for the issue?

Thanks in advance!

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @diogomatos3

Thanks for your question.

To better understand your issue, it would be necessary to know a bit more:

• Conan version
• Platform details
• What build system integrations you are using, the way build_type is translated to compile flags depends on the build system. The best would be to have a fully reproducible recipe that we can use. For example conan new cmake_lib -d name=mypkg -d version=0.1 produces a fully functional package recipe. If you provide your own recipe, make sure to add the CMakeLists.txt and all the necessary files to reproduce.
• If you can simplify some of the aspects, for example it looks like that you are cross-compiling, but is the issue still the same with a native build in Linux?
• If you are providing any special profiles, external toolchain files, or something like that, please add the details too.

Thanks for the feedback!

[diogomatos3]

Hi @diogomatos3

Thanks for your question.

To better understand your issue, it would be necessary to know a bit more:

* Conan version

* Platform details

* What build system integrations you are using, the way `build_type` is translated to compile flags depends on the build system. The best would be to have a fully reproducible recipe that we can use. For example `conan new cmake_lib -d name=mypkg -d version=0.1` produces a fully functional package recipe. If you provide your own recipe, make sure to add the `CMakeLists.txt` and all the necessary files to reproduce.

* If you can simplify some of the aspects, for example it looks like that you are cross-compiling, but is the issue still the same with a native build in Linux?

* If you are providing any special profiles, external toolchain files, or something like that, please add the details too.

Thanks for the feedback!

Hi @memsharded

• Conan version: 1.56.0
• Platform details: armv8_linux_gcc8 -- Conan setting CPP STANDARD: 17 WITH EXTENSIONS OFF -- Conan: Compiler GCC>=5, checking major version 8.4 -- Conan: Checking correct version: 8.4 -- Conan: C++ stdlib: libstdc++11

Conan profile is like this: [settings] arch=armv8 build_type=Release compiler=gcc compiler.cppstd=17 compiler.libcxx=libstdc++11 compiler.version=8.4 os=Linux

[options]

[env]

[build_requires] armv8_linux_gcc8/0.12.0@app/dev

• If you are providing any special profiles, external toolchain files, or something like that, please add the details too.
  • Indeed there is an external toolchain, in use... which I do not know details

I will need more time to reproduce, the issue on a "smaller example". But that is a good way to go. Restart smaller and validate is build_type equal to release reproduce a stripped file.

Thanks for the hints.

[memsharded]

Conan version: 1.56.0

Please note that the recommended production version nowadays is Conan 2.X, released like 17 months ago.

I will need more time to reproduce, the issue on a "smaller example". But that is a good way to go. Restart smaller and validate is build_type equal to release reproduce a stripped file.

The more critical piece of knowledge would be the integrations used. Even in Conan 1.X, the only recommended one is CMakeToolchain for newer projects (together with the from conan.tools.cmake import CMake helper).

Also it is possible that the armv8_linux_gcc8/0.12.0@app/dev package contains itself toolchains that it is injecting into the packages that use it as build-requires. Conan does very little regarding the translation of build_type to compiler flags, and in some build systems as CMake, it does basically nothing, just pass the build_type to CMake, and CMake will manage. This is why it is important to know the build system integration details, together with other possible toolchain issues. I suspect that this is not very on the Conan side, but I am willing to help to try to identify the issue.

[diogomatos3]

Hi @memsharded ,

Apologies for the late reply. Regarding, the current version in use. We are planning to do an intermediate upgrade. First to latest conan 1, then to conan 2. The reason is that we depend on packages that are maintained, on conan 1.56. And the same packages are out of our control. So, meantime we will update to 1.67. Then to 2.x.

Regarding the issue itself. You were correct. armv8_linux_gcc8/0.12.0@app/dev has a toolchain file that set the compiler flags and regarding release is missing '-s'.

Thanks for the hint.

[memsharded]

Apologies for the late reply.

No problem! We also often can't follow up on all the open tickets, so if we are also late in our replies, don't hesitate to ping to resurface the tickets.

Regarding, the current version in use. We are planning to do an intermediate upgrade. First to latest conan 1, then to conan 2. The reason is that we depend on packages that are maintained, on conan 1.56. And the same packages are out of our control. So, meantime we will update to 1.67. Then to 2.x.

Yes, that totally makes sense, first an update to latest Conan 1.X moving gradually things like the build system integrations to the recommended ones (like CMakeToolchain, etc), the environment management too (using [buildenv] and VirtualBuildEnv instead of [env]), etc.

Regarding the issue itself. You were correct. armv8_linux_gcc8/0.12.0@app/dev has a toolchain file that set the compiler flags and regarding release is missing '-s'.

Happy that you identified the issue.

Thanks for the hint.

Always happy to help, don't hesitate to create new tickets for any further question. Thanks for the feedback!