Prelink/ko

이 안내서에서는 Portage 2.0.46 이상의 버전에서 지원하는 prelink를 어떻게 사용할 수 있는지 알려줍니다.

Prelink가 무엇이고, 어떻게 도움을 받을 수 있나요?
대부분의 일반 프로그램은 공유 라이브러리를 활용합니다. 이들 공유 라이브러리는 실행 시간에 메모리로 불러와야 하며 다양한 심볼 참조를 해석해야 합니다. 대부분의 작은 프로그램은 동적 연결을 매우 빠르게 처리합니다. 그러나 C++로 작성한 프로그램이고 수많은 라이브러리 의존성을 지녔다면, 동적 연결에 상당한 시간이 필요할 수 있습니다.

대부분의 시스템에서는, 라이브러리가 자주 바뀌지 않으며 프로그램을 실행할 때, 프로그램과의 연결 처리가 동시에 일어납니다. Prelink는 실행 파일에 미리 연결하는 것과 같이 실행시 연결 및 라이브러리 저장을 처리하는 장점을 취합니다.

선 링크는 프로그램의 시작 시간을 줄일 수 있습니다. 예컨대, 보통의 KDE 프로그램을 불러오는 시간은 최대 50% 가량 줄일 수 있습니다. 이 과정의 관리상 실행 파일에 미리 연결하기 위해 업그레이드한 라이브러리를 매번 선연결 처리를 위해 prelink를 다시 실행하기만 하면 됩니다.

요약

 * 놀랍게도 바이너리와 동적 라이브러리와의 선연결은 를 실행하면 됩니다. 바이너리를 좀 더 빠르게 실행할 수 있게 바꿉니다.
 * 프로그램에 동적 라이브러리를 선연결한 후 의존 라이브러리가 바뀌면, 프로그램과 재-선연결이 필요하며, 그렇지 않으면 속도 이득을 잃게 됩니다. 이는 곧, 라이브러리를 업데이트하는 포티지로 꾸러미를 업데이트할 때마다 매번 재-선연결을해야 한다는 얘기입니다.
 * 바이너리가 바뀌면 완전히 되돌릴 수 있습니다. 에 실행 취소 기능이 있습니다.
 * 포티지 현재 버전에서는 로 바이너리의 MD5sum과 mtime을 바꿔 처리할 수 있습니다.
 * 파일에서 값을 설정할 필요가 없습니다. 포티지에서는 선연결 바이너리를 찾을 수 있으면 선연결을 자동으로 지원합니다.

프로그램 설치
먼저  도구를 설치해야 합니다. 이머지 과정에서는 시스템에서 안전하게 선연결을 할 수 있도록 자동으로 검증합니다.

테스트에 실패하는 문제로 prelink 이머지 중에 수많은 사람이 오류를 만납니다. 테스트는 안전을 이유로 실시하지만, 테스트를 비활성화하면 prelink의 동작이 정의되지 않습니다. 이머지 오류는 보통 핵심 꾸러미, binutils, gcc, glibc에만 관련이 있습니다. 이들 꾸러미를 순서대로 다시 이머지해보십시오.

다른 시스템에서도 나타나는 이머지 오류를 재현하는 단계를 안다면, 버그질라 를 방문하여 이미 보고한 문제점이 아니라면 보고해주십시오.

시스템 준비
또한 CFLAGS/CXXFLAGS에 -fPIC를 설정하지 않았는지 확인하십시오. 설정했다면 해당 옵션을 빼고 시스템 전체를 빌드해야합니다.

설정
Running  will generate the  file that tells  which files to prelink.

Unfortunately you cannot prelink files that were compiled by old versions of binutils. Most of these applications come from pre-compiled, binary only packages which are installed in. Making the following file will tell prelink not to attempt to prelink them.

prelink 사용법
I use the following command to prelink all the binaries in the directories given by.

Prelink 크론 작업
and later install a cron job in. To enable it, edit the configuration file. This will run prelink daily in the background, as needed, saving you running the command manually.

prelink 실행 후 KDE 속도 개선
KDE's loading time can be greatly reduced after prelinking. If you inform KDE that it has been prelinked it will disable the loading of  (as it isn't required anymore) which speeds up KDE even more.

Set  in  to inform KDE about the prelinking.

선(先)연결 제거
If you ever change your mind about prelinking, before you unmerge prelink, you'll first need to remove the prelink cronjob from and. Next, you'll have to remove prelinking from all binaries:

마지막으로  자체를 제거하십시오:

"Cannot prelink against non-PIC shared library"
The cause of this problem is from badly compiled shared libraries that were compiled without the -fPIC gcc option for all their object files.

Here are the libraries that haven't been fixed or cannot be fixed:


 * The libraries in the wine package, including winex. Prelinking wouldn't speed up MS Windows executables anyway.
 * The library in media-video/mjpegtools,.
 * Nvidia OpenGl libraries, . Due to performance reasons they were compiled without PIC support.

If your problem library was not listed please report it with, preferably, a patch to add  to the relevant CFLAGS.

시스템을 prelink 할 때 일부 바이너리가 더이상 동작하지 않습니다
glibc는 100% 정적 바이너리만 있다고 간주하지 않습니다. glibc로 바이너리 정적 컴파일을 한다면, 여전히 다른 시스템 파일에 의존할 수도 있습니다. Dick Howell의 설명을 살펴보겠습니다:

"I suppose the idea is that everything will be in the downloaded file, so nothing depends on the local libraries on the target system. Unfortunately with Linux, and I think anything else using GLIBC, this still isn't quite true. There's this "libnss" (name service switch, some people seem to call it network security system) which provides functions for accessing various databases for authentication, network information, and other things. It's supposed to make application programs independent of the separately configured actual network environment of the machine. A nice idea, but changes to GLIBC can lead to problems loading it. And you can't statically link "libnss", since it is configured for each machine individually. The problem comes, I think, mainly from statically linking other GLIBC libraries, notably "libpthread", "libm", and "libc", from which come incompatible calls to "libnss" functions."

Prelink가 "prelink: dso.c:306: fdopen_dso: Assertion `j
k' failed." 메시지에서 멈춤 ===

This a known problem, kindly diagnosed here. Prelink cannot cope with UPX-compressed executables. As of prelink-20021213 there is no fix except to hide the executables while you are prelinking. See the section above for an easy way to do this.

grsecurity를 사용하는데 prelink가 동작하지 않는 것 같네요.
In order to prelink on a system with grsecurity using a randomized mmap base, it is necessary to turn "randomized mmap base" OFF for. This can be done with the  utility, but it must be done when the file is not in use (f.i. boot from a rescue CD).

Prelink fails with error "prelink: Can't walk directory tree XXXX: Too many levels of symbolic links"
Your symlinks are nested too deeply. This happens when a symlink points to itself. For example, is the most common. To fix this, you can find the symlink manually or use the utility provided by the  package:

More details can be found at Bugzilla and this forum post.

마무리
Prelinking can drastically speed up the start up times for a number of large applications. Support is built into Portage. Prelinking is also safe as you can always undo the prelinking for any binary if you come across any problems. Just remember that when you update glibc or other libraries that you prelinked with, you need to rerun ! In short good luck!