Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1234277 - distro-wide architecture set overriden by buildsystem
Summary: distro-wide architecture set overriden by buildsystem
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: 389-ds-base
Version: 22
Hardware: ppc64le
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ZedoraTracker PPCTracker F-ExcludeArch-ppc64le, PPC64LETracker
TreeView+ depends on / blocked
 
Reported: 2015-06-22 09:21 UTC by Dan Horák
Modified: 2020-09-13 21:26 UTC (History)
8 users (show)

Fixed In Version: 389-ds-base-1.3.4.1-1.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-19 14:57:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1533 0 None None None 2020-09-13 21:26:15 UTC

Description Dan Horák 2015-06-22 09:21:00 UTC
The distro-wide architecture set in CFLAGS is overriden by 389-ds-base buildsystem. It tries to set -march to non-existing values on s390(x), for ppc* such compiler option doesn't even exist. The buildsystem should touch the -march options at all. See also https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags

from build logs
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1851358
...
gcc -Wall -Wno-unknown-pragmas -std=c99 -march=s390 -c -I"src" -I"inc" -fpic -O0 -g -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 -m31 -march=z9-109 -mtune=z10  -o obj/queue_queue.o src/queue/queue_queue.c
gcc: error: unrecognized argument in option '-march=s390'
gcc: note: valid arguments to '-march=' are: g5 g6 z10 z196 z9-109 z9-ec z900 z990 zEC12
...

and
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2559662
...
gcc -Wall -Wno-unknown-pragmas -std=c99 -march=ppc64le -c -I"src" -I"inc" -fpic -O0 -g -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 -mcpu=power7 -mtune=power8  -o obj/queue_new.o src/queue/queue_new.c
gcc -MM -std=c99 -I"src" -I"inc" src/stack/stack_delete.c >obj/stack_delete.d
cc1: error: unrecognized command line option '-march=ppc64le'
...


Version-Release number of selected component (if applicable):
389-ds-base-1.3.4.0-1.fc22

Comment 1 Rich Megginson 2015-06-22 13:35:39 UTC
Noriko, can you port the recent fixes for 389 (that is, only build nunc-stans on x86_64, and use nunc-stans 0.1.5) to fedora?

Comment 2 Noriko Hosoi 2015-06-23 16:45:10 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/48202

