Bug 1412274
Summary: | rubygem-rkerberos is FTBFS on Rawhide [ppc] | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Vít Ondruch <vondruch> | ||||||
Component: | ruby | Assignee: | Vít Ondruch <vondruch> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 26 | CC: | 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
Vít Ondruch
2017-01-11 16:28:36 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); ^~~~~ ``` 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 ... Please note there was this workaround applied: http://pkgs.fedoraproject.org/cgit/rpms/rubygem-rkerberos.git/commit/?id=427960e06fbacd2a0cfe859699cc7b8f41a65d41 /usr/include/gssrpc/xdr.h is part of krb5-devel, I guess krb5 should make sure the types are available. 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. The header inclusion chains can be different between arches. Let me try build on s390x ... (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 (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). (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 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. Upstream adds that the problem may be the build using `-std=c99` instead of `-std=gnu99`. (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) I still don't understand what is different on PPC. There should be no difference IMO. Created attachment 1244204 [details]
preprocessed source on x86_64 with -std=c99
preprocessed source on x86_64 with -std=c99
Created attachment 1244205 [details]
preprocessed source on ppc64 with -std=c99 (
preprocessed source on ppc64 with -std=c99
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. (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. (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. 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. > 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.
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 FTR, I applied those two commits as a result of discussion here, thanks! http://pkgs.fedoraproject.org/cgit/rpms/multilib-rpm-config.git/commit/?id=5d02c918d6f8ae9f4d0c5698d01c8d05b3d63f79 http://pkgs.fedoraproject.org/cgit/rpms/multilib-rpm-config.git/commit/?id=01d964b7f45a5137291bdb6cb333c334b1ccbbba (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 ;)). (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. (In reply to Mamoru TASAKA from comment #24) Ok, I will apply as soon as Ruby could be build again ... 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. This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'. rubygem-rkerberos-0.1.5-5.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-1ad6c7faa3 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 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. |