이재만 교수의 공간

어느 정도 규모가 있는 프로젝트에서는 여러 컴파일 결과물들을 라이브러리 형태로 관리하는 것이 편할 때가 많다.

라이브러리는 목적 파일들을 하나로 합친 파일로, 관례적으로 .a라는 확장자(archive)를 가진다.

make 명령은 라이브러리를 편하게 관리할 수 있는 특별한 구문을 제공한다.

lib(file.o)라는 구문이 바로 그것인데, 이는 lib.a라는 라이브러리에 들어 있는 목적 파일 file.o를 지칭한다.

make에는 라이브러리 관리용 내장 규칙도 들어있다.

실제로 그 규칙을 풀어서 쓴다면 다음과 같다

.c.a:

$(CC) -c $(CFLAGS) $<

$(AR) $(ARFLAGS) $@ $*.o

이것은 .c 파일로부터 .a를 만들어내는 규칙이다.

보통의 경우 매크로 참조 $(AR)과 $(ARFLAGS)는 각각 ar과 

옵션 rv로 확장된다. 따라서 이 규칙은

- 우선 소스 파일을 컴파일해서 목적 파일을 만들고,

- ar 명령을 이용해서 새 목적 파일을 라이브러리에 추가한다

이 규칙에는 여러 가지 특수 매크로들이 쓰이는데, 이들은 현재 시점에서의 해당 파일 이름들로 치환된다.

$< - 원본 이름

$@ - 대상 이름

$* - 접미어가 없는 이름

내장 규칙들은 파일 이름의 접미어(suffix)와 확장자를 기초로 적용된다.

특정한 접미어가 붙은 파일을 지정하면 make는 그에 해당하는 다른 접미어를 가진 파일을 생성한다.

대표적인 예는 .c와 .o 이다.

make는 이름에 .c가 붙은 파일을 컴파일해서 .o 파일을 만들어 낸다

이러한 접미어 기반 규칙을 사용자가 새로 만드는 것도 가능하다

이러한 경우 .cpp 파일로부터 목적 파일을 생성하는 새로운 접미어 규칙을 make에게 알려주는 것이다.

프로젝트에 소스 파일들이 많다고 할 때 이러한 접미어 규칙을 이용하면 Makefile이 훨씬 간결해지며, 또한 프로젝트에서 새 소스 파일을 추가하는 작업도 훨씬 쉬워진다.

Makefile에서 새 접미어 규칙을 추가할 때에는 두 가지 일을 해주어야 한다. 

.SUFFIXES 명령으로 새 접미어를 등록하고 

다음과 같은 형태의 대상에 실제 규칙을 지정해 주는 것이다.

.<기존 접미어> .<새 접미어> :

이러면 make는 접미어가 <기존 접미어>인 파일에 해당 규칙을 적용해서 이름이 같고 접미어가 <새 접미어>인 파일을 생성한다.

다음은 .cpp파일을 .o 파일로 컴파일하는 접미어 규칙이다

.SUFFIXES: .cpp

.cpp.o:

$(CC) -xc++ $(CFLAGS) -I$(INCLUDE) -c $<

여기서 .cpp.o: 라는 의존성 정의는 접미어가 .cpp인 파일을 

그 아래의 규칙을 이용해서 .o 파일로 변환하라고 

make에게 알려주는 역할을 한다

이런 형태의 의존성에 대한 규칙에서는 파일 이름을 명시적으로 지정할 수 없으므로 특별한 매크로들이 필요하다. 위의 규칙에서 $<을 볼 수 있을텐데,

이는 원본 파일(기존 접미어를 가진 파일)의 이름으로 확장된다.

참고로 -xc++ 플래그는 gcc에게 이것이 C++ 소스 파일임을 알려주는 역할을 한다.

한 가지 주목할 것은 C++ 소스 파일들에 대해 단지 .cpp에서 .o 파일로의 규칙만 정의하면 된다는 점이다. 

.o 파일들을 이진 실행 파일로 만드는 방법은 make가 이미 알고 있다.

이제 make를 실행하면 make는 위의 새 규칙을 이용해서 bar.cpp를 bar.o를 만들어내고, 그런 다음 자신의 내장 규칙들을 이용해서 .o로부터 실행 파일을 만들어 낸다.

요즘의 make는 .cpp 확장자를 가진 C++ 소스 파일을 다루는 방법을 알고 있지만, 이런 접미어 규칙을 이용하면 한 종류의 파일을 다른 종류의 파일로 변환할 때 일이 아주 편해진다.

좀 더 최근 버전의 make는 이러한 접미어 기반 변환이나 기타 여러가지 작업을 가능하게 하는 좀 더 유연한 구문을 지원한다. 예를 들어 특수 문자 %를 이용하면 파일 확장자에만 의존하는 것이 아니라 좀 더 일반적인 파일 이름 패턴 부합 기능에 의존해서 변환을 수행하는 의존성 정의를 만드는 것이 가능하다.

다음은 앞에 나온 .cpp 접미어 규칙을 패턴 규칙을 이용해서 표현한 것이다.

%.cpp: %o

$(CC) -xc++ $(CFLAGS) -I$(INCLUDE) -c $<

