[arch-dev-public] Default LDFLAGS for official packages
I think we should agree on a default LDFLAGS setting for our official packages. In the pacman signoff thread, it was suggested to use -Wl,--as-needed and later also -Wl,--no-undefined (and more). Can we compose a default LDFLAGS line that we all should use?
Thomas Bächler wrote:
I think we should agree on a default LDFLAGS setting for our official packages. In the pacman signoff thread, it was suggested to use -Wl,--as-needed and later also -Wl,--no-undefined (and more). Can we compose a default LDFLAGS line that we all should use?
I will again propose: -Wl,--hash-style=gnu -Wl,--as-needed Last time I tried, --no-undefined broke quite a few packages so I don't think it is ready for general use yet. Allan
Allan McRae schrieb:
Thomas Bächler wrote:
I think we should agree on a default LDFLAGS setting for our official packages. In the pacman signoff thread, it was suggested to use -Wl,--as-needed and later also -Wl,--no-undefined (and more). Can we compose a default LDFLAGS line that we all should use?
I will again propose: -Wl,--hash-style=gnu -Wl,--as-needed
Last time I tried, --no-undefined broke quite a few packages so I don't think it is ready for general use yet.
Doesn't --hash-style=gnu break compatibility with closed-source and legacy binaires? Shouldn't this be --hash-style=both? Not an expert here, just stating what I think to remember.
Thomas Bächler wrote:
Allan McRae schrieb:
Thomas Bächler wrote:
I think we should agree on a default LDFLAGS setting for our official packages. In the pacman signoff thread, it was suggested to use -Wl,--as-needed and later also -Wl,--no-undefined (and more). Can we compose a default LDFLAGS line that we all should use?
I will again propose: -Wl,--hash-style=gnu -Wl,--as-needed
Last time I tried, --no-undefined broke quite a few packages so I don't think it is ready for general use yet.
Doesn't --hash-style=gnu break compatibility with closed-source and legacy binaires? Shouldn't this be --hash-style=both? Not an expert here, just stating what I think to remember.
The linker handles both hash-types so this is not an issue. Note we already have hash-style=both as the default for our gcc. Allan
Allan McRae wrote:
Thomas Bächler wrote:
Allan McRae schrieb:
Thomas Bächler wrote:
I think we should agree on a default LDFLAGS setting for our official packages. In the pacman signoff thread, it was suggested to use -Wl,--as-needed and later also -Wl,--no-undefined (and more). Can we compose a default LDFLAGS line that we all should use?
I will again propose: -Wl,--hash-style=gnu -Wl,--as-needed
Last time I tried, --no-undefined broke quite a few packages so I don't think it is ready for general use yet.
Doesn't --hash-style=gnu break compatibility with closed-source and legacy binaires? Shouldn't this be --hash-style=both? Not an expert here, just stating what I think to remember.
The linker handles both hash-types so this is not an issue. Note we already have hash-style=both as the default for our gcc.
Another LDFLAG that should be safe is -Wl,--sort-common Allan
On Wed, 2009-08-12 at 11:29 +0200, Thomas Bächler wrote:
Allan McRae schrieb:
Thomas Bächler wrote:
I think we should agree on a default LDFLAGS setting for our official packages. In the pacman signoff thread, it was suggested to use -Wl,--as-needed and later also -Wl,--no-undefined (and more). Can we compose a default LDFLAGS line that we all should use?
I will again propose: -Wl,--hash-style=gnu -Wl,--as-needed
Last time I tried, --no-undefined broke quite a few packages so I don't think it is ready for general use yet.
Doesn't --hash-style=gnu break compatibility with closed-source and legacy binaires? Shouldn't this be --hash-style=both? Not an expert here, just stating what I think to remember.
It makes our binaries incompatible to old linkers, not the other way around.
On Wed, Aug 12, 2009 at 4:19 AM, Allan McRae<allan@archlinux.org> wrote:
Thomas Bächler wrote:
I think we should agree on a default LDFLAGS setting for our official packages. In the pacman signoff thread, it was suggested to use -Wl,--as-needed and later also -Wl,--no-undefined (and more). Can we compose a default LDFLAGS line that we all should use?
I will again propose: -Wl,--hash-style=gnu -Wl,--as-needed
Last time I tried, --no-undefined broke quite a few packages so I don't think it is ready for general use yet.
I'm fine with whatever people decide, I would only recommend it make it into the pacman package by way of being in the default makepkg.conf included there. Whoever wants to make the update is more than welcome to, and we can either rebuild right away or hold off for a bit (3.3.1 is likely ~2 weeks away). -Dan
On Wed, Aug 12, 2009 at 7:24 AM, Dan McGee<dpmcgee@gmail.com> wrote:
On Wed, Aug 12, 2009 at 4:19 AM, Allan McRae<allan@archlinux.org> wrote:
Thomas Bächler wrote:
I think we should agree on a default LDFLAGS setting for our official packages. In the pacman signoff thread, it was suggested to use -Wl,--as-needed and later also -Wl,--no-undefined (and more). Can we compose a default LDFLAGS line that we all should use?
I will again propose: -Wl,--hash-style=gnu -Wl,--as-needed
Last time I tried, --no-undefined broke quite a few packages so I don't think it is ready for general use yet.
I'm fine with whatever people decide
I'm with Dan here. As these discussions have shown, you guys know way more about gcc linker flags than I, so I will defer to what you guys think is right in this case. --as-needed is the only one I *know* is pretty important, though
I added: LDFLAGS="-Wl,--hash-style=gnu -Wl,--as-needed" to makepkg.conf on the pacman package SVN trunk so these will be default once pacman-3.3.1 gets released. This choice was a bit of a trade off between usability and being a ricer. Other LDFLAGS I considered (--sort-common, -Bsymbolic-functions, --no-undefined) may all be useful, but then again so are many CLFAGS we don't use. We can always make additions later. Allan
Allan McRae schrieb:
Thomas Bächler wrote:
I think we should agree on a default LDFLAGS setting for our official packages. In the pacman signoff thread, it was suggested to use -Wl,--as-needed and later also -Wl,--no-undefined (and more). Can we compose a default LDFLAGS line that we all should use?
I will again propose: -Wl,--hash-style=gnu -Wl,--as-needed
Last time I tried, --no-undefined broke quite a few packages so I don't think it is ready for general use yet.
Thanks again for the clarification w.r.t. the hash-style. IMO, --as-needed is a must (any breakage can be reported upstream). --no-undefined seems useful, but if you say it breaks a large portion of our packages, then I support your proposal. BTW, we should include default CFLAGS/LDFLAGS for official and community packages in the packaging guidelines, and recommend AUR users to use those as well, so they will test their packages in the right environment. If this breaks any package, the flag(s) should be unset inside the PKGBUILD and a comment should be added.
Thomas Bächler wrote:
Allan McRae schrieb:
Thomas Bächler wrote:
I think we should agree on a default LDFLAGS setting for our official packages. In the pacman signoff thread, it was suggested to use -Wl,--as-needed and later also -Wl,--no-undefined (and more). Can we compose a default LDFLAGS line that we all should use?
I will again propose: -Wl,--hash-style=gnu -Wl,--as-needed
Last time I tried, --no-undefined broke quite a few packages so I don't think it is ready for general use yet.
Thanks again for the clarification w.r.t. the hash-style. IMO, --as-needed is a must (any breakage can be reported upstream). --no-undefined seems useful, but if you say it breaks a large portion of our packages, then I support your proposal.
I would not say a large portions, but enough to be annoying. It is likely to be useful in the future.
BTW, we should include default CFLAGS/LDFLAGS for official and community packages in the packaging guidelines, and recommend AUR users to use those as well, so they will test their packages in the right environment. If this breaks any package, the flag(s) should be unset inside the PKGBUILD and a comment should be added.
The flags will be added to the Arch pacman package's makepkg.conf file so everybody will get them. I agree that issues with LDFLAGS should be handled the same way we currently deal with issues with CFLAGS. In the future, I intend to implement !cflags and !ldflags options in PKGBUILDs/makepkg that unset the values defined in makepkg.conf. Allan
participants (5)
-
Aaron Griffin
-
Allan McRae
-
Dan McGee
-
Jan de Groot
-
Thomas Bächler