• infeeeee@lemm.eeOP
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    11 months ago

    I don’t know, in the old version strip was enbled and it worked, check the commit in the MR

    How to stop their generation?

    • kixik@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      11 months ago

      strip has need enabled since I can remember, so yes it was enabled. The change was from this:

      OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug !lto)
      

      To this:

      OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge debug lto)
      

      Actually enabling debug and lto, but keeping strip. So unless I’m missing something, what it adds on one side, it removes it on the other, :)

      You can confirmed with the specif change on the referenced MR.

      • infeeeee@lemm.eeOP
        link
        fedilink
        arrow-up
        1
        ·
        11 months ago

        So lto should be disabled as well if I disable debug? Lto sounds like something useful, but actually I don’t know what it means exactly. Or what do you recommend, I don’t understand.

        • kixik@lemmy.ml
          link
          fedilink
          arrow-up
          2
          ·
          11 months ago

          LTO is a different thing, and I’m not sure why it was enabled by default until now (well, It’s said it doesn’t play nice with clang), see this RFC from 2 years back. Also notice what current makepkg uses is LTOFLAGS="-flto=auto". The idea according to the RFC, is that for packages failing to use the default, options=('!lto') can be added to the PKGBUILD.

          So that should be safe, and iif you’re wondering, it stands for Link Time Optimization. On AUR, I guess users adding new packages or maintaining packages, should be aware, and add that option if they find out LTO by default is giving issues.

          I guess the current defaults are sane. All I said the original post, is that the strip option, which is still enabled by default gets rid of the debug symbols. So yes, now they are getting generated by default, but also stripped off by default. And that’s what I don’t understand. Perhaps that’s a good topic for the arch-general mailing list, hoping some developer is around to clarify things. Perhaps the current makepkg.conf is an intermediate one, and there will come another one using !strip instead. Or maybe currently strip doesn’t get rid of all debug symbols generated by debug. But the current documentation on makepkg.conf is not clear enough…

          So I would leave the current defaults if it’s not clear yet if changing them is something that would help you out. As mentioned, with strip you shouldn’t get that huge packages. But also it’d be good to make sure, asking on a Arch forum involving devs…