빌드 과정의 각 단계를 Makefile에 명시적으로 지정했으나, make에 있는 여러 내장 규칙(built-in rule)들을 이용하면 Makefile들을 더 간단하게 만들 수 있다. 이런 접근 방식은 소스 파일들이 많은 경우에 더욱 유용하다

우선 Hello world 프로그램을 만든다 - foo.cpp

#include <iostream>

#include <stdlib.h>

int main( )

{

std::cout << "Hello world~~!\n";

exit(EXIT_SUCCESS);

}

Makefile을 지정하지 않고 make를 실행해보자

$ make foo

g++ foo.cpp -o foo

놀랍게도 make는 자신이 알고 있는 내장 규칙을 이용해서 소스 파일을 성공적으로 컴파일한다. 종종 이런 내장 규칙들을 추론 규칙(inference rules)이라고 부른다. 내장 규칙들은 매크로등을 사용하므로, 매크로들을 적절히 설정함으로써 내장 규칙의 기본 행동 방식을 변경할 수 있다.

make의 내장 규칙들은 -p 옵션으로 확인할 수 있다.

make -p

하나의 Makefile로 여러 개의 대상 파일들을 생성하거나 여러가지 작업들을 선택적으로 수행하는 게 바람직한 경우도 종종 있다

다음 실습에서는 기존의 Makefile에 불필요한 목적 파일들을 삭제하는 clean 대상과 최종 응용프로그램을 다른 디렉토리로 옮기는 install 대상을 추가한다

clean - 대상을 rm 명령을 이용해서 목적 파일들을 삭제

그런데 rm 앞에 -를 붙였기 때문에 make는 rm이 보고한 오류를 무시한다

따라서 목적파일들이 없어서 rm이 오류를 돌려준 경우에도 make는 작업을 계속 진행하게 된다.

clean:

-rm main.o 2.o 3.o

또 clean 대상의 : 다음에 아무 것도 없다는 점 역시 주목하기 바란다

이는 make에게 이 clean 대상은 어떠한 것에도 의존하지 않음을 알려주는 역할을 한다. 이 경우는 make는 clean 대상이 항상 낡은 것이라고 간주하며, 따라서 make 실행 시 clean을 지정하면 항상 이 대상의 규칙이 실행된다

install 대상의 규칙은 myapp에 의존한다. 따라서 make는 이 대상의 규칙을 실행하기 전에 반드시 myapp을 만든다. 이 대상의 규칙은 셸 스크립트 형태이다. make는 규칙을 실행할 때 셸을 호출하며 각 규칙에 대해 새로운 셸을 사용하므로, 스크립트 명령들 전부가 하나의 논리적인 스크립트 문장으로 실행되도록 각 줄 끝에 \를 붙였다. 또한 이 문장은 @로 시작하므로, make는 이 문장을 출력하지 않고 실행한다.

install 대상의 규칙은 응용 프로그램이 최종적인 장소에 설치될 때까지 여러 개의 명령들을 차례대로 수행한다. 그런데 이 규칙이 한 명령의 성공 여부로 그 다음 명령의 수행 여부를 결정하는 것은 아니다. 만일 한 명령이 성공적으로 수행된 경우에만 다음 명령이 수행되길 원한다면 다음 예처럼 &&로 명령들을 연결해야 한다

Makefile 안에서 매크로를 정의할 때에는 매크로이름 = 값 형태를 사용한다

그리고 매크로의 값에는 $(매크로이름) 또는 ${매크로이름} 형태로 접근한다

일부 make 버전들은 $매크로이름 구문도 지원한다

매크로에 빈 값을 배정하는 것도 가능하다

= 다음에 아무것도 쓰지 않으면 된다

매크로는 컴파일러 옵션에 즐겨 쓰인다

응용프로그램을 개발하는 동안에는 최적화를 전혀 사용하지 않으며 디버깅 정보를 실행 파일에 포함시키는 경우가 많다

반면 릴리스 버전에서는 빠른 속도와 작은 실행 파일을 위해 그 반대의 옵션, 즉 최대의 최적화와 디버깅 정보 제거를 필요로 하는 경우가 많다.

컴파일러 명령의 이름 자체도 매크로로 정의하곤 한다.

매크로들은 일반적으로 Makefile 자체에서 정의하나, make 명령 실행 시 정의하는 것도 가능하다. 

make CC=c89 

이처럼 명령줄에서 정의된 매크로들은 Makefile 안에 정의된 같은 이름의 매크로들보다 우선적으로 적용된다.

명령줄에서 매크로를 정의할 때 하나의 정의는 하나의 단일한 명령줄 인수이어야 한다. 따라서 빈칸을 사용하지 말거나, 빈칸이 필요하다면 반드시 따옴포로 감싸야 한다("CC = c89")

* 내장 매크로

$? : 현재 대상보다 더 최근에 수정된 의존물(대상이 의존하는 파일)들의 목록

$@ : 현재 대상의 이름

$< : 현재 의존물의 이름

$* : 현재 의존물의 이름(확장자는 제외)

Makefile 안에서 사용할 수 있는 유용한 특수 문자가 두 가지가 있다

이들은 규칙의 명령 앞에서 쓰인다

