GCC를 "cc"대 "gcc"로 호출

GCC를 "cc"대 "gcc"로 호출

---

대부분의 GNU / 리눅스 시스템에서 GCC는 명령 줄에서 "cc"라는 이름으로 호출 될 수 있다는 것을 알고 있습니다 ( "gcc"가 아니라). GCC가 한 방식으로 호출 될 때 다른 방식으로 호출 될 때 GCC의 동작에 차이가 있습니까?

예를 들어, "gcc"대신 "g ++"라는 이름을 통해 GCC를 호출하면 GCC가 다르게 동작한다는 것을 알고 있습니다 (.c 파일을 C ++ 표준 라이브러리에서 C ++ 소스 및 링크로 처리). "gcc"와 "cc"사이에 유사한 동작 차이가 있습니까?

편집 : 지금까지받은 답변 중 어느 것도 GCC가 한 방향으로 호출되는 경우 다른 방식으로 작동하는지 여부에 대해 명확한 "예"또는 "아니오"를 제공하지 않았습니다. 그러나 그 행동을 확인하기 위해 소스에 뛰어들라는 아이디어는 나를 그 길로 인도합니다. 내가 찾은 것을 바탕으로 나는 이제 대답이 다음과 같다고 믿습니다.

아니요. GCC는 "gcc"또는 "cc"를 통해 호출되는지 여부에 관계없이 동일하게 작동합니다 .

---

grins의 경우 argv[0]gcc ( main.c-> top_lev.c-> opts.c-> langhooks.c) 내에서 사용되는 방법을 추적 했으며 argv[0]현재 malloc실패시보고 할 것을 제공하는 것 이상으로 사용되는 것으로 보입니다 . 가 argv[0]이외의 경우 동작 변경이없는 것으로 보입니다 gcc.

---

그것은 나에게 보인다 cc(오래된 SUS 사양에 대한 링크가) 시스템의 컴파일러에 대한 벤더 중립적 인 인터페이스하기위한 것입니다. 레거시로 표시됩니다.

c89 유틸리티는 ISO C 표준에 대한 인터페이스를 제공하지만 cc 유틸리티는 C 언어의 지정되지 않은 방언을 허용합니다. 표준 C, 공용 C 또는 기타 변형 일 수 있습니다. 이식 가능한 C 프로그램은 ISO C 표준을 준수하도록 작성하고 c89로 컴파일해야합니다.

POSIX라는 유틸리티가 c99나는의 후속 믿습니다 c89. 그것은 말한다

c99 유틸리티는 원래 ISO POSIX-2 : 1993 표준에 도입 된 c89 유틸리티를 기반으로합니다. c89의 일부 변경 사항에는 새 헤더 및 옵션을 고려하여 표준 라이브러리 섹션의 내용에 대한 수정이 포함됩니다. 예를 들어, -l rt 피연산자에 추가되고 -l 추적 피연산자가 추적 기능에 추가되었습니다.

나는 모든 다른 표준에 익숙하지 않지만 최신 SUSv3 ( POSIX : 2004 ) 및 최근 POSIX : 2008 (아직 SUS 번호가없는 것 같음)처럼 유틸리티를 지정하지 않습니다. cc더 이상 호출 되지만 c99. 덧붙여, 내 리눅스 시스템 ( Arch_Linux은 )의 맨 페이지가 포함되어 c99있지만이 c89있지만라는 유틸리티가 포함되어 cc있지만,도, c89도 c99. 거기에 많은 혼란 :)

---

내 Mac에서 man gcc:

Apple의 GCC 버전에서 cc와 gcc는 실제로 gcc-version과 같은 이름의 컴파일러에 대한 심볼릭 링크입니다. 마찬가지로 C ++ 및 g ++는 g ++ 버전과 같은 이름의 컴파일러에 대한 링크입니다.

이를 바탕으로 cc와 gcc가 같은 방식으로 작동한다고 가정합니다.

---

나는 오늘도 똑같은 의구심을 가지고 있었고 스스로 찾아 보려고 노력했습니다.

$ which cc
 /usr/bin/ccc

$file /usr/bin/cc
 /usr/bin/cc: symbolic link to '/etc/alternatives/cc'

$file /etc/alternatives/cc
 /etc/alternatives/cc: symbolic link to '/usr/bin/gcc'

$which gcc
 /usr/bin/gcc

