/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: error: /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/../../../../lib64/libcrossguid.a(guid.o): requires dynamic R_X86_64_PC32 reloc against '_ZNSolsEi' which may overflow at runtime; recompile with -fPIC Reproducible: Always
See https://github.com/xbmc/xbmc/blob/c4da9e834abc7e4a208e818e7390d8d1283f6ee7/cmake/modules/LDGOLD.cmake -DNABLE_LDGOLD=OFF needs to always be passed to cmake so the default linker is always used. On Gentoo, the default linker is controlled by 'binutils-config' see https://wiki.gentoo.org/wiki/Gold therefore, no use flag is needed and -DNABLE_LDGOLD=OFF will always do the right thing.
https://github.com/gentoo/gentoo/pull/3535
Committed to tree. Thanks for such a rapid fix.
I'm using ld.gold as default and have never seen this error. Nevertheless you should not just pass -DENABLE_LDGOLD=OFF. https://github.com/xbmc/xbmc/pull/11213#issuecomment-268379754 says it is there for a reason (PR https://github.com/xbmc/xbmc/pull/9924). You should pass -DENABLE_LDGOLD=OFF if and only if tc-ld-is-gold returns false. so please adjust that accordingly.
(In reply to Steffen Hau from comment #4) > I'm using ld.gold as default and have never seen this error. Nevertheless > you should not just pass -DENABLE_LDGOLD=OFF. > https://github.com/xbmc/xbmc/pull/11213#issuecomment-268379754 says it is > there for a reason (PR https://github.com/xbmc/xbmc/pull/9924). You should > pass -DENABLE_LDGOLD=OFF if and only if tc-ld-is-gold returns false. so > please adjust that accordingly. It doesn't matter if we pass LDGOLD=off for everyone. We use the system linker not automagic to determine. This change would have no effect on you what so ever. The compile time issue was never the point of the bug.
(In reply to Steffen Hau from comment #4) > I'm using ld.gold as default and have never seen this error. Nevertheless > you should not just pass -DENABLE_LDGOLD=OFF. > https://github.com/xbmc/xbmc/pull/11213#issuecomment-268379754 says it is > there for a reason (PR https://github.com/xbmc/xbmc/pull/9924). You should > pass -DENABLE_LDGOLD=OFF if and only if tc-ld-is-gold returns false. so > please adjust that accordingly. -- Linker: Default system linker Linker flags: checking if the linker (/usr/x86_64-pc-linux-gnu/bin/ld) is GNU ld... yes checking if the linker (/usr/x86_64-pc-linux-gnu/bin/ld) is GNU ld... yes On a default ld.gold system linker it does adjust properly have confirmed it as well.
Thats not true! Please read the links I provided before taking assumptions. If you pass -DENABLE_LDGOLD=OFF then the complete module LDGOLD.cmake will not be used. The ebuild sets CMAKE_BUILD_TYPE to RelWithDebInfo for normal builds which means -gsplit-dwarf is not added to C{,XX}FLAGS and -Wl,--gdb-index is not added to CMAKE_*_LINKER_FLAGS. Have a look in LDGOLD.cmake or the mentioned PR. Whats wrong with my approach? It's a oneliner: tc-ld-is-gold || mycmakeargs+=( -DENABLE_LDGOLD=OFF ).
My understanding is that split-debug and gdb-index are improvements to the way debug information is stored. They require gold to be enabled to use them, but do not have to be enabled in order to use gold. Therefore, you're free to add them to your CFLAGS/LDFLAGS and use them system wide or just for this package... But this package shouldn't be enabling/forcing them itself (just like it shouldn't be forcing gold to be used or not used).
(In reply to candrews from comment #8) > My understanding is that split-debug and gdb-index are improvements to the > way debug information is stored. They require gold to be enabled to use > them, but do not have to be enabled in order to use gold. Therefore, you're > free to add them to your CFLAGS/LDFLAGS and use them system wide or just for > this package... But this package shouldn't be enabling/forcing them itself > (just like it shouldn't be forcing gold to be used or not used). It looks like you did not get the point... I'm curious about what your problem is? Whats wrong with adding my oneliner? Kodi devs have added that file for a purpose and you're deactivating it completely because of one person complaining about issues with ld.gold. toolchain eclass and its functions are there for a reason, e.g to see what the toolchain consist of. If it would be a big deal to check which linker is used, ok. But tc-ld-is-gold does this check for you and you should make use of it and both Jory and I get the functionality we want: disable ld.gold if it's not the default linker or use ld.gold and do it the kodi devs way..
My problem with your suggestion is that it goes against the general Gentoo policy that users should have control and packages should yield as much control as possible. If a user wants to use split-dward and gdb-index, they should be able to do so - or not - independent of what a package says. When a user uses gold, they may (or may not) want split-dward and gdb-index. If we do as you say, then when a uses users gold, for kodi, they get split-dward and gdb-index and they didn't ask for them nor expect them. IMHO, if you want split-dward and gdb-index, add them to your CFLAGS/LDFLAGS (either globally or just for kodi using package.env). But that shouldn't be forced on all gold users. Regarding Kodis approach to have split-dward and gdb-index on when gold is used, that's totally up to them :-) But as Gentoo, it's our packaging policy to give users freedom that upstreams may not always facilitate themselves. If Kodi won't build the way the ebuild is now and adding split-dward and gdb-index fixes it, that's a totally different situation - and I request that you file a new bug describing the failure if that's the case.
Yeah, then go ahead and start patching tons of other packages whose configure/cmake scripts check for compiler/linker switches and use them if available... How about the other way by letting the package compile and link as upstream suggest if LD is gold and users should disable gsplit-dwarf via package.env if desired. The point is: upstream kodi defaults to ld.gold if available. By using tc-ld-is-gold you can disable that instead of hard disabling it. Your approach leads to more work for me, my approach "blows" up the ebuild by approx 32 bytes.
Created attachment 461502 [details, diff] Configure cmake to use 'Gentoo' build type
Steffen point a potential future source of problems. Why this package use the RelWithDebInfo release instead of the gentoo one ? I use the gentoo release since I've switched to cmake build without problem. Gentoo build system add some info about the target system. With RelWithDebInfo, we are forced to follow the debian build rules. I attach a patch with the part about gentoo release type. It probably solves the LDGOLD issue and prevent future problem with the debian build policy. PS: I've just extracted the line from my ebuild, I can test it later on this ebuild if you want. PS2: There is probably a cleaner way for WITH_CPU, but I don't know it !
(In reply to Marc Perrudin from comment #13) > Steffen point a potential future source of problems. Why this package use > the RelWithDebInfo release instead of the gentoo one ? Because the binaries would be stripped. Details can be found on https://github.com/xbmc/xbmc/pull/11213. > I use the gentoo release since I've switched to cmake build without problem. > Gentoo build system add some info about the target system. With > RelWithDebInfo, we are forced to follow the debian build rules. I attach a > patch with the part about gentoo release type. It probably solves the LDGOLD > issue and prevent future problem with the debian build policy. Deb stands for Debug and not Debian.
(In reply to Marc Perrudin from comment #12) > Created attachment 461502 [details, diff] [details, diff] > Configure cmake to use 'Gentoo' build type There is no build type of "Gentoo" defined by Kodi. Why are you adding -DWITH_CPU, -DCMAKE_INSTALL_PREFIX, -DDEPENDS_PATH, and -DNATIVEPREFIX? They seems unnecessary as they match what is already done by default... what problem are you trying to solve?