- 문자는 make가 오류를 무시하게 만든다. 예를 들어 디렉토리를 생성하되 디렉토리가 이미 존재하기 때문에 생기는 오류 등 모든 오류를 무시하고 싶다면 mkdir 앞에 -를 붙이면 된다.

이 문자를 활용하는 간단한 예가 잠시 후에 나온다

@ 문자는 명령을 수행하기 전에 명령을 표준 출력에 출력하지 않게 한다. echo 명령으로 메시지를 출력하려고 할 때 유용하다

하나의 Makefile은 의존성 정의들과 규칙들로 구성된다

* 의존성(Dependency) - 하나의 대상(생성할 파일)과 그것이 의존하는 일단의 소스 파일들로 정의

* 규칙(rule) - 의존 파일들로부터 대상 파일을 생성하는 방법을 정의

* 대상(target) - 하나의 실행 가능 파일

다시 생성해야 하는 경우에는 해당 규칙을 찾아서 실행한다

make 명령은 Makefile의 의존성 정의들을 분석해서 적절한 대상 생성 순서를 결정한다

make의 옵션과 매개변수

-k : 오류가 발생했을 때에도 작업을 계속 진행

     이것을 지정하지 않으면 make는 첫 번째 오류가 났을 때 작업을 완전히      중단

     어떤 소스 파일들이 컴파일에 실패하는지 전반적으로 파악하고자 할 때      유용

-n : 빌드 명령을 실제로 수행하지 않고, 그냥 명령문들을 출력

      make가 어떤 일을 수행할 지 미리 파악할 때 유용

-f <파일이름> : Makefile로 사용할 때 파일을 명시적으로 지정

          명시적으로 지정하지 않으면

       1. 현재 디렉토리에서 makefile이라는 이름을 찾게 됨

       2. 그렇지 않으면 Makefile이라는 파일을 찾음

make로 특정한 하나의 대상(실행파일)을 빌드하는 경우에는 그 대상의 이름을 make의 한 매개변수로 지정

대상 이름을 주지 않는 경우, make는 Makefile의 첫 대상의 이름을 all로 하고 그 다음에 all이 의존하는 대상들을 나열하는 것.

이 관례는 make 명령에 대상을 지정하지 않았을 때 어떤 것이 만들어지는지를 명확하게 알 수 있다는 장점

* 의존성

- 최종 응용 프로그램의 각 파일이 소스 파일들과 어떻게 연관되는지를 지정. 다중 파일의 문제점을 이야기할 때 나온 예제의 경우, 최종 응용프로그램은 main.o, 2.o, 3.o에 의존하며 main.o는 main.c와 a.h에, 2.o는 2.c, a.h, b.h에, 그리고 3.o는 3.c, b.h, c.h에 의존한다

즉, main.o는 main.c와 a.h의 변화에 영향을 받는다

따라서 두 파일들 중 하나라도 변경되면 main.c를 다시 컴파일 해야 한다

Makefil 안에서 이러한 의존 관계를 명시할 때는 대상 이름을 쓰고 콜론을 쓴 다음 빈칸이나 탭으로 칸을 띄운 후에 대상을 만드는 데 필요한 파일들을 빈칸이나 탭으로 구분해서 나열해야 한다

다음은 앞의 예의 의존성들을 정의한 것이다

myapp : main.o 2.o 3.0

main.o : main.c a.h

2.o : 2.c a.h b.h

3.o : 3.c b.h c.h

이와 같이 의존성들은 소스 파일들이 서로 어떻게 연관되는지를 나타내는 하나의 계통구조를 형성한다고 할 수 있다. 이들을 통해서, 예를 들어 b.h가 변했다면, 2.o와 3.o가 갱신되어야 하며, 2.o와 3.o가 갱신되었으므로 myapp 역시 갱신되어야 함을 어렵지 않게 알 수 있다

여러 개의 최종 파일들을 생성해야 하는 경우 all이라는 유사 대상(phony target)을 사용하는 것이 관례이다. 예를 들어 응용 프로그램이 이진 파일 myapp와 매뉴얼 페이지 파일 myapp.1로 구성될 때, 이에 대한 all 대상을 다음과 같이 정의할 수 있다

all: myapp, myapp1

make 실행 시 all이라는 대상을 지정하지 않으면 make는 Makefile에 있는 첫 대상을 빌드하게 된다

* 규칙

해당 대상의 생성 방법을 서술하는 규칙도 지정

앞에 나온 의존성 예들은 2.o가 2.c와 a.h, b.h에 의존한다는 점만 make에게 알려줄 뿐, 그 파일들로부터 2.o를 어떻게 만들어야 하는지 알려주지 않는다

이를 알려주는 역할은 규칙(rule)이 담당

예를 들어 2.o의 경우 gcc -c 2.c 라는 규칙이면 충분

물론 헤더 파일 디렉토리라던가 디버깅을 위한 매크로 기호 같은 것을 추가할 수도 있다

모든 규칙은 하나의 탭 문자로 시작해야 한다

ex) Makefile1

myapp : main.o 2.o 3.o

gcc -o myapp main.o 2.o 3.o

main.o : main.c a.h

gcc -c main.c

2.o : 2.c a.h b.h

gcc -c 2.c

3.o : 3.c b.h c.h

gcc -c 3.c

