sudo apt-get install ruby-full rubygems
sudo su -
export REALLY_GEM_UPDATE_SYSTEM=true
gem update --system
exit
gem install rails

/usr/bin/ruby1.8 extconf.rb
checking for sqlite3.h... no
sqlite3.h is missing. Try 'port install sqlite3 +universal' or 'yum install sqlite3-devel'
*** extconf.rb failed ***


Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

sudo apt-get install libsqlite3-dev

<출처 플리커 - http://www.flickr.com/photos/jessfeldon/3359967900/sizes/z/in/photostream/>

<만들면서 배우는 리스프 프로그래밍, 한빛미디어 - 출처 yes24>

"만들면서 배우는 리스프 프로그래밍"이 만화책같다면 "카산드라 완벽 가이드"는 교과서같은 느낌입니다. 카산드라라는 분산 DB가 탄생한 이유부터 구축, 적용까지 광범위한 내용을 다루고 있더라구요. 제가 DB 쪽은 아직 깊이 다루어본 적이 없어서 NoSQL이 필요한 이유같은 부분에서 약간 공감이 적긴하지만, 나름대로 조금씩 읽고 있습니다. ^^;;;;

언젠가는 저도 NoSQL이 필요한 시점이라고 느낄날이 올지도 모르니까요. ㅎㅎ 카산드라에 대해서 궁금하신 분이라면 이 책을 한 번 보시는 것도 괜찮을 것 같습니다. ^^)/~

<카산드라 완벽 가이드, 한빛미디어 - 출처 yes24>

굵게 표시된 부분이 오타가 수정된 부분입니다.

==== 1권의 오탈자 내용 ====

*. 79 Page, 아래에서 5 번째 줄

보호 모드는 IA-32e 모드로 전환하려면 공식적으로 거쳐야 하는 모드로, 32비트 윈도우나 리눅스 OS가 동작하는 기본 모드입니다.

*. 80 Page, 위에서 6 번째 IA-3e 모드를 IA-32e 모드로 수정

IA-32e 모드

*. 80 Page, 아래에서 5 번째줄

리얼 모드에서 전환할 수 있는 모드는 공식적으로 보호 모드뿐 이며, 보호 모드에서는 가상 8086 모드나 IA-32e 모드, 다시 리얼 모드로 전환할 수 있습니다. 시스템 관리 모드는 모든 모드에서 진입할 수 있고, 처리가 끝나 이전의 운영 모드로 복귀하거나 리셋을 통해 리얼 모드로 진입할 수 있습니다.

*. 80 Page, 아래에서 3 번째 줄

화살표가 연결되지 않은 리얼 모드에서 IA-32e 모드로 전환하는 것은 불가능하며, 무리하게 시도하면 리셋이나 예외가 발생할 수있습니다(실제 편법을 사용하면 가능하긴 하지만 여기서는 다루지 않습니다).

*. 83 Page, [그림 3-3]에서 128비트 XMM 레지스터(16개), 64비트 RIP, 64비트 RFLAGS, CR8 레지스터 부분 수정됨

*. 85 Page의 "여기서 잠깐"의 시작에서 6번째 줄

곱셈 명령은 AX와 오퍼랜드를 곱한 후, 그 결과를 DX:AX나 혹은 AX에 저장하도록 설계되었습니다.

*. 87 Page 아래에서 5번째 줄부터...

그렇다면 어떻게 해야 할까요? 프로세서 제조사에서는 이런 경우를 대비하여 무조건 분기 명령어(jmp)에 예외를 두었습니다.

즉, 무조건 분기 명령어의 오퍼랜드의 크기는 기본 64비트로 하여 전체 어드레스 범위에서 이동이 가능하도록 한 것입니다.

[그림 3-5]는 RIP 상대 어드레스를 사용하여 표현 가능한 어드레스 영역과 무조건 분기 명령어를 사용해서 접근할 수 있는 영역에 대해

나타낸 것입니다.

*. 88 Page [그림 3-5]

*. 113 Page 아래에서 8번째 줄

그 위쪽에서 두 파일은 a.c와 b.c로부터 생성되는 것을 알 수 있습니다.

