Re: $CC and intel icc/ecc compiler

[Charles Wilson]

Bob Friesenhahn wrote:

> Yes, my
>
>    CC='gcc -V 3.1.1'
>
> example is a good one since it selects the version of the tool-set to
> be used.  Most of gcc's '-m' options deserve to be specified in the CC
> specification since these specify the target architecture, and the
> compiler may need to select different startup-files, libraries,
> linker, etc, to support that target architecture.
>
> I am just using gcc as an example.  Many vendor compilers need special
> flags to enable ANSI C support, select the target ABI, or other modes.
>
> CFLAGS is only used for compilation.  LDFLAGS is used for linking.

to follow up, in many ways these options serve more to change the 
personality of the compiler itself, rather than simply modifying in some 
small way the compilation process.

e.g. 'gcc -mno-cygwin', even tho it's the same binary gcc.exe, is really 
a completely different compiler than 'gcc'.  It uses a different include 
path, and different library search path, a different set of runtime 
libraries (msvcrt.dll vs. cygwin1.dll, a windows-native libstdc++ vs 
cygwin-native libstdc++, a different set of default linked-in system 
libraries, etc).

Now, to be sure, I've always managed to work around the issue (CC=mgcc, 
where mgcc is a shell script containing simply "gcc -mno-cygwin $*") but 
that doesn't help with libtool -- because libtool is "smart".

It "knows" how to use ld to build libraries -- and sometimes this causes 
problems, by bypassing whatever magic 'gcc -mno-cygwin' does to the link 
search order, if you simply used 'gcc -mno-cygiwn' to link (instead of 
using ld directly, as libtool does).

Point: yes, the lack of this feature has caused problems (mostly minor, 
IMO) in the past.

--Chuck