makefile이나 Makefile이 아닌 파일 이름을 사용했기 때문에, 이 파일로 make를 실행하기 위해서는 반드시 -f 옵션을 이용해서 파일 이름을 명시적으로 지정해주어야 함

make 명령은  Makefile의 의존성들을 분석해서 어떤 파일들을 어떤 순서로 만들 것인지 결정한다. Makefile 상에서는 myapp이 제일 먼저 나오지만, make는 그 대상을 만들기 위해서 다른 파일들부터 만들어야 함을 알아내고는 규칙 부분들을 해석해서 해당 파일들을 생성하는 데 필요한 적절한 명령들을 실행한다. 또한 그 명령들을 실행하면서 그 명령들을 콘솔에 출력한다

* 실습할 차례 요약

* Windows(Samba 서버 역할 - host 컴퓨터)

- Windows에 자신의 자원을 사용할 사용자를 추가

- Windows의 자원을 공유

* CentOS7(Samba 클라이언트 - 가상 컴퓨터)

- Samba 클라이언트 패키지가 설치되어 있는지 확인

- smbclient 명령어로 Windows가 제공하는 자원을 확인

- smbmount 명령어로 Windows가 제공한 공유 폴더를 마운트

* Windows 폴더를 생성 및 공유하고, 리눅스에서 접근해서 사용

1. Windows 파일 탐색기에서 C:/CentOS_Common 이라는 폴더를 생성한다

   만든 폴더를 마우스 오른쪽 버튼을 클릭한 다음 바로기가 메뉴에서 [속성] -> [공유]를 선택한 후, <공유> 버튼을 클릭해서

   Everyone 사용자를 선택한 다음 <추가>를 클릭

   [사용 권한 수준]의 설정을 [읽기/쓰기]를 선택해 읽기/쓰기가 가능하다록 하고 <공유>를 클릭

   만약 [모든 공용 네트워크에 대해 네트워크~~~]라는 메시지 박스가 나오면 [예, 모든 공용 네트워크에 대해~~~]를 선택

2. 최종적으로 '컴퓨터이름/CentOS_Common' 이라는 네트워크 경로로 공유가 되었다. <닫기> 버튼을 클릭해서 공유 설정을 마침

3. 공유 폴더인 CentOS_Common에 적당한 파일을 복사

4. 리눅스에서 접근을 허용하려면 리눅스의 사용자를 추가하고 비밀번호를 지정

명령 프롬프트를 관리자 모드로 실행한 후, 다음 명령을 입력하자

net user root 1234 /add     => root 사용자를 만들고 암호를 1234로 지정

- 제어판의 [사용자 계정]에서 사용자를 추가할 수도 있으나, Windows 버전 별로 사용법이 많이 달라서 혼란스러울 수 있으므로 간단히 명령어로 사용자를 추가하자

- 필요하다면 제어판의 [사용자 계정]에서 추가된 root 사용자를 확인할 수 있다

- 명령 프롬프트에서 'ipconfig' 명령어를 입력해 Windows의 IP 주소를 확인하자

* Windows에서 공유한 폴더를 리눅스에서 사용해보자

- yum list samba-client

- yum list samba-common 

을 입력해서 samba-client와 samba-common이 설치 되었는지 확인한다

없으면 samba-client를 설치한다

- yum install -y samba-client

5. 먼저 다음 명령어를 입력해 Windows에서 공유한 폴더 및 프린터가 보이는지 확인

- smbclient -L WindowsIP주소

- Enter root's password : -> Windows에서 생성한 (root) 사용자의 암호(여기서는 '1234')

- 공유된 컴퓨터의 이름과 공유 폴더를 확인할 수 있다

6. 다음 명령을 입력해 Windows에서 공유한 폴더(CentOS_Common)에 마운트할 디렉터리를 만들고 마운트 시킨다

mkdir 리눅스에서마운트할디렉토리이름

mount -t cifs //WindowsIP주소/Windows공유폴더이름 리눅스에서마운트할디렉토리이름

Password :  -> Windows에서 생성한 root의 암호(여기서는 1234)

ex) mkdir sambaFolder

mount -t cifs //172.16.10.xx/CentOS_Common /sambaFolder/

Password : 1234

7. 이제 /sambaFolder 디렉터리를 사용하는 의미는 Windows의 C:/CentOS_Common/이라는 폴더를 사용하는 것과 동일한 의미가 된다.

/sambaFolder 디렉토리에 파일을 몇 개 복사하고, Windows의 탐색기에서 확인해도 잘 보인다

이 가이드는 CentOS 최신 릴리즈의 최소 설치에 기초하고 여러 외부 인코딩 라이브러리를 위한 지원을 가지는  로컬, 비시스템 설치를 제공한다. 이 설명들은 또한 최근 Red Hat Enterprise Linum(RHEL)와 Fedora에 적용되어야 한다. 이것은 비 침투적(invasive)인 가이드이고 모든 단계는 간단하고 이 페이지의 끝에 보여진다

* 의존성 얻기

# 는 명령어가 supuruser나 root로 실행되어야만 하는 것을 가리킨다

의존성을 얻어라. 이것은 컴파일 하는데 요구되어지지만 만약 선호하면 그것을 행할 때 그것들을 삭제할 수 있다

