Quentin Spencer wrote:
Rex Dieter wrote:
Quentin Spencer wrote:
I just got a report from a user of the Octave RPM on FC4 that he got a
crash due to an illegal instruction on an old AMD K6-3. I was able to
duplicate this on a Pentium 233 (yes, I still have one), but not on my
Centrino laptop. This shouldn't happen, right? The configure command
from the spec file is:
CXXFLAGS="$RPM_OPT_FLAGS -D_GNU_SOURCE" ./configure \
--enable-shared=yes --enable-lite-kernel --enable-static=no \
--prefix=%{_prefix} --infodir=%{_infodir} --libdir=%{_libdir}
This should produce something that runs on an i386, right?
Not right.
By not using %configure, and manually using ./configure, you've built a
binary that possibly optimizes for the build-host, though $RPM_OPT_FLAGS
*should* avoid that problem. NOTE: You only set CXXFLAGS, but not
CFLAGS or FFLAGS (like what %configure does).
OK, but if the application is written in C++, isn't setting CXXFLAGS
enough? Whenever I build locally, it always looks like -march=i386 is
set in all of the compile commands. (Granted, there are some fortran
modules, but don't think the particular crash involves any of them).
Just a further update: I rebuilt octave locally on the Pentium MMX
system (it took about 10 hours yesterday to do it), so I tried
installing it and it still crashes. Even if I had mis-used the
RPM_OPT_FLAGS, because it was built locally, wouldn't this confirm that
it's a compiler bug?
Is there a reason you didn't use the %configure macro?
I think there was, but I can't remember what it is right now.
Update on this: I looked at the original version of the spec file that I
inherited from when Octave was in core, and the %configure macro was
never used even then. The configure command was:
CFLAGS="$RPM_OPT_FLAGS -fPIC -D_GNU_SOURCE" ./configure --enable-dl
--enable-shared=yes --enable-rpath --enable-lite-kernel
--enable-picky-flags --enable-static=no --with-g77 --prefix=/usr
--infodir=/usr/share/info
Most of this I have changed since I took over maintaining the package
(it never should have been CFLAGS for a C++ application, for example),
but I'm still not using %configure because I thought the -D_GNU_SOURCE
might have been important for something. Now I have my doubts. Does
anyone know what it's for?
Frankly, while it's not perfect even now, the spec file was quite a mess
when I took it over and it makes me think that core packages should be
subject to the same review process we have for Extras, as I think many
of our spec files are better as a result.
-Quentin
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
