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
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?
Upstream ticket: https://fedorahosted.org/389/ticket/48202
(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.
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.
(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
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)"
(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
http://pkgs.fedoraproject.org/cgit/redhat-rpm-config.git/tree/rpmrc defines the CPU support for Fedora
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.
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
hmm, the srpm from http://koji.fedoraproject.org/koji/taskinfo?taskID=10194208 really doesn't contain the nunx-stans archive, looking further ...
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.
(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.
(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.
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
yes, that's the correct way, include all sources, but build only the appropriate ones
(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
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
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).
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
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.
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.
(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
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.