"illegal instruction" is a compiler bug, right?

[Quentin Spencer]

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