Re: Hacks for multilib unclean C headers

2016-06-10 Thread Garrett Holmstrom
On 2016-06-09 01:18, Jonathan Wakely wrote: On 09/06/16 08:02 +, Petr Pisar wrote: That's because gcc.x86_64 accepts -m32 but cannot produce 32-bit executable without the i686 toolchain packages. It sounds like broken dependencies. The alternative would be for gcc.x86_64 to

Re: [Fedora-packaging] Re: Hacks for multilib unclean C headers

2016-06-10 Thread Pavel Raiskup
On Thursday, June 9, 2016 11:28:05 AM CEST Jason L Tibbitts III wrote: > > "PR" == Pavel Raiskup writes: > PR> Thanks to Vit for the link, I'd like to see the discussion in: > PR> https://fedorahosted.org/fpc/ticket/312 > > Why would you bump a three year old ticket for

Re: [Fedora-packaging] Re: Hacks for multilib unclean C headers

2016-06-09 Thread Jason L Tibbitts III
> "PR" == Pavel Raiskup writes: PR> Thanks to Vit for the link, I'd like to see the discussion in: PR> https://fedorahosted.org/fpc/ticket/312 Why would you bump a three year old ticket for this? Just open a new one. - J< -- devel mailing list

Re: Hacks for multilib unclean C headers

2016-06-09 Thread Petr Pisar
On 2016-06-09, Jonathan Wakely wrote: > On 09/06/16 08:02 +, Petr Pisar wrote: >>On 2016-06-08, Jonathan Wakely wrote: >>> Think about it: you can't build 32-bit software **at all** unless you >>> install glibc-devel.i686, not even just

Re: [Fedora-packaging] Re: Hacks for multilib unclean C headers

2016-06-09 Thread Pavel Raiskup
Thanks to Vit for the link, I'd like to see the discussion in: https://fedorahosted.org/fpc/ticket/312 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Hacks for multilib unclean C headers

2016-06-09 Thread Jonathan Wakely
On 09/06/16 08:02 +, Petr Pisar wrote: On 2016-06-08, Jonathan Wakely wrote: On 08/06/16 15:43 +, Petr Pisar wrote: On 2016-06-08, Jonathan Wakely wrote: Also, since gcc%{?_isa} **doesn't work** then yes, not using %_isa for gcc

Re: Hacks for multilib unclean C headers

2016-06-09 Thread Jakub Jelinek
On Thu, Jun 09, 2016 at 08:02:55AM +, Petr Pisar wrote: > > Think about it: you can't build 32-bit software **at all** unless you > > install glibc-devel.i686, not even just "int main() { }" with no > > headers at all. > > > That's because gcc.x86_64 accepts -m32 but cannot produce 32-bit >

Re: Hacks for multilib unclean C headers

