|
From: | Charles Wilson |
Subject: | Re: $CC and intel icc/ecc compiler |
Date: | Wed, 09 Apr 2003 23:18:05 -0400 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |