[PATCH] Fix CFLAGS overwrite by Makefile

[Andriy Gapon]

on 25/05/2011 15:25 Ruslan Ermilov said the following:
> On Tue, May 24, 2011 at 11:08:52PM -0400, Arnaud Lacombe wrote:
>> Hi,
>>
>> On Tue, May 24, 2011 at 10:54 PM, Arnaud Lacombe <lacombar at gmail.com> wrote:
>>> ps: for static library and loader, I derived the total size as the sum
>>> of the size of the text/data/bss section of the member object using :
>>>
>>> size *.o | awk 'BEGIN {text=0; data=0; bss=0;}; {text+=$1; data+=$2;
>>> bss+=$3}; END {print text " " data " " bss " '$i'"}'
>>>
>>> where $i is the cpu type to test. make(1) is passed either CPUTYPE=$i
>>> for i in i[3456]86, or the empty string. The compiler used for the
>>> test is gcc, and it is the compiler build during a buildworld stage,
>>> in the tmp directory.
>>>
>> just to cut loose any question about my environment, additionally to
>> the original patch, I made the following modification to the tree to
>> try to isolate it from the host:
>>  - applied the following patch:
> 
> [...]
> 
>>  - manually created two symlinks:
>>  1) include/machine -> ../sys/i386/include/
>>  2) include/x86 -> ../sys/x86/include/
>>
>> The host is running a custom 8.2-STABLE/amd64 kernel (only config
>> change) on the following CPU:
>>
>> CPU: Intel(R) Xeon(R) CPU           X3430  @ 2.40GHz (2394.00-MHz K8-class CPU)
>>   Origin = "GenuineIntel"  Id = 0x106e5  Family = 6  Model = 1e  Stepping = 5
>>  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>>   Features2=0x98e3fd<SSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT>
>>   AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
>>   AMD Features2=0x1<LAHF>
>>   TSC: P-state invariant
>>
>> I am still not sure what is the default gcc target architecture on this machine.

Default target architecture should not depend on current machine.
It is in gcc manual page:
generic
    Produce code optimized for the most common IA32/AMD64/EM64T
    processors.  If you know the CPU on which your code will run,
    then you should use the corresponding -mtune option instead of
    -mtune=generic.  But, if you do not know exactly what CPU users
    of your application will have, then you should use this option.

    As new processors are deployed in the marketplace, the behavior
    of this option will change.  Therefore, if you upgrade to a
    newer version of GCC, the code generated option will change to
    reflect the processors that were most common when that version
    of GCC was released.

    There is no -march=generic option because -march indicates the
    instruction set the compiler can use, and there is no generic
    instruction set applicable to all processors.  In contrast,
    -mtune indicates the processor (or, in this case, collection of
    processors) for which the code is optimized.
...
i686
    Same as "generic", but when used as "march" option, PentiumPro
    instruction set will be used, so the code will run on all i686
    family chips.

> Why not go along a supported way, and do a cross-build?

There is nothing wrong about the day he does it.
And a classic cross-build won't help with setting i586 or lower that he needs:

i586, pentium
    Intel Pentium CPU with no MMX support.

Just my 2 cents.
-- 
Andriy Gapon