Bug 1412274

Summary: rubygem-rkerberos is FTBFS on Rawhide [ppc]
Product: [Fedora] Fedora Reporter: Vít Ondruch <vondruch>
Component: rubyAssignee: Vít Ondruch <vondruch>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 26CC: abokovoy, dan, dominic, j, mmorsi, msuchy, mtasaka, mtasaka, nalin, npmccallum, praiskup, rharwood, s, strzibny, vanmeeuwen+fedora, vondruch
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-01 16:50:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1417590    
Bug Blocks: 1071880    
Attachments:
Description Flags
preprocessed source on x86_64 with -std=c99
none
preprocessed source on ppc64 with -std=c99 ( none

Description Vít Ondruch 2017-01-11 16:28:36 UTC
Description of problem:
rubygem-rkerberos does not build on ppc64(le). It fails with errors such as:

```
gcc -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. -I/usr/include/et -DHAVE_KRB5_H -DHAVE_KADM5_ADMIN_H -DHAVE_KDB_H -I/usr/local/include    -fPIC -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64  -std=c99 -Wall -pedantic -m64 -o keytab.o -c keytab.c
In file included from /usr/include/gssrpc/rpc.h:46:0,
                 from /usr/include/kadm5/admin.h:45,
                 from ./rkerberos.h:9,
                 from keytab.c:1:
/usr/include/gssrpc/xdr.h:123:38: error: unknown type name 'caddr_t'
```



Version-Release number of selected component (if applicable):
rubygem-rkerberos-0.1.5-2.fc26

How reproducible:
Always

Comment 1 Vít Ondruch 2017-01-11 16:31:42 UTC
I shortened the log too much, so once more:

```
gcc -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I. -I/usr/include/et -DHAVE_KRB5_H -DHAVE_KADM5_ADMIN_H -DHAVE_KDB_H -I/usr/local/include    -fPIC -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64  -std=c99 -Wall -pedantic -m64 -o keytab.o -c keytab.c
In file included from /usr/include/gssrpc/rpc.h:46:0,
                 from /usr/include/kadm5/admin.h:45,
                 from ./rkerberos.h:9,
                 from keytab.c:1:
/usr/include/gssrpc/xdr.h:123:38: error: unknown type name 'caddr_t'
   bool_t (*x_getbytes)(struct XDR *, caddr_t, u_int);
                                      ^~~~~~~
/usr/include/gssrpc/xdr.h:123:47: error: unknown type name 'u_int'
   bool_t (*x_getbytes)(struct XDR *, caddr_t, u_int);
                                               ^~~~~
```

Comment 2 Dan Horák 2017-01-11 16:34:07 UTC
Looks as either a header is not included on ppc while it's on other arches or maybe undefined BSD compat mode. Could be a recent glibc change ...

Comment 3 Vít Ondruch 2017-01-12 08:28:39 UTC
Please note there was this workaround applied:

http://pkgs.fedoraproject.org/cgit/rpms/rubygem-rkerberos.git/commit/?id=427960e06fbacd2a0cfe859699cc7b8f41a65d41

Comment 4 Dan Horák 2017-01-12 10:44:47 UTC
/usr/include/gssrpc/xdr.h is part of krb5-devel, I guess krb5 should make sure the types are available.

Comment 5 Robbie Harwood 2017-01-13 15:59:34 UTC
Why is this failing on ppc and nowhere else?  None of the other platforms export these symbols differently.

In order to use xdr.h, you need to include types.h.  While this is far from great, it is also not new; these files have not been touched since 2010.

Comment 6 Dan Horák 2017-01-13 16:07:51 UTC
The header inclusion chains can be different between arches. Let me try build on s390x ...

Comment 7 Dan Horák 2017-01-13 16:54:46 UTC
(In reply to Dan Horák from comment #6)
> The header inclusion chains can be different between arches. Let me try
> build on s390x ...

no issue on s390x - https://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2446338

Comment 8 Mamoru TASAKA 2017-01-13 17:03:16 UTC
(In reply to Dan Horák from comment #7)
> (In reply to Dan Horák from comment #6)
> > The header inclusion chains can be different between arches. Let me try
> > build on s390x ...
> 
> no issue on s390x -
> https://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2446338

Note that this already contains my workaround (see comment #3 ).
If you can try, remove the workaround (i.e. remove -D_DEFAULT_SOURCE).

Comment 9 Dan Horák 2017-01-13 17:18:40 UTC
(In reply to Mamoru TASAKA from comment #8)
> (In reply to Dan Horák from comment #7)
> > (In reply to Dan Horák from comment #6)
> > > The header inclusion chains can be different between arches. Let me try
> > > build on s390x ...
> > 
> > no issue on s390x -
> > https://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2446338
> 
> Note that this already contains my workaround (see comment #3 ).
> If you can try, remove the workaround (i.e. remove -D_DEFAULT_SOURCE).

right :-) https://s390.koji.fedoraproject.org/koji/taskinfo?taskID=2446344 is without the patch, but both were without the new ruby 2.4

Comment 10 Robbie Harwood 2017-01-17 20:50:13 UTC
Upstream suggests that there may be a version mismatch here - can you try with all the krb5-1.15 packages installed?

I know krb5 built on this platform, so the headers are around, but it looks like they're not installed at build-time for the gem here.

Comment 11 Robbie Harwood 2017-01-24 19:41:35 UTC
Upstream adds that the problem may be the build using `-std=c99` instead of `-std=gnu99`.

Comment 12 Mamoru TASAKA 2017-01-25 03:54:29 UTC
(In reply to Robbie Harwood from comment #11)
> Upstream adds that the problem may be the build using `-std=c99` instead of
> `-std=gnu99`.

Looks like this is bingo: with -std=c99, build still fails on ppc64{,le}, however with removing -std=c99 (gcc 6.3 defaults to -std=gnu11) or explicitly replacing with -std=gnu99 makes compile pass on i686,x86_64,armv7hl,aarch64,ppc64,pcp64le.

Committed:
http://pkgs.fedoraproject.org/cgit/rpms/rubygem-rkerberos.git/commit/?id=13b7719684d0609ab5a388368664e6110d7c879c

* Wed Jan 25 2017 Mamoru TASAKA <mtasaka> - 0.1.5-3
- Use GNU extension for compilar flag to avoid build failure on
  ppc64{,le} wrt kerberos header (bug 1412274)

Comment 13 Vít Ondruch 2017-01-25 09:16:30 UTC
I still don't understand what is different on PPC. There should be no difference IMO.

Comment 14 Mamoru TASAKA 2017-01-25 10:17:25 UTC
Created attachment 1244204 [details]
preprocessed source on x86_64 with -std=c99

preprocessed source on x86_64 with -std=c99

Comment 15 Mamoru TASAKA 2017-01-25 10:19:54 UTC
Created attachment 1244205 [details]
preprocessed source on ppc64 with -std=c99 (

preprocessed source on ppc64 with -std=c99

Comment 16 Mamoru TASAKA 2017-01-25 10:30:06 UTC
Looks like the problem seems to be in ruby (ruby-devel).

Difference of preprocessed source (with -std=c99) between x86_64 and ppc64 at the very top lines shows:

--- x86_64-preprocessed.log     2017-01-25 19:14:34.285989354 +0900
+++ ppc64-preprocessed.log      2017-01-25 19:14:45.149070857 +0900
 # 1 "/usr/include/ruby/ruby.h" 1 3 4
 # 24 "/usr/include/ruby/ruby.h" 3 4
 # 1 "/usr/include/ruby/config.h" 1 3 4
-# 36 "/usr/include/ruby/config.h" 3 4 <======================
-# 1 "/usr/include/ruby/config-x86_64.h" 1 3 4 <======================
-# 37 "/usr/include/ruby/config.h" 2 3 4
-# 25 "/usr/include/ruby/ruby.h" 2 3 4
-# 36 "/usr/include/ruby/ruby.h" 3 4
-# 1 "/usr/include/ruby/defines.h" 1 3 4
-# 20 "/usr/include/ruby/defines.h" 3 4
-# 1 "/usr/include/ruby/config.h" 1 3 4
-# 21 "/usr/include/ruby/defines.h" 2 3 4
-# 101 "/usr/include/ruby/defines.h" 3 4
-# 1 "/usr/include/stdio.h" 1 3 4
-# 28 "/usr/include/stdio.h" 3 4
-# 1 "/usr/include/bits/libc-header-start.h" 1 3 4
-# 33 "/usr/include/bits/libc-header-start.h" 3 4
+# 23 "/usr/include/ruby/config.h" 3 4 <======================
+# 1 "/usr/include/endian.h" 1 3 4 <======================
+# 21 "/usr/include/endian.h" 3 4
 # 1 "/usr/include/features.h" 1 3 4 <==========================

So /usr/include/ruby/config.h shows:

     18 #if defined(__i386__)
     19 #include "ruby/config-i386.h"
     20 #elif defined(__ia64__)
     21 #include "ruby/config-ia64.h"
     22 #elif defined(__powerpc64__)
     23 #include <endian.h>
     24 #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
     25 #include "ruby/config-ppc64.h"
     26 #else
     27 #include "ruby/config-ppc64le.h"
     28 #endif
     29 #elif defined(__powerpc__)
     30 #include "ruby/config-ppc.h"
     31 #elif defined(__s390x__)
     32 #include "ruby/config-s390x.h"
     33 #elif defined(__s390__)
     34 #include "ruby/config-s390.h"
     35 #elif defined(__x86_64__)
     36 #include "ruby/config-x86_64.h"

So on x86_64, line 36 includes ruby/config-x86_64.h, which contains "#define _GNU_SOURCE 1", for example, and later features.h is included. So at the time features.h is included, _GNU_SOURCE is already defined.

On ppc64, it is different. First ruby/config.h includes "endian.h", which includes "features.h" immediately. At this time config-ppc64.h is not defined, and _GNU_SOURCE is not defined (yet).
Later ppc64 includes "config-ppc64.h", which contains "#define _GNU_SOURCE 1", however this may be no effect as feature.h is already included.

Comment 17 Vít Ondruch 2017-01-25 11:00:26 UTC
(In reply to Mamoru TASAKA from comment #16)
This sounds as plausible explanation. This was introduced due to bug 1053263.

So is there any better chance how to detect that we are on PPC64LE? Looking at MIPS, they are using different approach. Is there something similar on PPC?

May be we should use something proposed here?

https://fedorahosted.org/fpc/ticket/312
https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks

Although (on the first look) it does not look it supports PPC64LE correctly.

Comment 18 Dan Horák 2017-01-25 11:14:11 UTC
(In reply to Vít Ondruch from comment #17)
> (In reply to Mamoru TASAKA from comment #16)
> This sounds as plausible explanation. This was introduced due to bug 1053263.
> 
> So is there any better chance how to detect that we are on PPC64LE? Looking
> at MIPS, they are using different approach. Is there something similar on
> PPC?

the current check to distinguish between ppc64 and ppc64le is the correct one. There is nothing like __powerpc64le__ defined by default.

Comment 19 Mamoru TASAKA 2017-01-25 14:38:16 UTC
Well, after some consideration:

So does ruby related source compilation expect that ruby/config.h (or ruby/config-<arch>.h) should always be included before <features.h> is included?

Consider the following code, for example:
---------------------------------
#include <string.h>
#include <ruby.h>
----------------------------------

Here glibc's standard C header file like string.h or so will always include features.h at first, so at the time we write #include <ruby.h>, features.h is already included. And I think we can't force people to do like, "if you want to use <ruby.h>, always include first!!!".

So I suspect that we cannot expect that we can specify C dialect (like _GNU_SOURCE) using ruby/config-<arch>.h, we must always specify C dialect using command line (like -std=gnu99 or -D_GNU_SOURCE or so).

Under such assumption, as we are actually using glibc, one alternative approach can be to make ruby/config.h explicitly include features.h first. With this, I think we can minimize arch-specific differences as shown in this bug. Also, maybe adding "-std=gnu11" or "-D_GNU_SOURCE" or some other options default for ruby into "rbconfig.h" is preferable.

Comment 20 Mamoru TASAKA 2017-01-25 14:42:12 UTC
> we must always specify C dialect using command line (like -std=gnu99 or -D_GNU_SOURCE or so).

or to write feature test macro explicitly before including any headers.

Comment 21 Vít Ondruch 2017-01-25 15:08:44 UTC
Since you keep thinking about it, this is my (untested, but this is the scratch build [1]) proposal:

```
diff --git a/ruby.spec b/ruby.spec
index cdb2047..05ad784 100644
--- a/ruby.spec
+++ b/ruby.spec
@@ -153,6 +153,7 @@ BuildRequires: git
 BuildRequires: %{_bindir}/cmake
 # Required to test hardening.
 BuildRequires: %{_bindir}/checksec
+BuildRequires: multilib-rpm-config
 
 # This package provides %%{_bindir}/ruby-mri therefore it is marked by this
 # virtual provide. It can be installed as dependency of rubypick.
@@ -553,8 +554,7 @@ make install DESTDIR=%{buildroot}
 
 # Rename ruby/config.h to ruby/config-<arch>.h to avoid file conflicts on
 # multilib systems and install config.h wrapper
-mv %{buildroot}%{_includedir}/%{name}/config.h %{buildroot}%{_includedir}/%{name}/config-%{_arch}.h
-install -m644 %{SOURCE7} %{buildroot}%{_includedir}/%{name}/config.h
+%multilib_fix_c_header --file %{_includedir}/%{name}/config.h
 
 # Rename the ruby executable. It is replaced by RubyPick.
 %{?with_rubypick:mv %{buildroot}%{_bindir}/%{name}{,-mri}}
```

folowing this guildelines draft [2]. According my understanding, the wrapper is created only for the systems, which are actually multilib. So on PPC64LE, which is not multilib as far as I understand, it is no-op and there is no wrapper at all.

If something is wrong with this approach, we can file bug against multilib-rpm-config and let others fix it ;)

Now I need to check the scratch build actually.

BTW upstream position is that everybody should use mkmf or some other configuration tool to build even the simplest piece of Ruby dependent C code ...



[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=17410884
[2] https://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks

Comment 23 Vít Ondruch 2017-01-26 09:43:12 UTC
(In reply to Vít Ondruch from comment #21)
> Since you keep thinking about it, this is my (untested, but this is the
> scratch build [1]) proposal:

I tested it on x86_64/i686 and it works. According to Dan, the scratch build works with the original rubygem-rkerberos on PPC(LE).

So if nobody objects, I'll apply this patch lets say Monday (or later in case I forget ;)).

Comment 24 Mamoru TASAKA 2017-01-30 13:29:42 UTC
(In reply to Vít Ondruch from comment #23)
> (In reply to Vít Ondruch from comment #21)
> > Since you keep thinking about it, this is my (untested, but this is the
> > scratch build [1]) proposal:
> 
> I tested it on x86_64/i686 and it works. According to Dan, the scratch build
> works with the original rubygem-rkerberos on PPC(LE).
> 
> So if nobody objects, I'll apply this patch lets say Monday (or later in
> case I forget ;)).

Sorry I have not checked this. Please check in if it seems good for you. If something went wrong, I can report it later.

Comment 25 Vít Ondruch 2017-01-30 15:09:10 UTC
(In reply to Mamoru TASAKA from comment #24)
Ok, I will apply as soon as Ruby could be build again ...

Comment 26 Vít Ondruch 2017-02-03 15:41:28 UTC
I applied the patch from comment 21 into Ruby. Switching this to ON_QA, since we should test the rkerberos again. It should build now without all the patches again.

Comment 27 Fedora End Of Life 2017-02-28 10:55:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 28 Fedora Update System 2017-03-07 13:02:07 UTC
rubygem-rkerberos-0.1.5-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-1ad6c7faa3

Comment 29 Fedora Update System 2017-03-10 23:19:24 UTC
rubygem-rkerberos-0.1.5-5.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-1ad6c7faa3

Comment 30 Fedora Update System 2017-04-01 16:50:03 UTC
rubygem-rkerberos-0.1.5-5.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.