*. 141 Page 위에서 6번째 줄, 154 Page 아래서 5번째 줄, 2861 Page 위에서 7번째 줄, 2872 Page 맨 밑줄

xor byte [ HEADNUMBER ], 0x01 ; 헤드 번호를 0x01과 XOR 하여 토글(0->1, 1->0)

*. 142 Page, 아래서 3번째줄

x86 프로세서의 스택은 [그림 5-3]과 같이 데이터가 삽입될 때마다 스택의 상위(Top)를 나타내는 스택 포인터 레지스터(SP)가 낮은 어드레스(0x00에 가까운 어드레스)로 이동합니다.

*. 143 Page, 밑에서 10째줄

또한 스택은 넉넉한 것이 좋으므로 스택 포인터 레지스터(SP)와 베이스 포인터 레지스터(BP)를 0xFFFF로 설정하여, 스택 영역의 크기를 세그먼트의 최대 크기로 지정하겠습니다.

*.149 Page, 아래에서 13번째 줄

        ret 12                   ; 호출한 함수로 복귀한 후, 스택에 삽입된 파라미터 3개를 제거(3*4) "ret" "add esp, 12"와 같은 역할

        ^^^^^^

            ret 수행 후 스택 포인터(SP)를 12만큼 더함. 보호모드 코드이므로

            레지스터의 기본 크기 및 스택의 기본 크기가 32비트(4바이트)이기 때문에 4*3 = 12만큼 더함

*.151 Page, 위에서 15번째 줄

        ret 4                     ; 호출한 함수로 복위한 후, 스택에 삽입된 파라미터 1개를 제거(1*4) "ret" "add esp, 4"와 같은 역할

        ^^^^^^^

             ret 수행 후 스택 포인터(SP)를 4만큼 더함. 보호 모드 코드이므로

             레지스터의 기본 크기와 스택의 기본 크기가 32비트(4바이트)이기 때문에 4*1 = 4만큼 더함

*. 161 Page, 아래서 5번째줄 Code

; 512 - ( $ - $$ ) % 512 : 현재부터 어드레스 512까지

*. 213 Page, 가장 아래번째 줄

보호 모드 엔트리 포인트(EntryPoint.s) 코드에서 최초로 실행되는 C 코드입니다.

*. 251 Page, [그림 9-2] 페이지 디렉터리 엔트리 부분에서 PS1을 PS로 수정

*. 261 Page, 위에서 4번째 줄

kSetPageEntryData( &( pstPML4TEntry[ 0 ] ), 0x00, 0x101000, PAGE_FLAGS_DEFAULT, 0 );

*. 263 Page, [그림 9-5]의 XMSE를 SMXE로 수정

*. 266 Page, 소스 코드에서 위에서 10째줄

// 1 비트 P, RW, US, PWT, PCD, A, D, PS, G, 3 비트 Avail, 1 비트 PAT, 8 비트 Reserved,

*. 283 Page, [표 10-2] IA32_EFER 레지스터의 비트 구성에서 7번째 줄 LMA 항목

LMA 읽기 전용 -1로 설정되면 프로세서 모드가 IA-32e 모드(호환 모드 또는 64비트 모드)임을 나타내며, 0으로 설정되면 프로세서 모드가 기타 모드임을 나타냄

*.283 Page, 밑에서 10째줄

[표 10-2]에서 보는 것과 같이 IA-32e 모드 활성화 여부는 비트 8에 위치하는 LME 비트와 관계가 있고 이 비트를 1로 설정하면 IA-32e 모드를 활성화할 수 있습니다.

*.288 Page [예제 10-2] 위에서 1째줄

#ifndef __MODESWITCH_H__

#define __MODESWITCH_H__

*. 333 Page 아래쪽과 351 Page 가운데 부분, 482 Page 윗부분

BOOL kChangeKeyboardLED( BOOL bCapsLockOn, BOOL bNumLockOn, BOOL bScrollLockOn )

