FYI clang devs don't want to take 1 line patch adding another no-op flag upstream. https://lists.llvm.org/pipermail/cfe-dev/2017-July/054588.html
-------- Original Message -------- Subject: Re: [arch-dev-public] Changing compilation flags From: arch-dev-public@archlinux.org To: Evangelos Foutras evangelos@foutrelis.com Daniel Micay danielmicay@gmail.com, Public mailing list for Arch Linux development arch-dev-public@archlinux.org On 5 July 2017 at 19:51, Daniel Micay danielmicay@gmail.com wrote: So I think it would be a good idea to flip the default to -z,now in the linker if we"re going to use -fno-plt. I think they"d take a patch for that upstream. Clang issue could be avoided with a 1 line patch adding another no-op flag and they"d take that upstream. It"s harmless to use the slower lazy linking calling convention when -fno-plt is passed.
On 7 July 2017 at 16:39, Jordan Glover Golden_Miller83@protonmail.ch wrote:
FYI clang devs don't want to take 1 line patch adding another no-op flag upstream. https://lists.llvm.org/pipermail/cfe-dev/2017-July/054588.html
Thanks for trying to push the change upstream. I'm sorry they weren't very receptive of it; your responses were on point and further clarified our intended use case.
I'm not sure what Joerg meant by saying "Arch Linux can't do compiler-specific flag definitions". He could be thinking of a regular project that can check for supported compiler flags, but AFAIK that concept is not readily transferable to distro-wide flags. (Even if it was, it would also apply to stack-check and friends so it's a weak argument in my opinion.)
At the end of the day, it's not an issue to carry this patch downstream in Arch. :-)
I'm surprised as it seemed to me that Daniel took it for granted that patch like that will get accepted. Anyway it's hard for an outsider to successfully submit anything to big upstream project. I hope you'll be more lucky if/when you decide to upstream your pie/ssp patches. It would be nice if makepkg have some conditionals i.e. : if cc=clang then cflags="-march=x86-64 -mtune=generic -O2 -pipe -fsanitize=safe-stack -fsanitize=cfi -fvisibility=hidden if cc=gcc then cflags="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fstack-check
-------- Original Message -------- Subject: Re: [arch-dev-public] Changing compilation flags From: evangelos@foutrelis.com To: Jordan Glover Golden_Miller83@protonmail.ch arch-general@archlinux.org arch-general@archlinux.org, Daniel Micay danielmicay@gmail.com, Public mailing list for Arch Linux development arch-dev-public@archlinux.org, joerg@netbsd.org Thanks for trying to push the change upstream. I"m sorry they weren"t very receptive of it; your responses were on point and further clarified our intended use case. I"m not sure what Joerg meant by saying "Arch Linux can"t do compiler-specific flag definitions". He could be thinking of a regular project that can check for supported compiler flags, but AFAIK that concept is not readily transferable to distro-wide flags. (Even if it was, it would also apply to stack-check and friends so it"s a weak argument in my opinion.) At the end of the day, it"s not an issue to carry this patch downstream in Arch. :-)
On 7 July 2017 at 19:17, Jordan Glover Golden_Miller83@protonmail.ch wrote:
I'm surprised as it seemed to me that Daniel took it for granted that patch like that will get accepted. Anyway it's hard for an outsider to successfully submit anything to big upstream project. I hope you'll be more lucky if/when you decide to upstream your pie/ssp patches.
The SSP/PIE patch is a bit of a hack and is specific to Arch and the architectures we support. As mentioned in the commit message, it's a temporary fix until upstream makes those parameters configurable at compile-time (or a better solution is found). This means it's not upstreamable.
It would be nice if makepkg have some conditionals i.e. :
if cc=clang then cflags="-march=x86-64 -mtune=generic -O2 -pipe -fsanitize=safe-stack -fsanitize=cfi -fvisibility=hidden
if cc=gcc then cflags="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fstack-check
There are multiple ways the compiler can be selected; two of them are: 1) exporting CC/CXX in the PKGBUILD and 2) the project's configure script picking one of the available compilers. makepkg can't realistically know which compiler is going to be used and thus must have only one set of flags that is supported by both GCC and Clang.
On 7 July 2017 at 19:17, Jordan Glover Golden_Miller83@protonmail.ch wrote:
I'm surprised as it seemed to me that Daniel took it for granted that patch like that will get accepted. Anyway it's hard for an outsider to successfully submit anything to big upstream project. I hope you'll be more lucky if/when you decide to upstream your pie/ssp patches.
It would be nice if makepkg have some conditionals i.e. :
if cc=clang then cflags="-march=x86-64 -mtune=generic -O2 -pipe -fsanitize=safe-stack -fsanitize=cfi -fvisibility=hidden
if cc=gcc then cflags="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fstack-check
-------- Original Message -------- Subject: Re: [arch-dev-public] Changing compilation flags From: evangelos@foutrelis.com To: Jordan Glover Golden_Miller83@protonmail.ch arch-general@archlinux.org arch-general@archlinux.org, Daniel Micay < danielmicay@gmail.com>, Public mailing list for Arch Linux development < arch-dev-public@archlinux.org>, joerg@netbsd.org
Thanks for trying to push the change upstream. I"m sorry they weren"t very receptive of it; your responses were on point and further clarified our intended use case.
I"m not sure what Joerg meant by saying "Arch Linux can"t do compiler-specific flag definitions". He could be thinking of a regular project that can check for supported compiler flags, but AFAIK that concept is not readily transferable to distro-wide flags. (Even if it was, it would also apply to stack-check and friends so it"s a weak argument in my opinion.)
At the end of the day, it"s not an issue to carry this patch downstream in Arch. :-)
On 08-07-17 04:31, Evangelos Foutras via arch-general wrote:
There are multiple ways the compiler can be selected; two of them are: 1) exporting CC/CXX in the PKGBUILD and 2) the project's configure script picking one of the available compilers. makepkg can't realistically know which compiler is going to be used and thus must have only one set of flags that is supported by both GCC and Clang.
An alternative solution would be to tailor things to the compiler used by the majority (gcc) and to avoid clang as much as possible. That would ocourse require special settings for packages compiled with clang.
NOTE : whether that is a good idea is another matter, but it IS an option.
On 07/08/2017 06:53 AM, LoneVVolf wrote:
On 08-07-17 04:31, Evangelos Foutras via arch-general wrote:
There are multiple ways the compiler can be selected; two of them are: 1) exporting CC/CXX in the PKGBUILD and 2) the project's configure script picking one of the available compilers. makepkg can't realistically know which compiler is going to be used and thus must have only one set of flags that is supported by both GCC and Clang.
An alternative solution would be to tailor things to the compiler used by the majority (gcc) and to avoid clang as much as possible. That would ocourse require special settings for packages compiled with clang.
NOTE : whether that is a good idea is another matter, but it IS an option.
AIUI that is already what we do, in the sense that gcc is the assumed default everywhere, and our (C|CXX|LD)FLAGS are written with the assumption that gcc is the default compiler.
Any packages that need to deviate from the default makepkg.conf flags (because they *already* have special settings to use clang, those settings are in the project build configuration files) can currently modify those flags on a PKGBUILD-by-PKGBUILD basis, or alternatively we can try to get clang to deal with basic gcc compatibility in a graceful manner.
My idea was to have general CC=, CXX=... options set in makepkg.conf, then makepkg would use: CFLAGS_GCC when CC=gcc and CFLAGS_CLANG when CC=clang This way instead of setting common minimal compatible flags we could enable all features that compiler have and maintainer/user would only need to set different CC= option in PKGBUILD or globally in makepkg.conf (it's already possible but flags have to be also manually changed).
-------- Original Message -------- Subject: Re: [arch-general] [arch-dev-public] Changing compilation flags From: arch-general@archlinux.org To: arch-general@archlinux.org Eli Schwartz eschwartz93@gmail.com On 07/08/2017 06:53 AM, LoneVVolf wrote:
On 08-07-17 04:31, Evangelos Foutras via arch-general wrote:
There are multiple ways the compiler can be selected; two of them are: 1) exporting CC/CXX in the PKGBUILD and 2) the project"s configure script picking one of the available compilers. makepkg can"t realistically know which compiler is going to be used and thus must have only one set of flags that is supported by both GCC and Clang.
An alternative solution would be to tailor things to the compiler used by the majority (gcc) and to avoid clang as much as possible. That would ocourse require special settings for packages compiled with clang.
NOTE : whether that is a good idea is another matter, but it IS an option.
AIUI that is already what we do, in the sense that gcc is the assumed default everywhere, and our (C|CXX|LD)FLAGS are written with the assumption that gcc is the default compiler. Any packages that need to deviate from the default makepkg.conf flags (because they *already* have special settings to use clang, those settings are in the project build configuration files) can currently modify those flags on a PKGBUILD-by-PKGBUILD basis, or alternatively we can try to get clang to deal with basic gcc compatibility in a graceful manner. -- Eli Schwartz
spec file? only supported by gcc, but that seems to be kinda the point here. I think this is what most distros do (and possibly also how --enable-default-* works).
arch-general@lists.archlinux.org