공유라이브러리라...
안 좋은 점을 이야기하라니 퍼뜩생각나는게 없군요.
질문에 써놓은 초기 로딩이외에는 글쎄요... -)
공유라이브러리 자체가 시스템을 좀더 효율적으로 사용하기위해
개발된 것이기 때문에 일반적으로는 그리 눈에 띄는 점은 없는것
같군요...
답변은 아니지만 비슷한 주제의 글이 있군요.
Link를 시키때 사용하지 않는 라이브러리를 기술했을 때의 결과를
물어보는 것은 직접해보면 알게되겠죠.
대표적으로 파일의 사이즈가 틀려질 수가 있으니까요...
답은 Linker의 역할에 있습니다.
개발자가 아무리 많은 라이브러리를 나열해 놓아도 linker는 실제로
필요한 라이브러리만을 찾아 link를 시키죠.
즉, 개발자는 헛고생만하고 linker는 기술되어있는 것중에 필요한
것만 골라서 사용한다는 결론이 나옵니다.
부작용은 Makefile의 사이즈만 커지고 라이브러리를 기술하기위해
개발자의 시간이 축이 나겠죠.
소켓이나 기타 스트링, 파일, 날짜 등의 처리를 하는 공통 라이브러리를
가지고 있었는데여, 여러 프로그램에서 같이 쓰고 있었거든요.
근데 개발하다보면 첨부터 깔끔하게 모듈이 나뉘는 것이 아니잖아여..
그리고 어떤 부분은 성격은 공통 모듈같은 성격을 가지면서
실제 쓰이는 곳은 한 프로그램에서만 있는 경우도 있고요..
근데 운영중인 서버의 한 프로그램에서 버그가 발견된거예여.
(모든 버그 다 잡은 다음에 운영에 올리라는 말이나
미리 모듈들을 잘 분할하라는 말 하지 마셔여...-_-)
HP나 몇몇 곳에서는 실행중인 프로그램이 쓰는 라이브러리는
mv나 rm이 안되거든여..
그래서 조그만 버그 하나 때문에도 라이브러리를 바꿔야 하기 때문에
그 라이브러리를 쓰는 프로그램들을 모두 내려야 하는 *운영상*의 부담이
있습니다. 내리고 올리는데는 수초나 수십초면 되는데, 예기치 못한 버그
의 가능성, 서비스 중단 등등, 그리고 자신이 '을'의 입장이라면 더욱 더
조심스러워지져.
Re: 공유도서관(shared library)에 대해서 질문합니다.^^
공유라이브러리라...
안 좋은 점을 이야기하라니 퍼뜩생각나는게 없군요.
질문에 써놓은 초기 로딩이외에는 글쎄요... -)
공유라이브러리 자체가 시스템을 좀더 효율적으로 사용하기위해
개발된 것이기 때문에 일반적으로는 그리 눈에 띄는 점은 없는것
같군요...
답변은 아니지만 비슷한 주제의 글이 있군요.
http//www.debian.or.kr/~cwryu/articles/shared-library-mess.txt
Link를 시키때 사용하지 않는 라이브러리를 기술했을 때의 결과를
물어보는 것은 직접해보면 알게되겠죠.
대표적으로 파일의 사이즈가 틀려질 수가 있으니까요...
답은 Linker의 역할에 있습니다.
개발자가 아무리 많은 라이브러리를 나열해 놓아도 linker는 실제로
필요한 라이브러리만을 찾아 link를 시키죠.
즉, 개발자는 헛고생만하고 linker는 기술되어있는 것중에 필요한
것만 골라서 사용한다는 결론이 나옵니다.
부작용은 Makefile의 사이즈만 커지고 라이브러리를 기술하기위해
개발자의 시간이 축이 나겠죠.
Re: 공유도서관(shared library)에 대해서 질문합니다.^^
1. 같이쓰는 책꽂이는 못박힌 책꽂이 비해 혹시 좋은 않은
점이 있을 수도 있나요?
(처음에읽어들이는빠르기가 빠르지 않은것은 빼고)
2. 같이쓰는 책꽂이를 만들기책에 적을때
(가령) -l도서관1 -l도서관2 ...
>1.공유도서관이 정적도서관에 비해 혹시 안좋은 점이 있을 수 있나요?
>(초기로딩속도 느린것 제외)
>2.공유도서관을 makefile에 기술할때 (ex) -l도서관1 -l도서관2 ...
>이중 도서관2가 실제로는 호출되지 않는데 기술했다고 가정할때,
>어떤 부작용(문제점)은 없는지요?
>PS. "도서관"은 라이브러리임.^.^
>즐거운 중추절되세요.
Perfect!
Definitely
프로그램 외적인 문제가 있을 수 있져..
지가 몇번 당해봤습니다.
저희 서버가 여러 프로그램들로 구성되어 있습니다.
소켓이나 기타 스트링, 파일, 날짜 등의 처리를 하는 공통 라이브러리를
가지고 있었는데여, 여러 프로그램에서 같이 쓰고 있었거든요.
근데 개발하다보면 첨부터 깔끔하게 모듈이 나뉘는 것이 아니잖아여..
그리고 어떤 부분은 성격은 공통 모듈같은 성격을 가지면서
실제 쓰이는 곳은 한 프로그램에서만 있는 경우도 있고요..
근데 운영중인 서버의 한 프로그램에서 버그가 발견된거예여.
(모든 버그 다 잡은 다음에 운영에 올리라는 말이나
미리 모듈들을 잘 분할하라는 말 하지 마셔여...-_-)
HP나 몇몇 곳에서는 실행중인 프로그램이 쓰는 라이브러리는
mv나 rm이 안되거든여..
그래서 조그만 버그 하나 때문에도 라이브러리를 바꿔야 하기 때문에
그 라이브러리를 쓰는 프로그램들을 모두 내려야 하는 *운영상*의 부담이
있습니다. 내리고 올리는데는 수초나 수십초면 되는데, 예기치 못한 버그
의 가능성, 서비스 중단 등등, 그리고 자신이 '을'의 입장이라면 더욱 더
조심스러워지져.
static인 경우에는 그런 부담이 없죠.
댓글 달기