에러메시지 원인을 알았습니다. 설치를 잘못해서 일어나는 일 이더군요.
먼저 평상시대로(?) /usr/local에 설치를 하고
/etc/ld.so.conf 에 gcc라이브러리 패스를 적어주었습니다.
에러메시지 나오지 않습니다.
gcc-2.95.3은 단순히 사용자의 환경설정에 LD_LIBRARY_PATH와
LIBRARY_PATH만 적어주면 정상동작하는데 3.0.3은 ... --;;
지금으로서는 그냥 정상동작 한다는 것에 만족합니다.
==================
MPICH-1.2.3 컴파일시 다음과 같은 메시지가 나옵니다. 2.95.3으로
컴파일 할때는 조용하더군요. Redhat 7.2(updated) + Ximian
삽질하실때 참고하세요. 아래 질문이냐 팁이냐 물었는데 물음표는 제가
지식이 짧아서 단순히 MPICH에서 뱉어낸 쓰레기인지 실제로 존재하는
버그인지 몰라서 입니다. 그리고 MPICH 컴파일시 컴파일러며 기타등등을
지정해주어야 한다고 말씀하시는데 정말 기억이 가물가물 할 정도로
오래전에 작업해본 것 같군요. 시간이 있으면 아래 메시지들을 손수
일일이 테스트 해보겠는데 그렇지 못합니다.
좋아진 점은 2.95.3으로 컴파일할때 40분 걸리던 것이 gcc-3.0.3 로
하면 10분 정도로 컴파일 시간이 단축되더군요.(C++ 고급(?)기능사용시)
나빠진 점은 그렇게 컴파일된 코드가 2.95.3으로 컴파일 한 것보다
실행속도가 25배 가량 느리지더군요. 어디까지나 제가 사용하는
라이브러리에 국한된 이야기 입니다. 지금은 다시 2.95.3을 사용합니다. --;;
===
방금 확인했는데 MPICH-1.2.3소스안에 C 버그 체크하는 프로그램이 있네요.
버그 있는 것 맞습니다. mpich-1.2.3/ccbugs 안에 보면 여러가지 버그를
체크하는 C 프로그램이 있습니다. 그것을 컴파일해서 결과를 확인하는 모양인데
공학하시거나 중요한 프로그램 작성하시는 분들은 3.0.3 을 사용하지
않는 것이 좋겠군요.
그런데 mpich-1.2.3/ccbugs 에서 에러난다는 소스를 3.0.3으로 컴파일
해보았는데 에러(틀린 결과)가 나오지 않네요. --;; 허참. 암튼 찝찝하니깐...
===
2.95.3으로 바꾸었는데 예전의 성능이 나오지 않는군요. 업데이트 된
라이브러리에 문제가 있는 모양입니다. 이거 깨끗이 밀고 새로 깔은 것인데
아무래도 다시 밀어보아야 겠습니다. 지미안을 설치하지 말던가... ㅜ.ㅜ
checking for correct handling of #elif... no
*# ******************************************************************
*# * Your C compiler can not properly handle the #elif preprocessor *
*# * directive. Report the problem to your vendor; you may want to *
*# * using the GNU C compiler instead. *
*# * *
*# * Please file a bug report with your vendor. If you do not get *
*# * satisfaction from your vendor, we suggest that you consider *
*# * gcc. *
*# * *
*# ******************************************************************
Output from compile step was:
In file included from /usr/include/_G_config.h:44,
from /usr/include/libio.h:32,
from /usr/include/stdio.h:65,
from conftest.c:18:
/usr/include/gconv.h:172: array size missing in `__data'
checking that constant folding in arrays works... yes
checking that compiler truncates unsigned char correctly ...... no
*# ******************************************************************
*# * YOUR C COMPILER HAS A BUG!!!!!! *
*# * *
*# * Your C compiler fails to properly handle truncations of data *
*# * to unsigned char properly. This should not affect MPICH but *
*# * may cause errors in user programs and in some parts of the *
*# * MPICH test suite. *
*# * *
*# * You may find that the compiler will generate correct code *
*# * a lower levels of optimization. *
*# ******************************************************************
Output from compile step was:
In file included from /usr/include/_G_config.h:44,
from /usr/include/libio.h:32,
from /usr/include/stdio.h:65,
from conftest.c:1:
/usr/include/gconv.h:172: array size missing in `__data'
checking that compiler/hardware has commutative arithmetic ...... no
*# ******************************************************************
*# * YOUR C COMPILER / HARDWARE HAS NON-COMMUTATIVE ARITHMETIC!!! *
*# * *
*# * Your C compiler believes that x*y-y*x can be different from *
*# * zero. This may be the result of inconsistent rounding in *
*# * your computers hardware when multiply-add instructions are *
*# * used. *
*# * *
*# * On some systems, a Multiply-Add combination whose results are *
*# * different from a Multiply and an Add can cause this to happen. *
*# * Results on this system, if it alleges to be IEEE, will differ *
*# * from IEEE systems where arithmetic is commutative. *
*# * *
*# * At least one vendor views this behavior as a feature; if *
*# * commutative arithmetic is important to you, consider using *
*# * compilation options to reduce the amount of optimization or *
*# * eliminate the use of Multiply-Add (this may reduce *
*# * performance but will make it possible to compare computations *
*# * on different systems). *
*# * *
*# ******************************************************************
Output from compile step was:
In file included from /usr/include/_G_config.h:44,
from /usr/include/libio.h:32,
from /usr/include/stdio.h:65,
from conftest.c:1:
/usr/include/gconv.h:172: array size missing in `__data'
checking that compiler assigns to char correctly ...... no
*# ******************************************************************
*# * YOUR C COMPILER HAS A BUG!!!!!! *
*# * *
*# * Your C compiler fails to properly handle assignments or *
*# * references to char arrays properly when the most significant *
*# * bit in the character bit is set. This should not affect MPICH *
*# * but may cause errors in user programs and in some parts of the *
*# * MPICH test suite. *
*# * *
*# * You may find that the compiler will generate correct code *
*# * a lower levels of optimization. *
*# ******************************************************************
Output from compile step was:
In file included from /usr/include/_G_config.h:44,
from /usr/include/libio.h:32,
from /usr/include/stdio.h:65,
from conftest.c:1:
/usr/include/gconv.h:172: array size missing in `__data'
checking that compiler does not call unknown routines for long doubles... yes
checking that compiler accepts args correctly ...... no
*# ******************************************************************
*# * YOUR C COMPILER IS SERIOUSLY BROKEN!!!!!! *
*# * *
*# * Your C compiler fails to accept macro definitions to strings *
*# * with embedded blanks. This often means that your compiler is *
*# * improperly implemented as a shell script. You should file a *
*# * bug report and require a fix *
*# * *
*# * MPICH is able to work around this bug; however, any compiler *
*# * that can not handle this simple case is highly suspect. *
*# * *
*# * You may find that the compiler is an sh script with a *
*# * statement containing $*. This is a common error; consider *
*# * replacing $* with "$@". *
*# ******************************************************************
*#
--
장미가 장미라는 것은 장미인가?