Comment 3 Noriko Hosoi 2015-06-23 16:46:04 UTC
(In reply to Rich Megginson from comment #1)
> Noriko, can you port the recent fixes for 389 (that is, only build
> nunc-stans on x86_64, and use nunc-stans 0.1.5) to fedora?

Sure, I will.  Thanks for the report.

Comment 4 Dan Horák 2015-06-23 19:03:23 UTC
Ah, I made a mistake in the description, but I guess you got what I meant. The sentence should read - The buildsystem should not touch the -march options at all.

Comment 5 Noriko Hosoi 2015-06-23 20:29:08 UTC
(In reply to Dan Horák from comment #4)
> Ah, I made a mistake in the description, but I guess you got what I meant.
> The sentence should read - The buildsystem should not touch the -march
> options at all.

If we build nunc-stans only for x86_64, the --march override problem disappears except on x86_64.

This "-march=core2" is not allowed on x86_64, either?

gcc -Wall -Wno-unknown-pragmas -std=c99 -march=core2 -c -I"src" -I"inc" -fpic -O0 -g -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 -mtune=generic  -o obj/XYZ.o src/queue/XYZ.c

Comment 6 Noriko Hosoi 2015-06-23 20:39:38 UTC
Note: it's in the make file in the source code.
liblfds/makefile.linux
 30 ifeq ($(GCCARCH),x86_64)
 31   GCCARCH = core2
 32 endif
     ...
 46 CBASE   = -Wall -Wno-unknown-pragmas -std=c99 -march=$(GCCARCH) -c -I"$(SRCDIR)" -I"$(INCDIR)"

Comment 7 Dan Horák 2015-06-23 20:47:42 UTC
(In reply to Noriko Hosoi from comment #5)
> (In reply to Dan Horák from comment #4)
> > Ah, I made a mistake in the description, but I guess you got what I meant.
> > The sentence should read - The buildsystem should not touch the -march
> > options at all.
> 
> If we build nunc-stans only for x86_64, the --march override problem
> disappears except on x86_64.
> 
> This "-march=core2" is not allowed on x86_64, either?

correct, as the resulting binary can crash on CPUs that are not core2 compatible

> gcc -Wall -Wno-unknown-pragmas -std=c99 -march=core2 -c -I"src" -I"inc"
> -fpic -O0 -g -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 -mtune=generic  -o
> obj/XYZ.o src/queue/XYZ.c

Comment 8 Dan Horák 2015-06-23 20:51:08 UTC
http://pkgs.fedoraproject.org/cgit/redhat-rpm-config.git/tree/rpmrc defines the CPU support for Fedora

Comment 9 Rich Megginson 2015-06-23 21:12:51 UTC
I do not want to touch liblfds at all.  Take a look at https://git.fedorahosted.org/cgit/nunc-stans.git/tree/m4/lfds.m4#n65

The goal is to create a GNUmakefile that we can use to override whatever is in the liblfds makefile.

And the 0.1.5 version of nunc-stans should have done just that:

CFLAGS = $CFLAGS \$(AM_CFLAGS) -c -fpic -Wno-unknown-pragmas -std=c99 -I"\$(SRCDIR)" -I"\$(INCDIR)" $LFDS_CFLAGS

Basically, override any CFLAGS set in makefile.linux.

If this isn't working, then we need to revisit this.

Comment 10 Noriko Hosoi 2015-06-24 00:00:31 UTC
Hello Dan, could you please help me?

I updated nunc-stans to 0.1.5 and ran fedpkg to build 389-ds-base-1.3.4.1, then somehow it fails to pick up the nunc-stans-0.1.5.tar.bz2.

I repeated the same procedures when I built 389-ds-base-1.3.4.0.

Here's the steps:
$ fedpkg new-sources `pwd`/389-ds-base-1.3.4.1.tar.bz2 `pwd`/nunc-stans-0.1.5.tar.bz2
$ cat sources
4f61a797a4d9eff4d41c619b7d3d0358  nunc-stans-0.1.5.tar.bz2
ddcc0c0174faf1c5c1e063e2360a1984  389-ds-base-1.3.4.1.tar.bz2

I verified the sources and spec file were good by the scratch build.
For instance, 
$ fedpkg srpm
$ rpm -ivh 389-ds-base-1.3.4.1-1.fc22.src.rpm
$ ls -l ~/rpmbuild/SOURCES
-r--r--r--.  1 nhosoi nhosoi 3356649 Jun 23 15:23 389-ds-base-1.3.4.1.tar.bz2
-r--r--r--.  1 nhosoi nhosoi  402557 Jun 23 15:19 nunc-stans-0.1.5.tar.bz2

I committed/pushed the changes to dist-git.
  .gitignore
  389-ds-base.spec
  sources

$ fedpkg build

This fails as follows:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10194207
x86_64:
http://koji.fedoraproject.org/koji/taskinfo?taskID=10194210
build log:
https://kojipkgs.fedoraproject.org//work/tasks/4210/10194210/build.log
error: File /builddir/build/SOURCES/nunc-stans-0.1.5.tar.bz2: No such file or directory

Thanks,
--noriko

Comment 11 Dan Horák 2015-06-24 10:02:31 UTC
hmm, the srpm from http://koji.fedoraproject.org/koji/taskinfo?taskID=10194208 really doesn't contain the nunx-stans archive, looking further ...

Comment 12 Dan Horák 2015-06-24 10:09:36 UTC
And I see it, you should never ever use %ifarch around the Source or Patch tags (or %if %{use_nunc_stans} in your case), they must be present all the times. But later in the spec you can skip unpacking it. The source rpm must be the same, not depending on the arch of the builder.

Comment 13 Rich Megginson 2015-06-24 13:52:23 UTC
(In reply to Dan Horák from comment #12)
> And I see it, you should never ever use %ifarch around the Source or Patch
> tags (or %if %{use_nunc_stans} in your case), they must be present all the
> times.

But what if we don't want to build nunc-stans at all, don't have the source, and don't care about the source?  That is, if I don't want to build with nunc-stans, why should I care about making sure the source is available?  If you are referring to an official Fedora packaging guideline, can you provide the link?

> But later in the spec you can skip unpacking it. The source rpm must
> be the same, not depending on the arch of the builder.

See above.

Comment 14 Dan Horák 2015-06-24 15:27:49 UTC
(In reply to Rich Megginson from comment #13)
> (In reply to Dan Horák from comment #12)
> > And I see it, you should never ever use %ifarch around the Source or Patch
> > tags (or %if %{use_nunc_stans} in your case), they must be present all the
> > times.
> 
> But what if we don't want to build nunc-stans at all, don't have the source,
> and don't care about the source?  That is, if I don't want to build with
> nunc-stans, why should I care about making sure the source is available?  If
> you are referring to an official Fedora packaging guideline, can you provide
> the link?

https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Conditionalizing_Builds_for_Architecture

For Fedora a single source rpm is sent to build for all architecture, both primary and secondaries. And as we can see in the example in comment 10 I think the "build srpm" task is treated as noarch, because even when it was run on x86_64 builder it didn't include the nunc_stans source archive.

> > But later in the spec you can skip unpacking it. The source rpm must
> > be the same, not depending on the arch of the builder.
> 
> See above.

Comment 15 Noriko Hosoi 2015-06-24 15:50:48 UTC
If it is allowed just including the nunc-stans tarball in srpm but not compiling it, may I do this?

diff --git a/389-ds-base.spec b/389-ds-base.spec
index 50bdc44..83677c2 100644
--- a/389-ds-base.spec
+++ b/389-ds-base.spec
@@ -19,9 +19,7 @@
 %global use_nunc_stans 0
 %endif
 
-%if %{use_nunc_stans}
 %global nunc_stans_ver 0.1.5
-%endif
 
 # fedora 15 and later uses tmpfiles.d
 # otherwise, comment this out
@@ -124,9 +122,7 @@ Source0:          http://port389.org/binaries/%{name}-%{version}%{?prerel}.tar.b
 # 389-ds-git.sh should be used to generate the source tarball from git
 Source1:          %{name}-git.sh
 Source2:          %{name}-devel.README
-%if %{use_nunc_stans}
 Source3:          https://git.fedorahosted.org/cgit/nunc-stans.git/snapshot/nunc-stans-%{nunc_stans_ver}.tar
-%endif
 
 %description
 389 Directory Server is an LDAPv3 compliant server.  The base package includes

Comment 16 Dan Horák 2015-06-24 15:59:54 UTC
yes, that's the correct way, include all sources, but build only the appropriate ones

Comment 17 Noriko Hosoi 2015-06-24 16:01:30 UTC
(In reply to Dan Horák from comment #16)
> yes, that's the correct way, include all sources, but build only the
> appropriate ones

Thank you for your help, Dan!  I'm going to run the build from now...
--noriko

Comment 18 Fedora Update System 2015-06-24 17:04:38 UTC
389-ds-base-1.3.4.1-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.1-1.fc22

Comment 19 Fedora Update System 2015-06-25 08:17:39 UTC
Package 389-ds-base-1.3.4.1-1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing 389-ds-base-1.3.4.1-1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-10664/389-ds-base-1.3.4.1-1.fc22
then log in and leave karma (feedback).

Comment 20 Fedora Update System 2015-07-28 05:02:32 UTC
389-ds-base-1.3.4.3-1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/389-ds-base-1.3.4.3-1.fc22

Comment 21 liblfds-admin 2016-01-13 15:06:22 UTC
Hello.

I am the author of liblfds.

On the 29th December 2015, release 7.0.0 was published.

Arch is now set always to 'native'.

The makefile appends to CFLAGS, which I think will still mean the appended values will be used rather than any existing values, so the 7.0.0 makefile does not solve the problem in this bug.

It's not apparent to me what the usual behaviour is supposed to be.  Should the makefile build its own CFLAGS and then append the existing CFLAGS?

Could you let me know what changes you'd like to see, and I'll get them in the next release (which will be quite soon, unlike 7.0.0, which took basically six years).

As an aside, perhaps of interest, 7.0.0 supports the Linux kernel.

Comment 22 liblfds-admin 2016-01-13 15:08:33 UTC
Oh - additionally - I will backport the makefile fixes to the earlier releases of liblfds.  I did not mean to imply you should use 7.0.0.

Comment 23 Noriko Hosoi 2016-01-14 17:52:02 UTC
(In reply to liblfds-admin from comment #21)
> Hello.
> 
> I am the author of liblfds.
> 
> On the 29th December 2015, release 7.0.0 was published.
> 
> Arch is now set always to 'native'.
> 
> The makefile appends to CFLAGS, which I think will still mean the appended
> values will be used rather than any existing values, so the 7.0.0 makefile
> does not solve the problem in this bug.
> 
> It's not apparent to me what the usual behaviour is supposed to be.  Should
> the makefile build its own CFLAGS and then append the existing CFLAGS?
> 
> Could you let me know what changes you'd like to see, and I'll get them in
> the next release (which will be quite soon, unlike 7.0.0, which took
> basically six years).
> 
> As an aside, perhaps of interest, 7.0.0 supports the Linux kernel.

Thank you for your update.  I've opened a new bug for liblfds upgrade.
Bug 1298679 - nunc-stans -- upgrading liblfds

Comment 24 Fedora End Of Life 2016-07-19 14:57:53 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.