{

    int i, j;

    // 키보드에 LED 변경 커맨드 전송하고 커맨드가 처리될 때까지 대기

    for( i = 0 ; i < 0xFFFF ; i++ )

    {

        // 입력 버퍼(포트 0x60)가 비었으면 커맨드 전송 가능

        if( kIsInputBufferFull() == FALSE )

        {

            break;

        }

    }

...   생략 ...

*. 334 Page 위에서 3번째 줄

// 입력 버퍼(포트 0x60)로 LED 상태 편경 커맨드(0xED) 전송

kOutPortByte( 0x60, 0xED );

... 생략 ...

*. 341 Page 위에서 15번째 줄, 357 Page 아래에서 5번째 줄

BOOL kIsUseCombinedCode( BYTE bScanCode )

*. 341 Page, 위에서 18번째 줄, 357 Page, 아래에서 2번째 줄

BOOL bUseCombinedKey = FALSE;

*. 343 Page 아래쪽과 359 Page 가운데 부분

void UpdateCombinationKeyStatusAndLED( BYTE bScanCode )

{

    BOOL bDown;

    BYTE bDownScanCode;

    BOOL bLEDStatusChanged = FALSE;

    // 눌림 또는 떨어짐 상태처리, 최상위 비트(비트 7)가 1이면 키가 떨어졌음을 의미하고

    // 0이면 눌림을 의미함

    if( bScanCode & 0x80 )

    {

        bDown = FALSE;

        bDownScanCode = bScanCode & 0x7F;

    }

    else

    {

        bDown = TRUE;

        bDownScanCode = bScanCode;

    }

// 키보드의 상태를 관리하는 자료구조

typedef struct kKeyboardManagerStruct

{

    // 조합 키 정보

    BOOL bShiftDown;

    BOOL bCapsLockOn;

    BOOL bNumLockOn;

    BOOL bScrollLockOn;

    

    // 확장 키를 처리하기 위한 정보

    BOOL bExtendedCodeIn;

    int iSkipCountForPause;

} KEYBOARDMANAGER;

*. 365 Page, 아래에서 12번째 줄

BOOL kIsUseCombinedCode( BYTE bScanCode );

*. 365 Page, 아래에서 17번째줄 변수 선언 부분 굵게 처리

void Main( void )

{

    char vcTemp[ 2 ] = {0, };

    BYTE bFlags;

    BYTE bTemp;

    int i = 0;

    ... 생략 ...

*. 383 Page의 [그림 12-7]에서 16~31 비트의 값(크기를 기준 주소로 수정)

*. 386 Page, 위에서 21번째 줄 30번째 줄

#define GDT_FLAGS_LOWER_TSS ( GDT_FLAGS_LOWER_DPL0 | GDT_FLAGS_LOWER_P ) 

#define GDT_FLAGS_UPPER_TSS ( GDT_FLAGS_UPPER_G )

*. 428 Page 아래에서 18번째 줄, 436 Page 아래에서 3번째 줄, 600 Page 아래에서 9번째 줄, 606 Page 위에서 7번째 줄

%macro KLOADCONTEXT 0      ; 파라미터를 전달받지 않는 KLOADCONTEXT 매크로 정의

*. 483 Page, 위에서 10번째 줄, 굵게 표시

// 키를 저장하는 큐와 버퍼 정의

static QUEUE gs_stKeyQueue;

static KEYDATA gs_vsKeyQueueBuffer[ KEY_MAXQUEUECOUNT ];

*. 492 Page의 위쪽

사실 14장은 앞 장과 비교해서 변한 것이 거의 없습니다.

*. 498 Page의 "GCC 헤더 파일에 정의된 가변 인자 매크로와 리스트"의 위쪽 문단

각 매크로와 데이터 타입이 어떻게 정의되어 있는지 코드를 직접 확인해 보겠습니다.

*. 609 Page, 첫 번째 줄  굵게 표시

{ "createtask", "Create Task", kCreateTestTask },

*. 627 Page, "TCB 할당 및 해제 함수의 코드"에서 위로 2번째 줄

다음은 앞서 설명한 내용에 따라 구현한 TCB 할당 및 해제 함수의 코드입니다. ID를 처리하는 부분을 제외하고는 평이한 코드이므로

이해하는데 큰 어려움이 없을 것입니다. TCB 자료구조에 추가된 stLink 필드는 18.2.4절에서 살펴보겠습니다.

*. 660 Page의 위에서 4째줄

콘솔 화면의 주변을 돌면서 문자를 출력하는 태스크와 자신의 ID에 해당하는 위치에 바람개비를 출력하는 태스크를 작성했습니다.

*. 741 Page 위에서 7 번째 줄

태스크의 수를 제한하려면 임계 영역 진입 여부를 나타내는 플래그와 잠금 횟수를 나타내는 카운터, 그리고 임계 영역에 진입한 태스크의 ID만 있으면 처리할 수 있습니다.

*. 742 Page 아래에서 8번째 라인

만약 잠근 태스크가 해제를 요청하는 것이고 잠긴 횟수가 2 이상이면 중복으로 잠긴 것이므로 횟수만 1 감소시키고 실제로 해제하는 작업은 수행하지 않습니다.

*. 751 Page 그림 [20-4]

*. 769 Page 맨 윗 라인

콘솔 셸 파일에는 태스크를 생성하고 종료하는 태스트 때문에 killtask 커맨드의 기능이 수정되고 동기화 기능을 테스트하는 testmutex 커맨드가 추가되었습니다.

*. 791 Page의 밑에서 셋째줄

하지만 멀티코어 프로세서 환경일 경우 자식 스레드는 다른 코어에서 실행될 수 있으며, 이런 경우 태스크를 즉시 대기 리스트로 옮길 수 없습니다.

*. 815 Page의 밑에서 8째줄

[그림 21-4]의 위를 보면 콘솔 셸(태스크 ID: 0x100000000)과 유휴 태스크(태스크 ID: 0x200000001)의 태스크 플래그를 보면 최상위 바이트가 각기 0x60과 0x58로 시작하는 것을 볼 수 있습니다.

*. 825 Page [그림 22-2]

* 843 Page, 밑에서 10 째줄

또 FPU 예외 처리가 끝나면 다시 0으로 설정해서 같은 태스크가 FPU를 사용할 때 예외가 발생하지 않도록 해야 합니다.

* 876 Page, 밑에서 두번째 줄

1KB 블록 2개를 생성한 후 1KB 블록 하나를 할당해주면 남은 블록은 [그림 23-3]과 같이 1KB 블록 1개, 2KB 블록 1개, 4KB 블록 1개가 됩니다.

* 933 Page 위에서 7 째줄

하지만, LBA 어드레스 모드일 때는 레지스터가 LBA 어드레스로 통합되어 섹터 번호 레지스터는 LBA 어드레스의 0비트~7비트, 실린더 LSB 레지스터는 8비트~15비트, 실린더 MSB 레지스터는 16비트~23비트, 드라이브/헤드 레지스터의 헤드 필드는 24비트~27비트를 저장합니다.

* 1049 Page, 위에서 6번째 줄 자료구조에서 아래의 굵게된 부분 추가

* 1120 Page 위에서 6 째줄

// 파일 이름 삽입

kMemCpy( vcBuffer, pstentry->d_name, kStrLen( pstEntry->d_name ) );

* 1161 Page, [그림 27-5]의 가장 마지막 부분

*. 1174 Page, 위에서 11 번째 줄

iRealReadCount = MIN( gs_stRDDManager.dwTotalSectorCount -

dwLBA, iSectorCount );

*. 1174 Page, 밑에서 9 번째 줄

iRealWriteCount = MIN( gs_stRDDManager.dwTotalSectorCount -

dwLBA, iSectorCount );

*. 1186 Page, 밑에서 16 번째 줄

iRealReadCount = MIN( gs_stRDDManager.dwTotalSectorCount -

dwLBA, iSectorCount );

*. 1186 Page, 밑에서 2 번째 줄

iRealWriteCount = MIN( gs_stRDDManager.dwTotalSectorCount -

dwLBA, iSectorCount );

*. 1239 Page, 위에서 10째줄과 13째줄

// LSB 제수 래치 레지스터(포트 0x3F8)에 제수의 하위 8비트를 전송

// MSB 제수 래치 레지스터(포트 0x3F9)에 제수의 상위 8비트를 전송

*. 1246 Page, 위에서 2째줄과 5째줄

// LSB 제수 래치 레지스터(포트 0x3F8)에 제수의 하위 8비트를 전송

// MSB 제수 래치 레지스터(포트 0x3F9)에 제수의 상위 8비트를 전송

 

*. 1655 Page, 위에서 5번째 줄

브레슨햄 직선 알고리즘을 사용한 선 그리기 함수의 코드 - 최적화 후

*. 1672 Page, 35.2.1절에서 아래로 8번째줄

하지만, 문자 정보가 비트맵으로 들어 있으므로 확대하거나 축소했을 때 문자가 깨끗하게 표시되지 않고, 굵게하거나 기울일려면 해당 스타일의 비트맵을 모두 생성해야하는 단점이 있습니다.

*.1764 Page, 아래에서 10번째줄, kDrawMouse -> kDrawCursor로 수정

kDrawCursor( &stScreenArea, pstVideoMemory, iX, iY );

*. 1882 Page, 위에서 7번째 줄

이 절에서 작성할 윈도우 매니저는 더 이상 테스트 코드가 아닌 실제 코드로서, 키보드와 마우스 데이터를 이용해 윈도우로 이벤트를 전달하는 기능과 업데이트를 수행하는 기능을 구현합니다.

*. 1946 Page, 위에서 4번째 줄

//----------------------------------------------------------------------------------------------

// 제목 표시줄 그리기

//----------------------------------------------------------------------------------------------

// 제목 표시줄을 채움

kInternalDrawRect( &stArea, ... 생략 ...)

*. 1951 Page, 위에서 6번째 줄

39장의 내용을 MINT64 OS에 추가한 뒤 make를 입력하면 Disk.img 파일이 생성됩니다.

*. 1994 Page, 위에서 6번째 줄 제목

41.1.1 Z 순서의 가장 아래에서 위로 그리는 알고리즘의 문제점

*. 1998 Page, 위에서 3번째 줄

윈도우 1은 자신의 영역에 포함된 픽셀 오프셋 5~7 부분을 비디오 메모리로 전송한 뒤 해당 영역의 비트맵을 모두 0으로 표시합니다.

*. 2027 Page, 아래에서 3번째 줄

특히 마우스 데이터를 처리하는 부분과 화면 업데이트 요청을 처리하는 부분은 조금만 수정하면 화면 업데이트 횟수를 많이 줄일 수 있기 때문에 속도에 목마른 우리에겐 아주 중요한 포인트입니다.

*. 2150 Page, 위에서 첫번째 줄

43장에서는 프로세서의 정보와 메모리 정보를 표시하는 시스템 모니터 태스크를 구현해 봤습니다. 

*. 2150 Page, 위에서 6번째 줄

44장에서는 다시 고전으로 돌아가 역사의 뒤안길로 사라졌던 콘솔 셸을 GUI 버전으로 부활시킬 것입니다.

*. 2169 Page, 위에서 7번째 줄 도움말

while( kGetKeyFromGUIKeyQueue( &stData) == FALSE)

        |---------- 그래픽 모드용 키 큐에서 데이터를 꺼내는 함수

*. 2182 Page, "44.3.2 콘솔 파일 수정"에서 아래 첫번째 줄

콘솔 파일은 그래픽 모드 지원을 위해 입출력 함수의 코드를 일부 수정하고, 그래픽 모드용 화면 버퍼와 키 큐를 추가했습니다.

*. 2309 Page 전체를 아래 내용으로 교체

*. 2400 Page, 아래에서 4번째 줄

MINT64 OS에는 아직까지 MSR에 읽고 쓰는 함수가 없으므로 MSR에 관련된 어셈블리어 함수부터 만들겠습니다.

*. 2546 Page, "[표 50-2] e_entry 필드의 세부 구성과 의미"를 "[표 50-2] e_ident[16] 필드의 세부 구성과 의미"로 변경

*. 2546 Page, 아래에서 7번째 줄

가장 먼저 할 일은 e_ident 필드의 상위 4바이트가 매직 넘버이므로, 파일의 첫 4바이트가 매직 넘버와 일치하는지를 검사하여 올바른 ELF64 파일인지 확인하는 것입니다.

*. 2548 Page, 아래에서 5번째 줄

현재 섹션의 타입에 따라 필드의 의미가 달라지며 자세한 내용은 [표50-6]을 참조

*. 2616 Page, 위에서 첫번째 줄

[그림 51-2]는 이러한 처리 과정을 나타낸 그림입니다.

*. 2625 Page 위에서 14번째 줄,  2641 Page 아래에서 8번째줄, 2785 Page 밑에서 7번째줄, 

// 현재 라인에서 남은 문자 수와 한 라인에 출력할 수 있는 문자 수 를 비교하여 작은 것을 선택

*. 2692 Page, 위에서 12번째 줄

g_stGameInfo.iBlockX = -1;

g_stGameInfo.iBlockY = -1;

*. 2693 Page, 위에서 10번째 줄

게임판의 블록이 존재하는지 여부는 게임 자료구조의 vvbBoard 필드에 저장되어 있습니다.

*. 2694 Page, 위에서 5번째 줄

게임 자료구조에는 현재 게임판의 정보를 저장하는 vvbBoard 필드가 있으므로 움직이는 블록의 현재 좌표를 그대로 게임판에 저장하면 됩니다.

*. 2720 Page, 아래에서 13번째 줄

g_stGameInfo.iBlockX = -1;

g_stGameInfo.iBlockY = -1;

*. 2766 Page, 위에서 4번째 줄

텍스트 뷰어에 한글 출력 기능을 추가하려면 한글인지를 판단해 2바이트씩 출력하는 코드만 추가하면 되기 때문입니다.

*. 2846 Page, 위에서 1번째 줄

만든 첫 번째 한글 입력 모듈은 오토마타를 사용했습니다.

*. TODO...

OS 제작을 시도해본 분들은 아시겠지만...

OS를 개발하려면 PC 하드웨어부터 OS 관련 지식까지 많은 정보가 필요합니다. ^^;;;

저 역시 책도 많이 보고 웹 사이트도 많이 찾아다녔는데요,

OS를 개발할 때 도움이 되었던 책과 사이트를 정리해둘 필요가 있는 것 같아서 한자 남겨둡니다.

OS를 개발하시는 다른 분들에게 도움이 되었으면 좋겠네요.

책 목록

• Operating System Concepts : 워낙 유명한 책이라 따로 설명이 필요 없을 것 같네요. ^^;;;
• Understanding the Linux Kernel : OS 개발에 관심이 있다면 이 책을 한 번쯤 들어보셨을 것 같네요. ^^;;; 역시나 설명이 필요없는 책~!!
  
• The Design of the UNIX Operating System : 우연히 e-book을 구해서 읽기 시작함. Unix 시스템 전반에 대해서 아주 자세히 설명해줌
• MMURTL V1.0 : 위 책과 함께 우연히 e-book을 구해서 읽기 시작함. 32비트 멀티태스킹 OS를 만드는 내용을 담고 있음
  
• The Indispensable PC Hardware Book : PC Hardware의 모든 정보를 망라한 책~!!
• The Undocumented PC : 역시 PC Hardware의 모든 정보를 망라한 책~!!
  

사이트 목록

• OS Dev 사이트 : OS 개발에 대한 많은 내용을 담고 있는 사이트
• Bona Fide OS Developer 사이트 : OS 개발에 관련된 많은 자료와 예제 코드를 담고 있는 사이트
• The Operating System Resource Center : OS 개발에 관련된 각종 하드웨어나 소프트웨어 정보를 얻을 수 있는 사이트

<64비트 멀티코어 OS 원리와 구조>

qemu-0.10.4.zip

<책 표지 - 출처 Yes24>

이 책은 소프트웨어 개발에 관련된 여러 자원, 즉 사람부터 개발 언어 및 툴까지 여러가지 내용을 수필의 형식을 빌어 정리해두었는데, 여러 부분에서 공감이 가는 부분이 많았습니다. 그리고 충격적인 부분은... 이 책이 20년도 전에 쓰여진 책이라는 것이죠. @0@)-b

책을 덮고 나니... 제가 하고 있는 고민을 저만 하는게 아니라 오래전부터 하고 있던 부분이라는 것에 좀 씁쓸하더라구요. ㅠㅠ 시간이 20년이나 지났지만 예나 지금이나 소프트웨어 개발은 크게 달라진게 없는 것이 아닌가 하는 생각이 들어서... ㅠㅠ

제 책 "64비트 멀티코어 OS 원리와 구조"가 나온지도 벌써 2달 이상 지났습니다. ^^;;; 책이 출간됨과 동시에 가장 많이 질문을 받는 것이 OS 제작을 위한 환경 구축 방법인데요... 얼마전부터 환경 구축에 어려움을 겪는 분들이 많아지셔서 Cygwin 최신 버전을 다운 받아서 빌드를 해봤습니다. ^^;;; 실제로 빌드를 진행하다보니 한가지 변경점이 보이더군요. ㅠㅠ 그래서 그 내용을 여기다가 정리해놓습니다. ㅠㅠ

<출처 - yes24.com>

Cross Compiler를 만들려면 먼저 Cygwin 사이트(http://www.cygwin.com/install.html)로 이동해서 Cygwin Installer를 다운로드 받습니다. Setup.exe 파일을 다운하면 됩니다. ^^;;;

다운로드 후 파일을 실행하면 어떻게 설치할 것이고 패키지 소스는 어디에서 다운 받을 것인지 선택하는 부분이 나오는데,

책에 나와있는 카이스트 사이트(ftp://ftp.kaist.ac.kr)가 더이상 유효하지 않으니 다른 사이트를 선택해야합니다.

우리나라 근처에 있는게 아무래도... 속도도 빠르니 가까운 일본 주소인 ftp://ftp.jaist.ac.jp를 선택하면 됩니다. ^^;;;

패키지 소스를 다운 받을 주소를 선택하고 난 뒤에는 "Select Package" 화면이 나올 때까지 적당히 Next를 선택해주면 됩니다. ^^;;;

"Select Package" 화면이 나오면 아래의 항목들을 설치해줍니다. 책을 쓸 때는 C++ 관련 항목이 없어도 정상적으로 빌드가 되었지만, 지금은 C++ 컴파일러를 설치하지 않으니 configure 중에 오류가 발생하더군요. ㅠㅠ 가장 아래쪽에 있는 libmpc-devel이 변경된 부분입니다.

+Devel  
    + binutils - 2.21.53-2 버전, 소스 및 바이너리 모두 설치  
    + bison - 2.4-2-1 버전, 바이너리만 설치  
    + flex - 2.5.35-1 버전, 바이너리만 설치  
    + gcc4-core - 4.3.4-3 버전, 소스 및 바이너리 모두 설치  
    + gcc4-g++ - 4.3.4-4 버전, 바이너리만 설치  
    + libiconv - 1.14-1 버전, 바이너리만 설치  
    + libtool - 2.2.7a-15 버전, 바이너리만 설치  
    + make - 3.81-2 버전, 바이너리만 설치  
    + patchutils - 0.3.1-1 버전, 바이너리만 설치  
+Libs  
    + libgmp-devel - 4.3.2-1 버전, 바이너리만 설치  
    + libmpfr-devel -3.0.1-1 버전, 바이너리만 설치
    + libmpc-devel - 0.8-1 버전, 바이너리만 설치

위의 항목이 설치되고 나면 binutils부터 차례대로 빌드를 시작하면 됩니다.

binutils를 빌드하려면 /usr/src 디렉터리 아래에 있는 binutils 디렉터리로 이동해서 다음과 같은 순서로 커맨드를 입력하면 빌드와 설치가 끝납니다.

// 디렉터리 이동 후 아래 작업 수행

$> cd /usr/src/binutils-2.21.53-2  <== 디렉터리 이름은 binutils 버전에 따라 다를 수 있음
$> export TARGET=x86\_64-pc-linux  
$> export PREFIX=/usr/cross  
$> ./configure --target=$TARGET --prefix=$PREFIX --enable-64-bit-bfd --disable-shared --disable-nls  
$> make configure-host  
$> make LDFLAGS="-all-static"  
$> make install  

// 아래는 테스트를 위한 부분 커맨드를 실행했을 때 x86\_64 관련 항목이 보이면 제대로 된 것입니다. ^^;;;;  
$> /usr/cross/bin/x86\_64-pc-linux-ld --help | grep "supported "  
/usr/cross/bin/x86\_64-pc-linux-ld: supported targets: elf64-x86-64 elf32-i386 a.  
out-i386-linux efi-app-ia32 efi-bsdrv-ia32 efi-rtdrv-ia32 efi-app-x86\_64 efi-bsd  
rv-x86\_64 efi-rtdrv-x86\_64 elf64-little elf64-big elf32-little elf32-big srec sy  
mbolsrec tekhex binary ihex  
/usr/cross/bin/x86\_64-pc-linux-ld: supported emulations: elf\_x86\_64 elf\_i386 i38  
6linux  

binutils 빌드 및 설치가 끝났다면 gcc를 cross compile할 차례입니다. gcc는 아래와 같은 순서로 입력하면 빌드와 설치가 완료됩니다. ^^;;;

// 압축 해제, 파일명은 cygwin에서 다운받은 GCC 버전에 따라서 다를 수 있으니 실제 디렉터리를 확인하여 입력해야 합니다. ^^;;; 아래 패치 파일도 모두 마찬가지 입니다.  
$> cd /usr/src

$> tar -xvf gcc-4.3.4.tar.bz2  
$> patch -p1 < gcc4-4.3.4-3.src.patch  
$> patch -p1 < gcc4-4.3.4-3.cygwin.patch  
$> export TARGET=x86\_64-pc-linux  
$> export PREFIX=/usr/cross  
$> export PATH=$PREFIX/bin:$PATH

// 압축 해제가 끝났으니 소스가 있는 디렉터리 이동 후 나머지 작업 수행  
$>cd /usr/src/gcc-4.3.4 <== 디렉터리 이름은 GCC 버전에 따라 다를 수 있음

$> ./configure --target=$TARGET --prefix=$PREFIX --disable-nls --enable-languages=c --without-headers --disable-shared --enable-multilib  
$> make configure-host  
$> cp /lib/gcc/i686-pc-cygwin/4.3.4/libgcc\_s.dll.a /lib/gcc/i686-pc-cygwin/4.3.4/libgcc\_s.a  
$> cp /lib/libmpfr.dll.a /lib/libmpfr.a  
$> cp /lib/libgmp.dll.a /lib/libgmp.a  
$> make all-gcc  
$> make install-gcc  

// 테스트용입니다. 아래와 같이 입력했을 때 m64가 보이면 정상적으로 설치된 것입니다.  
$> /usr/cross/bin/x86\_64-pc-linux-gcc -dumpspecs | grep -A1 multilib\_options  
    *multilib\_options:  
    m64/m32  

자, 이제 64비트 바이너리를 생성할 수 있는 gcc가 생성되었으니,
즐거운 OS 프로그래밍하세요 ;)

<NetBeans 설치 방법>

<루비 개발용 플러그인 설치 화면>

클릭하고나면 플러그인 설치 화면이 표시되는데 여기에 ruby를 입력하면 "Ruby and Rails" 항목이 표시됩니다. 이 항목을 설치했으면 NetBeans를 다시 시작한 뒤에 "File" 메뉴의 "New Project" 메뉴를 선택합니다. 그러면 프로젝트 항목에서 Ruby가 표시되며 Ruby 프로젝트를 만들어서 프로그래밍을 할 수 있습니다. ^^

그럼 좋은 하루 되세요 ^^

<루비(Ruby) 사이트 - http://www.ruby-lang.org/ko/>