Created attachment 462676 [details, diff] Configure cmake to use 'Gentoo' build type I open a new bug for this. @Steffen Hau : It's the debian info dir witch make me think it was related. So, if it's a debug release, why use it for a normal release. I don't know what is better between 'RelWithDebInfo' and 'Debug', but for a normal build, why we should have the debug stuff in the installed files ? @candrews : Yes, there is no 'Gentoo' release defined in Kodi, it came with the cmake eclass. -DWITH_CPU, -DCMAKE_INSTALL_PREFIX, -DDEPENDS_PATH, and -DNATIVEPREFIX are needed if you define your own build. I think it's better to use it as soon as possible, it's like 'emake' instead of 'make' ...etc. Detail of what I've understood : WITH_CPU: CMake can define the arch and some other thing with it (ex linux use 'i386' for .so file instead of 'x32' with bsd) DEPENDS_PATH: Path to the 'depends' folder for the target architecture. I think it is used for crossbuilding. NATIVEPREFIX: Same as previous but for tools needed on the build host. As I say in my previous comment, the cmake eclass add this 'Gentoo' build type and discard the 'Release' build type. The eclass add some host specific info, for me, here is what it's added : -- <<< Gentoo configuration >>> Build type Gentoo Install path /usr Compiler flags: C -march=native -O2 -pipe C++ -march=native -O2 -pipe -std=c++11 Linker flags: Executable -Wl,-O1 -Wl,--as-needed -fuse-ld=gold Module -Wl,-O1 -Wl,--as-needed -fuse-ld=gold -fuse-ld=gold Shared -Wl,-O1 -Wl,--as-needed -fuse-ld=gold -fuse-ld=gold The linker stuff is handled here so I think It can solve the issue with the gold linker.
Found this in the environment file of the ffmpeg bug : SET (CMAKE_SYSTEM_PROCESSOR "${CHOST%%-*}") So : -DWITH_CPU="${CHOST%%-*}" Maybe this variable is available for configure phase : -DWITH_CPU=$CMAKE_SYSTEM_PROCESSOR (?)
(In reply to Marc Perrudin from comment #0) > Created attachment 462676 [details, diff] [details, diff] > Configure cmake to use 'Gentoo' build type > > I open a new bug for this. > > @Steffen Hau : It's the debian info dir witch make me think it was related. > So, if it's a debug release, why use it for a normal release. I don't know > what is better between 'RelWithDebInfo' and 'Debug', but for a normal > build, why we should have the debug stuff in the installed files ? I'm not aware of any debian info dir.. But as I already said: if you do not use RelWithDebInfo kodi's build system would strip binaries. This makes it impossible to preserve any debugging information with FEATURE splitdebug. If you haven't set the feature then emerge will strip the binaries. > As I say in my previous comment, the cmake eclass add this 'Gentoo' build > type and discard the 'Release' build type. The eclass add some host specific > info, for me, here is what it's added : > -- <<< Gentoo configuration >>> > Build type Gentoo > Install path /usr > Compiler flags: > C -march=native -O2 -pipe > C++ -march=native -O2 -pipe -std=c++11 > Linker flags: > Executable -Wl,-O1 -Wl,--as-needed -fuse-ld=gold > Module -Wl,-O1 -Wl,--as-needed -fuse-ld=gold -fuse-ld=gold > Shared -Wl,-O1 -Wl,--as-needed -fuse-ld=gold -fuse-ld=gold > > The linker stuff is handled here so I think It can solve the issue with the > gold linker. You also didn't get my point: candrews unconditionally sets ENABLE_LDGOLD to OFF, which causes kodi's cmake to ignore LDGOLD.cmake totally. I've installed binutils with EXTRA_ECONF="--enable-gold=default", so my linker is already ld.gold. Kodi dev's have done two things: 1) they force ld.gold if it's available and 2) also pass additional switches to CXX and LDFLAGS in order to speed up linking. While I agree that 1 may be no option for gentoo, 2) should be available if a user has ld.gold as the default linker. This could simply be achieved by making ENABLE_LDGOLD=OFF dependend on tc-ld-is-gold. Thats all.
(In reply to Steffen Hau from comment #2) > I'm not aware of any debian info dir.. But as I already said: if you do not > use RelWithDebInfo kodi's build system would strip binaries. This makes it > impossible to preserve any debugging information with FEATURE splitdebug. If > you haven't set the feature then emerge will strip the binaries. > I understood it's needed for a debug release, but what I don't understand is why it's needed for a normal build. Most (I didn't checked all of them !) of the package witch use cmake use this Gentoo build type for building package. > You also didn't get my point: candrews unconditionally sets ENABLE_LDGOLD to > OFF, which causes kodi's cmake to ignore LDGOLD.cmake totally. I've > installed binutils with EXTRA_ECONF="--enable-gold=default", so my linker is > already ld.gold. Kodi dev's have done two things: 1) they force ld.gold if > it's available and 2) also pass additional switches to CXX and LDFLAGS in > order to speed up linking. While I agree that 1 may be no option for gentoo, > 2) should be available if a user has ld.gold as the default linker. This > could simply be achieved by making ENABLE_LDGOLD=OFF dependend on > tc-ld-is-gold. Thats all. It could, but why not let the cmake eclass do its job and configure the linker ? It seeems to already do what's you want.
Strictly speaking, CMAKE_BUILD_TYPE=Gentoo is deprecated.
(In reply to Michał Górny from comment #4) > Strictly speaking, CMAKE_BUILD_TYPE=Gentoo is deprecated. Yes, it's useless. It's the default value. Kodi make use of "if (CMAKE_BUILD_TYPE STREQUAL xxx)", so if CMAKE_BUILD_TYPE is set to something else, it happens what is expained in the eclass : # @ECLASS-VARIABLE: CMAKE_BUILD_TYPE # @DESCRIPTION: # Set to override default CMAKE_BUILD_TYPE. Only useful for packages # known to make use of "if (CMAKE_BUILD_TYPE MATCHES xxx)". # If about to be set - needs to be set before invoking cmake-utils_src_configure. # You usualy do *NOT* want nor need to set it as it pulls CMake default build-type # specific compiler flags overriding make.conf. : ${CMAKE_BUILD_TYPE:=Gentoo} Does this mean it should not be defined at all, even for 'DEBUG' or 'RelWithDebInfo' ?
It means that we're going to change the default eventually. Possibly in the next EAPI. Most likely to RelWithDebInfo.
(In reply to Michał Górny from comment #6) > It means that we're going to change the default eventually. Possibly in the > next EAPI. Most likely to RelWithDebInfo. I hope this next eapi will be released soon, so I can understand something. In the meantime, I keep my own ebuild for epai6 and without all these debug stuffs. This bug should be closed until the next eapi.
(In reply to Marc Perrudin from comment #7) > (In reply to Michał Górny from comment #6) > > It means that we're going to change the default eventually. Possibly in the > > next EAPI. Most likely to RelWithDebInfo. > > I hope this next eapi will be released soon, so I can understand something. > In the meantime, I keep my own ebuild for epai6 and without all these debug > stuffs. What kind of debug stuffs? The eclass should wipe the most harmful stuff out, then it's the developer responsibility for the build type not to interfere further.
(In reply to Michał Górny from comment #8) > What kind of debug stuffs? The eclass should wipe the most harmful stuff > out, then it's the developer responsibility for the build type not to > interfere further. It's what I don't understand. There is some debug handling for the Gentoo build type witch handle this. With another build type, I see nothing so if it's a release with debug info, cmake add debug info. But I don't search further because the eclass say 'You usualy do *NOT* want nor need to set it as it pulls CMake default build-type specific compiler flags overriding make.conf.' and in fact you should use 'RelWithDebInfo' because of the further eapi version, there is no way for me to have this future eclass and understand what you talk about. The debug handling part of the cmake eclass : # @SEE CMAKE_BUILD_TYPE if [[ ${CMAKE_BUILD_TYPE} = Gentoo ]]; then # Handle release builds if ! has debug ${IUSE//+} || ! use debug; then local CPPFLAGS=${CPPFLAGS} append-cppflags -DNDEBUG fi fi
Resolved in the 17.3 version bump: https://github.com/gentoo/gentoo/commit/cd9b7029677f349145e3834c154245a45ac6a598
