This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Since ipvsadm does not use autoconf, I went ahead and put %set_build_flags in the %build section, per instructions in the link provided above. This did not work, caused build to fail. Have not been able to find documentation on this macro.

(In reply to Ryan O'Hara from comment #2)
> Since ipvsadm does not use autoconf, I went ahead and put %set_build_flags
> in the %build section, per instructions in the link provided above. This did
> not work, caused build to fail. Have not been able to find documentation on
> this macro.

When talking about build failures, please be more specific.  Do you have a link to a scratch build?  You do not a fairly recent Fedora 28 or rawhide installation inside the buildroot.

The macro is documented in the file I linked to in comment 0.

Please let me know if you have further questions.

Fixed in rawhide and F28.

Sorry, according to the ipvsadm-1.29-7.fc28 build log, LDFLAGS still aren't being used:

gcc -Wall -Wunused -Wstrict-prototypes -g -o ipvsadm ipvsadm.o config_stream.o dynamic_array.o libipvs/libipvs.a -lpopt -lnl-genl-3 -lnl-3

Right. I forgot to add the patch that adds LDFLAGS to the Makefile. I'll try to add this soon.

I have a patch that adds LDFLAGS to both the top-level Makefile and libipvs/Makefile, but that has caused some problems. The libipvs code is compiled with -fPIC (set in CFLAGS of libipvs/Makefile), but the ipvsadm utility itself is not. We end up with this:

/usr/bin/ld: ipvsadm.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: config_stream.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: dynamic_array.o: relocation R_X86_64_32 against symbol `strdup@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output

It was my understanding that, by default, all builds were hardened and it was also my understanding that this was defined in redhat-hardened-cc1. I'm not seeing any indication that redhat-hardened-cc1 rules are being used. Is that normal or am I missing something? Thoughts?

(In reply to Ryan O'Hara from comment #8)
> I have a patch that adds LDFLAGS to both the top-level Makefile and
> libipvs/Makefile, but that has caused some problems. The libipvs code is
> compiled with -fPIC (set in CFLAGS of libipvs/Makefile), but the ipvsadm
> utility itself is not. We end up with this:
> 
> /usr/bin/ld: ipvsadm.o: relocation R_X86_64_32 against `.rodata' can not be
> used when making a shared object; recompile with -fPIC
> /usr/bin/ld: config_stream.o: relocation R_X86_64_32 against `.rodata' can
> not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: dynamic_array.o: relocation R_X86_64_32 against symbol
> `strdup@@GLIBC_2.2.5' can not be used when making a shared object; recompile
> with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output

This means that these object files were not built as PIE (or PIC).

> It was my understanding that, by default, all builds were hardened and it
> was also my understanding that this was defined in redhat-hardened-cc1. I'm
> not seeing any indication that redhat-hardened-cc1 rules are being used. Is
> that normal or am I missing something? Thoughts?

With a successful CFLAGs injection, the -specs=…/redhat-hardened-cc1 option ensures that PIE is used for the build, unless -fpic or -fPIC is specified as well, in which case PIC is used.  This almost always does the right thing, producing code which is position-independent and optimized for PIE relocation if possible.

I do not know what is going wrong in your case.  Maybe you can post a link to a scratch build in Koji?  Then I can look at the RPM spec file, and also which flags, exactly, were used to build dynamic_array.o etc.

(In reply to Florian Weimer from comment #9)
> With a successful CFLAGs injection, the -specs=…/redhat-hardened-cc1 option
> ensures that PIE is used for the build, unless -fpic or -fPIC is specified
> as well, in which case PIC is used.  This almost always does the right
> thing, producing code which is position-independent and optimized for PIE
> relocation if possible.

Right. I think I found the problem. The Makefile in ipvsadm is setting CFLAGS directly, not appending, so the CFLAGS set as environment variable is not being used. I thought upstream had fixed this years ago but I must be mistaken.

> I do not know what is going wrong in your case.  Maybe you can post a link
> to a scratch build in Koji?  Then I can look at the RPM spec file, and also
> which flags, exactly, were used to build dynamic_array.o etc.

I was just doing a local 'fedpkg mockbuild' and have not done a commit yet because I wanted to make sure it worked this time. If this CFLAGS change does not work as I hope, I will do a quick scratch build from srpm and provide a link. Thanks.

Fixed (again) in F28 and rawhide. The F28 build can be found here:

https://koji.fedoraproject.org/koji/taskinfo?taskID=25350348

AFAICT the build.log looks correct, with proper LDFLAGS and CFLAGS. Feel free to verify.

Thanks, I can confirm that is fixed!