2016-06-09 Thread Petr Pisar
On 2016-06-08, Jonathan Wakely wrote: > On 08/06/16 15:43 +, Petr Pisar wrote: >>On 2016-06-08, Jonathan Wakely wrote: >>> Also, since gcc%{?_isa} **doesn't work** then yes, not using %_isa for >>> gcc seems sensible! :-) >>> >>Why both

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Jonathan Wakely
On 08/06/16 17:08 +0100, Jonathan Wakely wrote: The packaging guidelines say to use BuildRequires to build C and C++ packages. I want to extend those guidelines to say don't add Requires: gcc just because you isntall headers. That's not confusing or contradictory. Basically it seems like you

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Jakub Jelinek
On Wed, Jun 08, 2016 at 05:08:30PM +0100, Jonathan Wakely wrote: > On 08/06/16 15:43 +, Petr Pisar wrote: > >On 2016-06-08, Jonathan Wakely wrote: > >>Also, since gcc%{?_isa} **doesn't work** then yes, not using %_isa for > >>gcc seems sensible! :-) > >> > >Why both

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Jonathan Wakely
On 08/06/16 15:43 +, Petr Pisar wrote: On 2016-06-08, Jonathan Wakely wrote: Also, since gcc%{?_isa} **doesn't work** then yes, not using %_isa for gcc seems sensible! :-) Why both gcc.i686 and gcc.x86_64 are available in the x86_64 repository? Shouldn't

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Petr Pisar
On 2016-06-08, Jonathan Wakely wrote: > On 08/06/16 15:21 +0100, Jonathan Wakely wrote: >>I think -devel packages should not "Require: gcc" at all. Not with >>%_isa and not without it. >> >>To actually compile something using those headers you need the C (or >>C++)

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Petr Pisar
On 2016-06-08, Jonathan Wakely wrote: > Also, since gcc%{?_isa} **doesn't work** then yes, not using %_isa for > gcc seems sensible! :-) > Why both gcc.i686 and gcc.x86_64 are available in the x86_64 repository? Shouldn't gcc.i686 be expelled from the x86_64 repository?

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Carlos O'Donell
On 06/08/2016 10:21 AM, Jonathan Wakely wrote: >> If this is so, I will go to FPC with request the ammend the C guidelines >> with explicit discourage of %{?_isa} on gcc because the main >> architecture supports the secondary targets and because gcc is not >> multilib safe. > > I think -devel

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Jonathan Wakely
On 08/06/16 12:00 +, Petr Pisar wrote: On 2016-06-08, Jonathan Wakely wrote: On 08/06/16 08:38 +, Petr Pisar wrote: On 2016-06-08, Jonathan Wakely wrote: On 08/06/16 07:37 +, Petr Pisar wrote: Guidelines require devel

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Jonathan Wakely
On 08/06/16 15:21 +0100, Jonathan Wakely wrote: I think -devel packages should not "Require: gcc" at all. Not with %_isa and not without it. To actually compile something using those headers you need the C (or C++) build environment installed anyway, i.e. you need 'gcc' (or 'gcc-c++') installed

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Petr Pisar
On 2016-06-08, Jonathan Wakely wrote: > On 08/06/16 08:38 +, Petr Pisar wrote: >>On 2016-06-08, Jonathan Wakely wrote: >>> On 08/06/16 07:37 +, Petr Pisar wrote: Guidelines require devel packages to be architecture specific (no

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Jonathan Wakely
On 08/06/16 08:38 +, Petr Pisar wrote: On 2016-06-08, Jonathan Wakely wrote: On 08/06/16 07:37 +, Petr Pisar wrote: Guidelines require devel packages to be architecture specific (no BuildArch: noarch). Guidelines require having dependencies between

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Jakub Jelinek
On Wed, Jun 08, 2016 at 08:38:48AM +, Petr Pisar wrote: > Because "#include " fails without stdlib.h on the system, > you need to depend on something that provides the stdlib.h. And > guidelines says the provider is "gcc". gcc doesn't provide stdlib.h, glibc-headers does. But even for the

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Petr Pisar
On 2016-06-08, Jonathan Wakely wrote: > On 08/06/16 07:37 +, Petr Pisar wrote: >>Guidelines require devel packages to be architecture specific (no >>BuildArch: noarch). Guidelines require having dependencies between >>architecture specific packages restricted to the

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Jonathan Wakely
On 08/06/16 07:37 +, Petr Pisar wrote: Guidelines require devel packages to be architecture specific (no BuildArch: noarch). Guidelines require having dependencies between architecture specific packages restricted to the architecture (Requires: foo-devel%{?_isa}). C guildelines require

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Vít Ondruch
I pursued this once before: https://fedorahosted.org/fpc/ticket/312 but failed to propose the draft. But still, it would be much better if this can be resolved on gcc side: https://bugzilla.redhat.com/show_bug.cgi?id=979403 Vít Dne 7.6.2016 v 17:30 Pavel Raiskup napsal(a): > Just wanted to

Re: Hacks for multilib unclean C headers

2016-06-08 Thread Petr Pisar
On 2016-06-07, Pavel Raiskup wrote: > Just wanted to ping here about one packaging helper [1], which is stuck in > some (possibly infinite/priority) queue without any review. > > In database packages we have that multilib hack for a very long time, > mostly C'ed among various

Re: Hacks for multilib unclean C headers

2016-06-07 Thread Ralf Corsepius
On 06/07/2016 11:03 PM, Jan Kratochvil wrote: On Tue, 07 Jun 2016 17:30:58 +0200, Pavel Raiskup wrote: In database packages we have that multilib hack for a very long time, mostly C'ed among various spec files. #if defined(__x86_64__) #include "${filename}${opt_additional_suffix}_x86_64.h"

Re: Hacks for multilib unclean C headers

2016-06-07 Thread Jan Kratochvil
On Tue, 07 Jun 2016 17:30:58 +0200, Pavel Raiskup wrote: > In database packages we have that multilib hack for a very long time, > mostly C'ed among various spec files. #if defined(__x86_64__) #include "${filename}${opt_additional_suffix}_x86_64.h" #elif defined(__i386__) #include

Re: [Fedora-packaging] Re: Hacks for multilib unclean C headers

2016-06-07 Thread Jason L Tibbitts III
Also, if there is any point in having a packaging guideline for this, please submit a draft to FPC. I think I'd want to see how often it actually helps to have a standardized/mandated way of doing this before we go that far, though. (It's not particularly difficult to make that argument but

Re: Hacks for multilib unclean C headers

2016-06-07 Thread Dan Horák
On Tue, 07 Jun 2016 17:30:58 +0200 Pavel Raiskup wrote: > Just wanted to ping here about one packaging helper [1], which is > stuck in some (possibly infinite/priority) queue without any review. > > In database packages we have that multilib hack for a very long time, >

Hacks for multilib unclean C headers

2016-06-07 Thread Pavel Raiskup
Just wanted to ping here about one packaging helper [1], which is stuck in some (possibly infinite/priority) queue without any review. In database packages we have that multilib hack for a very long time, mostly C'ed among various spec files. Having this in redhat-rpm-config could make that more