그래서, 기본적으로 cc가리키는 gcc.

cc -v및을 사용하여 확인할 수도 있습니다 gcc -v. 그들이 똑같은 것을 출력한다면 그것은 정확히 똑같다는 것을 의미합니다.

---

gcc가 argv [0]의 값과 독립적으로 동일하게 작동하더라도 컴파일러로 지정하는 것과 상관없이 모든 소프트웨어가 동일하게 작동하는 것은 아닙니다.

RHEL 5.5 (gcc 4.1.2)에서 zlib 1.2.5를 빌드하는 경우 :

$ md5sum $(which cc)
69a67d3029b8ad50d41abab8d778e799  /usr/bin/cc
$ md5sum $(which gcc)
69a67d3029b8ad50d41abab8d778e799  /usr/bin/gcc

그러나:

$ CC=$(which cc) ./configure
Checking for shared library support...
Tested /usr/bin/cc -w -c -O ztest20557.c
Tested cc -shared -O -o ztest20557.so ztest20557.o
/usr/bin/ld: ztest20557.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
ztest20557.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
No shared library support; try without defining CC and CFLAGS
Building static library libz.a version 1.2.5 with /usr/bin/cc.
Checking for off64_t... Yes.
Checking for fseeko... Yes.
Checking for unistd.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.

과:

$ CC=$(which gcc) ./configure
Checking for shared library support...
Building shared library libz.so.1.2.5 with /usr/bin/gcc.
Checking for off64_t... Yes.
Checking for fseeko... Yes.
Checking for unistd.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.
Checking for attribute(visibility) support... Yes.

configure 스크립트는 Linux 시스템의 cc가 gcc 일 가능성을 고려하지 않습니다. 그래서, 당신이 당신의 가정을 얼마나 멀리 받아들이는지 조심하십시오.

---

cc는 컴파일러를 호출하는 UNIX 방식 일 뿐이며 모든 Unices에서 작동합니다.

---

이 스레드는 오래되었을 수 있지만 여기에 무언가를 추가하고 싶습니다 (아마도 누군가가 나중에 찾을 수있을 것입니다).

If you compiled this program

#include <stdio.h>
#include <stdlib.h>

void
myFunction(char *args)
{
   char buff1[12];
   char buff2[4] = "ABC";

   strcpy(buff1,args);

   printf("Inhalt Buffer2: %s",buff2);

}

int main(int argc, char *argv[])
{

   if(argc > 1)
   {
      myFunction(argv[1]);
   }
   else
      printf("no arguments sir daimler benz");

   getchar();

   return 0;
}

with "gcc", and you pass it "AAAAAAAAAAAAAAAAAAAAAAAAA" as argument, it will not overflow into buffer2, while it DOES if you compiled with "cc", which for me is a hint that if you used "gcc", the memory management works different, maybe by putting space between the memory segments of the fields buff1 & buff2 ?

Maybe someone with more experiance can put light into the darkness here.

---

Nothing in the GCC documentation indicates that GCC would behave any differently if its executable name is not gcc but cc. The GNU Fortran compiler even mentions that:

A version of the gcc command (which also might be installed as the system's cc command)

---

"No. GCC behaves the same regardless of whether it is called via 'gcc' or 'cc'."

[Quoted from original post.]

Based on my experienced in Ubuntu 14.04, this hasn't been the case.

When I compile my program using:

gcc -finstrument-functions test.c

I don't get any change in the behavior of my code. But when I compile using

cc -finstrument-functions test.c

It does behave differently. (In both cases, I incorporated the appropriate changes into my code described here to make -finstrument-functions work).

---

Considering this is coming from UNIX, I'd say that "cc" is the generic name and "gcc" is the actual compiler. i.e. "gcc" provides "cc" so a program looking for "cc" would find and use "cc", blissfully ignorant of the actual compiler being used.

Also, UNIX programs should be ignorant of the actual name used to call them (think Windows Desktop shortcuts -- it doesn't make sense to check what the shortcut was called), so, no, "gcc" and "cc" do the same thing if "cc" is a link to "gcc".

Unless, of course, "cc" is not a symlink but a shellscript calling gcc.

---

For my OS (Ubuntu 14.04) cc doesn't allow tab completion, whereas gcc does.

참고URL : https://stackoverflow.com/questions/939989/invoking-gcc-as-cc-versus-gcc