(make는 예외; 이것은 디폴트에 의해 설치되어야 하고 그것에 많은 것들이 의존한다)

# yum install autoconf automake cmake freetype-devel gcc gcc-c++ git libtool make mercurial nasm pkgconfig zlib-devel

home 디렉토리에서 모든 소스를 넣기 위해 새로운 디렉토리를 만들어라

# mkdir ~/ffmpeg_sources

* 컴파일과 설치

- 주의 : 만약 어떤 인코더가 필요하지 않으면 관련있는 부분들을 건너뛸 수 있고, FFmpeg에서 적당한 ./configure 옵션을 제거하라. 예를 들어 만약 libvorbis가 필요하지 않으면, 그 부분을 건너 띄고 --enable-libvorbis를 FFMpeg 설치 부분으로부터 제거하라

* Yasm

- Yasm은 x264와 FFmpeg에 사용되는 어셈블러이다

cd ~/ffmpeg_sources

git clone --depth 1 git://github.com/yasm/yasm.git

cd yasm

autoreconf -fiv

./configure --prefix="$HOME/ffmpeg_build" --bindir="$HOME/bin"

make

make install

make distclean

* libx264

- H.264 비디오 인코더이다. 더 많은 정보와 사용법 예제를 위해 H.264 인코딩 가이드를 봐라

--enable-gpl --enable-libx264로 구성된 ffmpeg이 필요하다

cd ~/ffmpeg_sources

git clone --depth 1 git://git.videolan.org/x264

cd x264

./configure --prefix="$HOME/ffmpeg_build" --bindir="$HOME/bin" --enable-static

make

make install

make distclean

* libx265

H.265/HEVC 비디오 인코더. 더 많은 정보와 사용법 예제를 위해 H.265 인코딩 가이드를 봐라

--enable-gpl --enable-libx265로 구성된 ffmpeg이 필요하다

cd ~/ffmpeg_sources

hg clone https://bitbucket.org/multicoreware/x265

cd ~/ffmpeg_sources/x265/build/linux

cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX="$HOME/ffmpeg_build" -DENABLE_SHARED:bool=off ../../source

make

make install

* libfdk_aac

AAC audio encoder

--enable-libfdk_aac로 구성된 ffmpeg이 필요하다(그리고 만약 또한 --enable-gpl을 포함시켰으면 --enable-nonfree)

cd ~/ffmpeg_sources

git clone --depth 1 git://git.code.sf.net/p/opencore-/amr/fdk-aac

cd fdk-aac

autoreconf -fiv

./configure --prefix="$HOME/ffmpeg_build" --disable-shared

make

make install

make distclean

* libmp3lame

MP3 오디오 인코더

--enable-libmp3lame으로 구성된 ffmpeg이 필요하다

cd ~/ffmpeg_sources

curl -L -O http://downloads.sourceforge.net/project/lame/lame/3.99/lame-3.99.5.tar.gz

tar xzvf lame-3.99.5.tar.gz

cd lame-3.99.5

./configure --prefix="$HOME/ffmpeg_build" --bindir="$HOME/bin" --disable-shared --enable-nasm

make

make install

make distclean

* libopus

Opus 오디오 디코더와 인코더

--enable-libopus로 구성된 ffmpeg이 필요하다

cd ~/ffmpeg_sources

git clone git://git.opus-codec.org/opus.git

cd opus

autoreconf -fiv

./configure --prefix="$HOME/ffmpeg_build" --disable-shared

make

make install

make distclean

* libogg

Ogg 비트스트림 라이브러리.

 libtheora와 libvorbis에 의해 필요된다

cd ~/ffmpeg_sources

curl -O http://downloads.xiph.org/releases/ogg/libogg-1.3.2.tar.gz

tar xzvf libogg-1.3.2.tar.gz

cd libogg-1.3.2

./configure --prefix="$HOME/ffmpeg_build" --disable_shared

make

make install

make distclean

* libvorbis

Vorbis 오디오 인코더. libogg를 필요로 한다

--enable-libvorbis로 구성된 ffmpeg을 필요로 한다

cd ~/ffmpeg_sources

curl -O http://downloads.xiph.org/releases/vorbis/libvorbis-1.3.4.tar.gz

tar xzvf libvorbis-1.3.4.tar.gz

cd libvorbis-1.3.4

LDFLAGS="-L$HOME/ffmpeg_build/lib" CPPFLAGS="-I$HOME/ffmpeg_build/include" ./configure 

--prefix="$HOME/ffmpeg_build" --with-ogg="$HOME/ffmpeg_build" --disable-shared

make

make install

make distclean

* libvpx

VP8/VP9 video encoder

--enable-libvpx로 구성된 ffmpeg을 필요하다

cd ~/ffmepg_sources

git clone --depth 1 https://chromium.googlesource.com/webm/libvpx.git

cd libvpx

./configure --prefix="$HOME/ffmpeg_build" --disable-examples

make

make install

make clean

* FFmpeg

cd ~/ffmpeg_sources

git clone --depth 1 git://source.ffmpeg.org/ffmpeg

cd ffmpeg

PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure --prefix="$HOME/ffmpeg_build" --extra-cflags="-I$HOME/ffmpeg_build/include" --extra-ldflags="-L$HOME/ffmpeg_build/lib" --bindir="$HOME/bin" --pkg-config-flags="--static" --enable-gpl --enable-nonfree --enable-libfdk_aac --enable-libfreetype 

--enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265

make

make install

make distclean

hash -r

컴파일은 지금 완료되고 ffmpeg(또한 ffprob, ffserver, lame, x264)는 지금 사용할 준비가 되어야 한다. 이 가이드의 나머지는 FFmpeg을 업데이트하거나 제거하는 방법을 보여준다

팁 : 만약 아래에서 보여지는 것과 같이 업데이트 하고자 하면 ffmpeg_sources 디렉토리와 모든 컨텐츠를 유지하라. 그렇지 않으면 이 디렉토리를 삭제할 수 있다.

* 업데이트

FFmpeg의 개발은 활발하고, 가끔의 업데이트는 새로운 특징과 버그 수정을 줄 수 있다. 첫째로, 오래된 파일을 제거하고 의존성을 업데이트 하라

rm -rf ~/ffmpeg_build ~/bin/{ffmepg, ffprobe, ffserver, lame, vsyasm, x264, x265, yasm, ytasm}

# yum install -y autoconf automake cmake gcc gcc-c++ git libtool make mercurial nasm pkgconfig zlib-devel

* Yasm 업데이트

cd ~/ffmpeg_sources/yasm

make distclean

git pull

그리고 나서 yasm 설치 부분에서 보여졌던 ./configure, make, make install를 실행하라

* x264 업데이트

cd ~/ffmpeg_sources/x264

make distclean

git pull

그리고 나서 x264 설치 부분에서 보여졌던 ./configure, make, make install을 실행하라

* x265 업데이트

cd ~/ffmpeg_sources/x265

