[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: "illegal instruction" is a compiler bug, right?

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:

      --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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]