1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • cmake: get rid of -fno-fat-lto-objects

    From Jerome BENOIT@21:1/5 to Debian Developers on Wed Mar 16 22:40:01 2022
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o2OSMtTBFAAQcBkQ1wEySPEcOs8TA3DTa
    Content-Type: text/plain; charset=utf-8; format=flowed
    Content-Language: en-US
    Content-Transfer-Encoding: quoted-printable

    Hello,

    One of my package builds with cmake.

    All is fine except that the built static library gets the no-code-sections error complaint from lintian.
    It appears [1,2] that /usr/share/cmake-3.22/Modules/Compiler/GNU.cmake enforces
    -fno-fat-lto-objects unconditionally for GCC + IPO

    What is the easiest way to revert the -fno-fat-lto-objects flags ?

    Thanks in advance,
    Jerome



    [1] https://gitlab.kitware.com/cmake/cmake/-/issues/21696
    [2] https://stackoverflow.com/questions/70806677/why-does-cmake-set-no-fat-lto-objects-when-i-enable-lto-ipo
    --
    Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/[email protected]
    AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B


    --o2OSMtTBFAAQcBkQ1wEySPEcOs8TA3DTa--

    -----BEGIN PGP SIGNATURE-----

    wsN5BAABCAAjFiEEriiuFXEN/x2H5adiP5IZpn82xosFAmIyWI8FAwAAAAAACgkQP5IZpn82xoti 5SAAhAkJfRreCfgRFgKzO2v7lTAf+y9FZ6daEgiQOcys09WxT1WwzRhIvmdyj4kqssDrq4FC9xlc PnYtUAc8lpBn/xNxH52PYvnaFWbVzGViMuLkL8WxA86B/m3PMA1JPG4YgGVkcY+MT+jojMe2OrDS CD7W8yz6+ux3X2lwbDBn+y/G85Ppf2G0dqZB+re1xZu1hudT3O9Q2gE3tdenaMaWDQ60h4wDetl6 ro/XhQZrE6h0vvO+9RDFzZKYIaOL90iXIHMfTMLebcyI7cMepoQWfQkpH/d2jtrm1RZUa7nk1+i4 LJToKO9eYXGz8VMiei5YLzapOAadnBvvuJU/JEXWXj7Tr/nclijtQz1pLNu1OtnsFpZYcR9iFrfl jCIa45M5Bj7uPmMlO9EPyaKPrpVEclzPtGR7ovCqsYz/3t8CygiOTOfHwu8Hr7Uqxoo39qF4C8+8 HMkR47A2wrvtd33HDZ3WrAxjOHGiO5B2cRahV/Z58LWkkSaPkpugtrDSVwcLYPS150RKoVRAFMas m66Q96epyK9GkquN2LppcOS58jzW+FJM3Til5/8564eKFDhhvs1n6dL+K0eEhxhh4xSA8wHLFtn/ lWg+a4iCWULdz8pmWaH3b6WKL77MdVajbkrNBWUbPdxTxzLfU/e9GSgH4G9Cu4NNn9Zy1lMJ7LVi
  • From Timo =?utf-8?Q?R=C3=B6hling?=@21:1/5 to All on Wed Mar 16 23:40:01 2022
    Hi Jerome,

    * Jerome BENOIT <[email protected]> [2022-03-16 22:37]:
    Hello,

    One of my package builds with cmake.

    All is fine except that the built static library gets the no-code-sections error complaint from lintian.
    It appears [1,2] that /usr/share/cmake-3.22/Modules/Compiler/GNU.cmake enforces
    -fno-fat-lto-objects unconditionally for GCC + IPO

    What is the easiest way to revert the -fno-fat-lto-objects flags ?
    I recommend you explicitly disable LTO for the static library with:

    set_target_properties(staticlib PROPERTIES
    INTERPROCEDURAL_OPTIMIZATION OFF)

    LTO does not really achieve anything for static libraries: They are
    merely an archive of object files, so the linker is never invoked on
    them. You might think that LTO is useful when the static library is
    linked with an executable eventually. Alas, the LTO intermediate
    code is very compiler-specific, so it will not work with a different
    compiler and most likely not even with a different version of the
    same compiler.

    Alternatively, you could add a snippet such as

    if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
    target_compile_options(staticlib PRIVATE -ffat-lto-objects)
    endif()

    This will work because the target-specific compile options happen to
    end up after the LTO compile options on the command line right now.
    However, dh_strip will remove the intermediate code anyway, for the
    reasons outlined above.


    Cheers
    Timo

    --
    ⢀⣴⠾⠻⢶⣦⠀ ╭────────────────────────────────────────────────────╮
    ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
    ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
    ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

    -----BEGIN PGP SIGNATURE-----

    iQGzBAABCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmIyYuEACgkQ+C8H+466 LVmF4QwA3dO7DEhJvQWiAOi/xOeGK/qUHdA1H2eOcbFmhhlA2CzVymCW4GqRt5sC LnGzeUgGG9hd1iyaO6oSghd5NU0J2IOwxnWHLRoULXV+vGhFu41zY5Vq2+QMAqt+ jRUiyWZywTcNgyofS5154q88herF5cCNyrIbhPk5zbgLdZW5PA+ss/ubEkC4AEzz VNP6bGtx6D9zFI/SZw1l4MZz7s5yX/HCHoDn8u45xh8kotjN1UEvqlLjIbfQyfEb inAryoHNhTuG6GE0qgirhOrN++1uULQ89GzNBw0ozs5XgOlPsdmmzwqlAJqGiXcY uSb91svLUEKtBRk61Gs9qX7ShSBDDG81uLQydiDhfRk
  • From Jerome BENOIT@21:1/5 to All on Thu Mar 17 00:30:01 2022
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wMMZe9Mp86ub5ljSqnh4GKdUCTElgVtCq
    Content-Type: text/plain; charset=utf-8; format=flowed
    Content-Language: en-US
    Content-Transfer-Encoding: quoted-printable

    Hi Timo, thanks a lot for the hint.
    Cheers,
    Jerome

    On 16/03/2022 23:21, Timo Röhling wrote:
    Hi Jerome,

    * Jerome BENOIT <[email protected]> [2022-03-16 22:37]:
    Hello,

    One of my package builds with cmake.

    All is fine except that the built static library gets the no-code-sections error complaint from lintian.
    It appears [1,2] that /usr/share/cmake-3.22/Modules/Compiler/GNU.cmake enforces
    -fno-fat-lto-objects unconditionally for GCC + IPO

    What is the easiest way to revert the  -fno-fat-lto-objects flags ?
    I recommend you explicitly disable LTO for the static library with:

       set_target_properties(staticlib PROPERTIES
                             INTERPROCEDURAL_OPTIMIZATION OFF)

    LTO does not really achieve anything for static libraries: They are
    merely an archive of object files, so the linker is never invoked on
    them. You might think that LTO is useful when the static library is
    linked with an executable eventually. Alas, the LTO intermediate
    code is very compiler-specific, so it will not work with a different
    compiler and most likely not even with a different version of the
    same compiler.

    Alternatively, you could add a snippet such as

        if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
            target_compile_options(staticlib PRIVATE -ffat-lto-objects)
        endif()

    This will work because the target-specific compile options happen to
    end up after the LTO compile options on the command line right now.
    However, dh_strip will remove the intermediate code anyway, for the
    reasons outlined above.


    Cheers
    Timo


    --
    Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/[email protected]
    AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B


    --wMMZe9Mp86ub5ljSqnh4GKdUCTElgVtCq--

    -----BEGIN PGP SIGNATURE-----

    wsN5BAABCAAjFiEEriiuFXEN/x2H5adiP5IZpn82xosFAmIycg8FAwAAAAAACgkQP5IZpn82xovA rSAAozNAJW8hYwAt2rWaEqRlkqCjTITAKPNp88ZFT+JC9muWF2R9HSwIE1WyknXZugkic0WIGSjt Dwrsn3s9wrI/2q11N8T4Offn853DcBpTFFhuR2HKqrWe8xJ0okg6Uj1k4vwvRu7r7T0j9spf0OB1 JHH5Ly0NPE2z2NuMVdSe+Xp0tk7I0yeMGJnFrZ55VAULIWUv1IZEtzv+iHieAcmIh4Y2wt9/ujCs RltGuUlaTY6V30gMxSfDAqQiEPWfPa4H9G3X/5mux74hr1b2gXb7dIx3md16agbL4XFtvskkD2S7 GYO33K5oHSYLSDZ5qiE4UjAMUVHJ5nEsD8CRS9NPaBqQrmQO6FaQLBtsoXuPxFfg4zFt+KrKVgeK fZ+FjZnwRAVbqnXIoNepU9XAZwduu5u9W9LYPMGuy7cSI0sMeZ+YYeRs+dynxe6g3hNJE3Te1Eu6 E0NJInl7byctwhXGxfSHaUAiICHgofI0S12y82lOWZz5nKeqnh0P0my8wekCvFymtav8jBPPWQBp B1ryavn5N3WNt/wSRuOjGItVI6FqTwz0DY9XXc3DH9zAssWiiDB2i/85GHuq7MzgPqKFLd9SQN2g uOSmgzwFQIGkalf7Uq1JBNGFHS4WP917pPXlGS5TDSlpSNHfL6XdFlaotB0okc+08FpSdfnsti6b