rm -rf ~/ffmpeg_sources/x265/build/linux/*

hg update

cd ~/ffmpeg_sources/x265/build/linux

그리고 나서 x265 설치 부분에서 보여졌던 ./configure, make, make install을 실행하라

* libfdk_aac 업데이트

cd ~/ffmpeg_sources/fdk_aac

make distclean

git pull

그리고 나서 libfdk_aac 설치 부분에서 보여졌던 ./configure, make, make install을 실행하라

* libvpx 업데이트

cd ~/ffmpeg_sources/libvpx

make clean

git pull

그리고 나서 libvpx 설치 부분에서 보여졌던 ./configure, make, make install을 실행하라

* FFmpeg  업데이트

cd ~/ffmpeg_sources/ffmpeg

make distclean

git pull

그리고 나서 FFmpeg 설치 부분에서 보여졌던 ./configure, make, make install을 실행하라

* 이 가이드에 의해 만들어진 변경 복구

rm -rf ~/ffmpeg_build ~/ffmpeg_sources ~/bin/{ffmpeg, ffprobe, ffserver, lame, vsyasm, x264, yasm, ytasm}

# yum erase autoconf automake cmake gcc gcc-c++ git libtool mercurial nasm pkgconfig zlib-devel

hash -r

컴파일 가이드

* 이 페이지는 리눅스와 그 파생들 하에서 소스코드 패키지로부터 시작하는 프로젝트를 컴파일하기 위한 일반적인 명령어들을 제공한다

- 소스 코드로부터 컴파일해야 하는 이유

바이너리 패키지는 보통 많은 플랫폼들에 대해 서드파티 패키져에 의해 제공되지만, 일부의 경우 여러 이유로 옵션이 없다

* 바이너리 패키지는 기한이 지나거나 치명적인 버그를 포함하거나 소프트웨어의 최신 버전에서 사용할 수 있는 필수적인 특징이 빠져있다

* 예를 들어 특별한 설치 레이아웃을 지원하기 위해, 플랫폼-특별 옵션을 얻기 위해 또는 바이너리 패키지에 지원되지 않는 특별한 라이브러리에 대한 링크를 위해 빌드를 커스터마이즈 할 필요가 있다

* 소스 코드를 편집하므로써 소프트웨어를 커스터마이즈 하기를 원한다

이 모든 경우에 소스코드로부터 패키지를 빌드하는 것은 최상의 해답이다

* 개요

대부분의 소스 패키지 설치는 다음과 같은 과정을 따른다고 가정한다

* configuration(with a configure script)

* compilation(with make)

* installation(with make install)

Configuration은 컴파일 스텝을 따름으로써 필요되는 필수적인 파일의 생성을 허락할 것이고, 일반적으로 소스 패키지에 의해 제공되는 configure 스크립트를 통해 되어진다. configuration 동안 install prefix와 사용 가능한 컴포넌트를 정의하는 것은 가능한다

컴파일은 보통 configuration 단계 완료 후에 make를 실행하는 것으로 구성된다. 이 구문에서 필요한 라이브러리와 바이너리는 생성된다.

Installation은 configuration 단계동안 지정된 path에서 바이너리와 라이브러리를 설치할 것이다. 컴파일 경로 안에 컴퓨일된 바이너리를 사용할 수 있기 때문에 이 단계는 정말로 필요하지 않다

* 설치 경로

패키지는 여러 디렉토리에 설티된 여러 개의 연관있는 파일들로 구성된다. configure 단계는 보통 사용자가 install prefix라 불리는 것을 지정하도록 허락하고, 보통 configure --prefix=PREFIX 옵션을 통해 구체화된다, 여기에서 PREFIX는 보통 기본으로 /usr/local에 있다. prefix는 모든 컴포넌트가 설치되어 있는 공통적인 디렉토리를 구체화한다

다음 디렉토리들은 보통 설치 안에 포함된다

- PREFIX/bin : 생성된 바이너리들을 포함한다(e.g. FFmpeg의 경우 ffmepg, ffplay, ffprobe 등)

- PREFIX/include : 라이브러리 헤더를 포함한다(e.g. FFmpeg의 경우 libavutil/avstring.h, libavcodec/avcodec.h, libavformat/avformat.h 등)은 패키지 라이브러리에 대해 링크된 응용프로그램을 컴파일 하기 위해 필요하다

- PREFIX/lib : 생성된 라이브러리를 포함한다(e.g. FFmpeg의 경우 libavutil, libavcodec, libavformat 등)

- PREFIX/share : 다양한 시스템 독립적인 컴포넌트를 포함한다; 특히 문서 파일과 예제

prefix를 구체화 함으로써, 설치 레이아웃을 정의하는 것이 가능하다

/usr/local/과 같이 shared prefix를 사용함으로써 다른 패키지가 같은 디렉토리에 설치될 것이어서 일반적으로 설치를 바꾸는 것이 더 어려울 것이다

/opt/PROJECT/와 같은 prefix를 사용하기 때문에 프로젝트는 지정된 디렉토리에 설치될 것이고 시스템으로부터 제거하기 위해 간단히 /opt/PREFIX 경로를 제거할 수 있다. 반면에 그런 설치는 커스텀 경로를 가리키기 위해 모든 환경 변수를 편집할 필요가 있다.

* 환경 변수

환경에 정의된 여러 변수들은 패키지 설치에 영향을 미친다. 특히 설치 prefix에 의존하여 시스템 도구에 발견될 수 있는 설치된 컴포넌트들을 확신하기 위해 이 변수들의 일부를 업데이트 할 필요가 있다.

환경 변수들의 리스트는 env 명령어를 통해 보여질 수 있다.

영향력 있는 변수들의 리스트는 다음과 같다

- PATH : : 는 경로를 구분한다 여기서 시스템은 바이너리를 찾는다. 예를 들어 만약 /usr/local/에 패키지를 설치하면, /usr/local/bin/을 포함하기 위해서 PATH를 업데이트 해야 한다. 예를 들어 export PATH=/usr/local/bin:$PATH 명령어를 통해 될 수 있다.

- LD_LIBRARY_PATH :  /usr/local/lib - export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH. 이 변수는 가끔 ldconfig를 이용해 사용안 되게 할 수 있다

- CFLAGS : C 컴파일러의 의해 사용되는 플래그를 포함한다

- LDFLAGS : 링커에 의해 사용되는 지시자 -LPREFIX/lib

- PKG_CONFIG_PATH : pkg-config 

터미널에서 명령어

* 종료 

- power off

- shutdown -P now

- init 0

- halt -p

-P, -p : 시스템 종료 옵션

* 시스템 재부팅

- shutdown -r now

- reboot

- init 6

* 로그 아웃

- 현재 사용자의 시스템 접속을 끝낸다는 뜻

- 시스템을 종료한다는 의미가 아님

- logout

- exit

* 디렉터리 파일 나열

- ls

* 디렉토리 이동

- cd

* 현재 디렉토리의 전체 경로 표시

- pwd

* 파일이나 디렉토리 삭제

- rm

* 파일이나 디렉토리 복사

- cp

- cp abc.txt bac.txt : abc.txt를 bac.txt라는 이름으로 바꿔서 복사

- cp -r abc cba : 디렉토리 복사

* 크기가 0인 새 파일을 생성, 이미 파일이 존재한다면 파일의 최종 수정 시간 변경

- touch

* 파일이나 디렉터리의 이름을 변경, 다른 디렉토리로 옮길 때 사용

- mv

- mv abc.txt /etc/sysconfig : abc.txt 파일을 /etc/sysconfig 디렉토리로 이동

- mv aaa bbb ccc : aaa, bbb 파일을 '/ccc' 디렉토리로 이동

- mv abc.txt www.txt : abc.txt를 www.txt로 변경

* 디렉토리 생성

- mkdir

* 디렉토리 삭제

- rmdir

* 파일의 내용을 보여줌

- cat

* 텍스트 형식으로 작성된 10행만 보여줌

- head, tail

- head file.txt : 앞의 10줄만 보여줌

- tail -3 file.txt : 뒤의 3줄만 보여줌

* 텍스트 형식으로 작성된 파일을 페이지 단위로 보여줌

- more

- more +100 file.txt : 100줄부터 한 페이지씩 보여줌

- less : Page Up, Page Down, 좌우키 지원도 가능

* 해당 파일이 어떤 종류의 파일인지 보여줌

- file

* 현재 사용중인 터미널 화면을 깨끗이 지워줌

- clear

셸(Shell) - 사용자와 리눅스 시스템 사이의 경계면 역할을 하는 프로그램

            - 사용자가 셸을 통해서 명령을 내리면 시스템이 그 명령을 수행

리눅스의 표준 셸은 항상 /bin/sh에 설치

GNU 소프트웨어의 하나인 bash(GNU Bourn-Again SHell) 이다

bash는 리눅스 시스템에 항상 설치, 오픈소스

셸이 /bin/sh에 설치

사용자 로그인시 기본적으로 실행되는 셸도 바로 그것

기본 셸인 /bin/sh/ 프로그램은 사실 /bin/bash 프로그램의 링크

CentOS7을 설치하는 과정에서 네트워크 디바이스 이름이 enp2s0, em0 등 

예상하지 못한 이름을 보게 될 것이다.

요즘 서버 시스템은 내장 네트워크 카드, PCI 네트워크 카드, USB 네트워크 카드등

다양한 장치를 장착하고 있다.

전통적인 ethx 방식의 네트워크 이름은 다양한 네트워크 인터페이스를 

구분하기 어려운 점이 있고 장치추가, 제거 시 이름이 바뀌는 경우도 있었다

이러한 문제를 해결하기 위해 CentOS7부터는 일관된 네트워크 디바이스 이름과

예측 가능한 네트워크 디바이스 이름을 제공한다

CentOS7의 systemd는 다음과 단계로 네트워크 인터페이스 이름을 명명한다

1. 펌웨어 또는 BIOS에서 온보드(on-board) 네트워크 디바이스에 대해

인덱스 번호를 제공한다면 온보드 디바이스 순서에 따라 명명한다. 예)eno1

2. 펌웨어 또는 BIOS에서 PCI 익스프레스 핫 플러그 슬롯 인덱스 번호를 제공한다면

핫 플러그 슬롯 인덱스에 따라 명명한다 예) ens1

3. 하드웨어 커넥터의 물리적 위치에 따라 명명한다 예) enp2s0

4. 네트워크 인터페이스 MAC 주소에 따라 명명한다.

이 방법은 사용자가 선택한 경우가 아니라면, 기본적으로 사용되지 않는다.

예) enxbc5ff41dfaa9

5. 위 모든 방법으로 명명하지 못한 경우 고전적인 방법으로 명명한다 예)eth0

전통적으로 리눅스에서, 네트워크 디바이스는 ethX의 이름이 주어진다

여기에서 X는 0부터 시작해서 증가하는 정수다.

이것의 결점은 어느 물리적 네트워크 포트가 어느 ethX 이름을 가질 것인지 

알 수 있는 결정적인 또는 일치하는 방법이 없다

여기서의 가정은 네트워크 매니저(NetworkManager)는 삭제되었고

네트워크 대몬(Network Daemon)이 사용될 것이다

다음 스텝을 따른다

1. 각각의 인터페이스에 할당되는 네트워크 디바이스 이름을 정하라

2. /etc/udev/rules.d/70-persistent-net.rules 파일을 생성하라

( vi /etc/udev/rules.d/70-persistent-net.rules)

3. 현재의 맵을 생성하기 위한 각각의 네트워크 인터페이스에 원하는 이름을 넣고 빼라

4. 원하는 이름을 반영하기 위해 /etc/sysconfig/network-scripts/ifcfg-X 를 이름을 바꾸고 변경하라.

5. 맥 주소와 디바이스 이름 맵을 생성하기 위해 /etc/udev/rules.d/70-persistent-net/rules 파일을 편집하라

6. 이 변경을 적용하기 위해 머신을 재부팅해라

yum install -y net-tools

이 명령어를 입력하면 설치가 된다

- 성능 측면에서 virtio 네트워크 어댑터는 Intel PRO/1000 보다 선호된다

  이것은 어댑터들 중에서 PCNet 종류가 선호된다.

- virtio와 Intel PRO/1000의 어댑터들은 세그멘테이션과 offloading 체크섬의 이익을 즐긴다.

  Segmentation offloading은 컨텍스트 스위칭이 덜하고, 

  VM/호스트 경계를 가로지르는 패킷의 사이즈가 

  급격하게 증가되는 것을 허락하기 때문에 고성능을 위해 필수적이다

- 3개의 타입(internal, bridged and host-only)은 거의 동일한 성능을 가진다

- internal 타입은 조금 더 빠른데 호스트의 네트워크 스택에 

절대 접근하지 않을 만큼의 패킷으로 CPU 사이클을 덜 사용하기 때문이다

- NAT 접근은 네트워크 주소 변경(network address translation)을 

  제공하기 때문에 모든 타입들 중에서 가장 느리다

 - VM에 할당된 CPU의 수는 네트워크 성능을 개선시키지 않는다

   어떤 경우에는 게스트에서 증가된 동시성 때문에 더 느릴 수 있다

네트워크 성능을 개선시키지 위한 짧은 요약

1. 가능할 때마다 virtio 네트워크 어댑터를 사용해라, 그렇지 않으면 Intel PRO/1000 어댑터 중에 하나를 사용해라

2. NAT 대신에 bridged 접근을 사용해라

3. 게스트 OS에서 Segmentation offloading이 사용 가능한지 확인해라

   그것은 보통 디폴드로 설정 되어 있다

   offloading 설정을 변경하거나 확인하고 싶으면 리눅스 게스트에서 ethtool 명령어를 사용해라