GCC를 "cc"로 호출하는 것과 "gcc"로 호출하는 것

GCC를 "cc"로 호출하는 것과 "gcc"로 호출하는 것

대부분의 GNU/Linux 시스템에서 GCC는 명령줄에서 ('gcc'가 아닌 'cc'라는 이름으로) 호출할 수 있습니다.GCC가 한 방향으로 호출되었을 때와 다른 방향으로 호출되었을 때의 동작에 차이가 있습니까?

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

편집: 지금까지 받은 답변 중 GCC가 어떤 방식으로 호출될 경우 다른 방식으로 동작할지 여부에 대해 "예" 또는 "아니오"라는 명확한 답변을 주지 않았습니다.그러나 소스의 동작을 확인하기 위해 소스에 접근해야 한다는 생각이 저를 그 길로 이끌었습니다.내가 거기서 발견한 것을 바탕으로, 나는 이제 그 해답이 다음과 같다고 믿는다.

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

나도 오늘 같은 의심을 했고 나 스스로 찾으려고 노력했어

$ 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

기본적으로는 ★★★★★★★★★★★★★★★★★★★★★★★★★★★」ccgcc.

'보다 낫다'를 할 수 있어요.cc -v ★★★★★★★★★★★★★★★★★」gcc -v만약 그들이 같은 것을 인쇄한다면, 그것은 그들이 정확히 같다는 것을 의미한다.

(오래된 SUS 사양에 대한 링크)는 시스템 컴파일러에 대한 벤더 중립적인 인터페이스인 것 같습니다.레거시로 표시되어 있습니다.

c89 유틸리티는 ISO C 표준에 대한 인터페이스를 제공하지만 cc 유틸리티는 C 언어의 지정되지 않은 방언(표준 C, 공통 사용 C 또는 기타 변종)을 받아들입니다.휴대용 C 프로그램은 ISO C 표준에 적합하도록 작성되고 c89와 함께 컴파일되어야 합니다.

POSIX에는 다음 유틸리티가 있습니다.c89라고 써있네요.

c99 유틸리티는 ISO POSIX-2:1993 표준에 처음 도입된 c89 유틸리티를 기반으로 합니다.c89에서 변경된 내용에는 새로운 헤더와 옵션을 설명하기 위한 표준 라이브러리 섹션의 내용 수정이 포함됩니다.예를 들어 -lrt 오퍼랜드에 추가되고 트레이스 함수용으로 -l 트레이스 오퍼랜드가 추가되었습니다.

이러한 다양한 표준에 대해서는 잘 모릅니다만, 보다 최신의 SUSv3(POSIX:2004)와 보다 최신의 POSIX:2008(아직 SUS 번호는 없는 것 같습니다)에는, 라고 하는 유틸리티가 지정되어 있지 않은 것 같습니다.cc이상 사용할 수 없습니다만, 「」, 「」라고 하는 .c99덧붙여서, 제 Linux 시스템(Arch_Linux)에는c99 아니다c89 , ,, , called called called called called called called called called called called called 만 포함되어 .cc 둘 다 아니다c89 않다c99 :)

달려가 들어, 나는 그냥 어떻게히죽히죽 웃으면서,내가방금 추적해 봤는데를 추적했다.argv[0]gcc main.c내에서 사용됩니다( - >top_lev.c->, ->.opts.c->, ->.langhooks.c)가)같이 표시됩니다 와로 보인다.argv[0]현재 아무것도 현재사용되는 것은에게 더 많은것 뿐입니다 제공하는 단지에 사용됩니다.malloc뭔갈 때 실패할 시 신고했다.할 사항입니다 보고해야실패했을 때.여기에는 어떠한 행동 변화 만약 동작의없는 것 같습니다 변화는 표시되지 않습니다.argv[0]말이라도 이외의보다 다른 것은gcc.

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

내 비옷 mac에서에.man gcc:

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

그에 따라 저는 cc와 gcc가 같은 동작을 한다고 가정합니다.

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.

구성 스크립트에서는 Linux 시스템의 cc가 gcc일 가능성은 고려하지 않습니다.그러니, 당신의 추측을 얼마나 멀리 가져가는지 조심하라.

이 스레드는 오래된 것일 수도 있지만 뭔가 추가하고 싶습니다(아마도 나중에 누군가가 찾을 수 있을 것입니다.

이 프로그램을 컴파일한 경우

#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;
}

"gcc"를 사용하여 "AAAAAAAAAAAAAAAAAAAAAAAAA"를 인수로 전달하면 버퍼2에 오버플로가 발생하지 않지만 "cc"를 사용하여 컴파일하면 버퍼2에 오버플로가 발생합니다.이것은 "gcc"를 사용하는 경우 메모리 관리가 버퍼1과 버퍼2의 사이에 공간을 삽입함으로써 다른 동작을 할 수 있음을 암시합니다.

아마 더 경험이 많은 사람이 여기 어둠 속에 빛을 넣을 수 있을 거야.

GCC 문서에는 실행 파일명이 gcc가 아닌 cc일 경우 GCC가 다르게 동작한다는 내용은 없습니다.GNU Fortran 컴파일러는 다음과 같은 내용까지 언급하고 있습니다.

gcc 명령어 버전(시스템의 cc 명령어로 설치될 수도 있음)

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

[원래 투고에서 인용]

Ubuntu 14.04에서의 제 경험에 비추어 볼 때, 이것은 사실이 아닙니다.

다음을 사용하여 프로그램을 컴파일할 때:

gcc -finstrument-functions test.c

코드 동작에 변화가 없습니다.하지만 컴파일을 할 때는

cc -finstrument-functions test.c

동작은 다릅니다.(두 경우 모두 - finruption-functions를 작동시키기 위해 여기에 설명된 코드에 적절한 변경을 포함시켰습니다.)

UNIX에서 온 것을 생각하면, 「cc」는 범용명, 「gcc」는 실제의 컴파일러라고 말할 수 있습니다.즉, 「gcc」는 「cc」를 제공하기 때문에, 「cc」를 찾는 프로그램은, 실제로 사용되고 있는 컴파일러에 대해서는 전혀 모르고, 「cc」를 검색해 사용합니다.

또한 UNIX 프로그램은 호출에 사용되는 실제 이름을 모르기 때문에(Windows Desktop 단축키가 무엇이었는지 확인하는 것은 의미가 없습니다), "gcc"와 "cc"가 "gcc"에 대한 링크라면 "gcc"와 "gcc"와 "cc"는 같은 작업을 수행합니다.

물론 "cc"는 심볼링크가 아니라 gcc를 호출하는 셸스크립트입니다.

내 OS(우분투 14.04).cc반면 탭 완성을 허용하지 않나.gcc한다.

언급URL : https://stackoverflow.com/questions/939989/invoking-gcc-as-cc-versus-gcc