Thanks for the analysis Frank.
On 28/02/14 22:52, Frank Ch. Eigler wrote:
...
What brings out i386 in the PCP builds is the joint effort of our
top level configure.in:
dnl Remove 4th name component, if present, from target, target_os,
dnl build and build_os. Squash all x86 cpus into one LCD form - i386
[...]
target_cpu=`echo $target_cpu | sed '[s/i[3-6]86/i386/]' | sed
'[s/powerpc/ppc/]'`
and build/rpm/GNUmakefile:
eval $(RPMPROG) -ba $$DEFS \
--target $(TARGET_CPU)-$(TARGET_VENDOR)-$(TARGET_OS) \
--clean $(SPEC)
Can someone explain why we do either of these and override distro defaults?
I cannot ... and I would think that newbie rpm packagers might have done
this wrong from the early days of making rpms.
If this is unchangeable, it may be possible to add autoconf-based
LLDLIBS=-latomic that may result in linkable binaries. However,
running the resulting binaries on an actual i386 (<< i686) hardware
may well fail with SIGILL.
Hmm ... I doubt that it is unchangeable, so we should follow standard
practice here (whatever that might be).
The SIGILL is a concern. This means (I think) that we either
(a) declare PCP is no longer supported on i386, i486 and i586, or
(b) change the build to not include pmmgr in the rpms on these platforms
(b) seems a better choice to me, but that may not be the consensus.
Of course there are non-rpm builds for old 32-bit platforms that have
not run across this problem, so I'm not sure if that is due to a
different gcc version, or different gcc flags, or the SIGILL problem is
either a non-problem or lurking undetected (I don't think any pmmgr QA
has been run on these platforms ... I'm struggling to get the build and
package working again on my QA farm, actually running QA is a yet to be
crossed bridge).
|