[완료]소스설치에 관한 질문.
글쓴이: SilverWhalle / 작성시간: 수, 2008/02/13 - 11:27오후
아~ 정말 단 한번만이라도 소스설치 성공할수만 있다면 좋겠습니다...
소스설치를 성공한적은 예전에 간단한거 한번 있었던것 같기도 하고 아닌것 같기도 하지만, 어쨌든 소스로 패키지를 성공적으로 설치해본 경험은 없다고 해도 됩니다.
하지만 ./configure는 성공을 여러번 해 봤습니다만.. 여기서 의문점이 있습니다.
./configure하면 수많은 checking 구문이 나옵니다.
checking for nsleep... no
...
위와 같은 구문들이죠. nsleep을 체크해보니 당신은 갖고 있질 않구나.. 이런 뜻이죠?
근데 왜 성공하는거죠? 제가 잘 모르지만 감으로도 ./configure 의 마지막에 configure error란 말이 없고 'creating docs/Makefile'과 같은 구문들이 줄을 지으면 1단계는 성공했다라는 감이 옵니다. checking에선 분명 수많은 'no'메세지가 뜨면서 성공하는 이유는 무엇인가요? 위와 같은 상황시 nsleep은 절대적으로 필요한 것은 아니란 말인가요?
그리고 현재 glib 설치중인데.. 아니 설치가 끝났습니다. 물론 소스설치로요..
근데 문제는 pango를 설치하려고 ./configure이라고 하면 glib버전이 2.12라고 우깁니다. 저는 분명 glib-2.14.5를 구해서 설치했습니다. 그런데 pango가 아니랍니다. 이러니 설치됐다고 하지도 애매한 상황입니다.
Forums:
"위와 같은 상황시
"위와 같은 상황시 nsleep은 절대적으로 필요한 것은 아니란 말인가요?"
==> yes..겠죠? 혹은 A나 B 둘 중 하나가 필요한 경우 A가 yes, B가 no인 경우도 있습니다.
"./configure이라고 하면 glib버전이 2.12라고 우깁니다. 저는 분명 glib-2.14.5를 구해서 설치했습니다."
==> 이건 정확한 답은 아니지만.. 경험상으로 볼 때 /usr 밑에는 glib-2.12가 깔려 있고, 직접 구해 설치하신 것이 /usr/local에 깔렸다든가 하는 경우일 수 있습니다. 여튼 중복설치 되었을 가능성이 있을 듯 합니다.
소스로 설치하는 것은 요구하는 라이브러리가 많지 않다면(Sun OS에 Subversion 설치하느라 무척 힘들었던 적이 있습니다) 저는 보통 어렵지 않게 되는데 안타깝네요.
노루가 사냥꾼의 손에서 벗어나는 것 같이, 새가 그물치는 자의 손에서 벗어나는 것 같이 스스로 구원하라 -잠언 6:5
방금 소스설치 하나 성공하고 오는 길입니다.
방금 소스설치 하나 성공하고 오는 길입니다.
우와~ 기분 좋네요.. 물론 간단한겁니다. sudo 설치했습니다. ㅋㅋ
자꾸 make에서 /usr/bin/ld: cannot find -lpam 이라는 메세지가 떠서 고생하다가 겨우 KELP에서 비슷한 사례를 찾아내었고 '#ln -s /lib/libpam.so.0 /lib/libpam.so'로 심볼릭을 만들어줘야 되는 경우라는걸 알아냈습니다. 뭐 이런거 보고할 필요는 없는데 말이죠.ㅎㅎ
일단 답변감사하구요.
답변주신대로 중복설치인것 같습니다. $dpkg -s libglib2.0-0 으로 확인해 보면 2.12로 정보가 뜨더라구요. 뭐, 이런식으로 패키지 설치여부를 확인하는것이 맞는진 모르지만요. 그러면 이런 경우엔 기존의 glib을 제거해준뒤에 다시 설치해야 하는것인가요?
그리고 추측하신대로 제가 구해 설치한건 prefix옵션으로 /opt/glib에다가 설치한겁니다.
"==> yes..겠죠? 혹은 A나 B 둘 중 하나가 필요한 경우 A가 yes, B가 no인 경우도 있습니다."
답변중 이부분은 이해가 안됩니다. yes..겠죠?라는 말은 무슨 뜻이신지.. 질문글에 있는대로입니다. yes로 뜨는것도 있는가하면 no로 뜬것들도 꽤나 됩니다.그중에 대표로 nsleep이 제 눈에 걸린거구요.
음... 제가 알콜
음... 제가 알콜 복용중이라 정확한 답변이 되지 못할 수 있지만...
no 라고 나오든, yes 라고 나오든, 그건 크게 중요치 않습니다. no 라고 나왔는데, configure 실행을 중단하지 않았다면, 그 소스의 개발자 스스로 그런 경우에도 대비하고 있었던 것이구나 생각하시면 될 것 같습니다.
물론 no 가 나왔는데, configure 는 실패하지 않았음에도 불구하고 build 가 안되더라, 이럴때는 쌍시옷을 한 번 날려주시고 삽질을 하시던지, 포기 하시던지, 아니면 테스트를 반복하신 뒤 버그 리포트를 날려주는 등을 하시면 될 것 같네요.
대개는 configure 는 config.h 를 생성하는데, 이 파일에는 #define 심볼들을 다수 포함하고 있고, config.h 를 인클루드 하는 소스들에서 적절하게 상황판단을 할 것입니다. ( #ifndef 뭐 이런 거요... ) 적절하게 못하면, 뭐 그런 것도 버그라 할 수 있겠죠. configure 를 멈추지 않고 넘어가 놓고서는 제대로 못하는 것이니까요.
그리고, ln 명령을 쓰는 것은 소스 설치의 기본입니다. 그런 것에 너무 스트레스 받을 필요는 없을 것 같고, 익숙해지면 당연시될 것 같네요...
Orion Project : http://orionids.org
아..
알콜복용중에도 답변을 써주셔서 감사합니다.
그런거군요. no가 나와도 configure가 진행된다는건 염려할만한 일이아닌거군요.
이제 두가지를 알게 되었군요. 버전이 잘못된건 중복설치일때이고, configure에서 no라는 메세지는 그리 문제될게 없다는 사실을요..
하지만 아직 중복설치일때 대처하는 방법은 알지 못합니다. 여기서부턴 다시 제 몫인가요? 찾는데 실패했는데, 다시 무한검색루프에 빠져야 되겠군요.
아, 그리고 답변주신분들만한 실력이 되려면 configure 스크립트를 한번 분석해 봐야 하는것인가요? 그러면 configure가 어떤일을 하는지 알게 될 것이고.. 각 메세지에 대한 대처능력이 더 높아질거라 생각되는데요. 물론 라인수가 장난아닌게 겁이 엄청납니다만..
음.. no 가 나오면
음.. no 가 나오면 염려할만한 일이긴 해요... 빌드가 잘 안됐을때는요. 근데 빌드 되면, 뭐 그런거죠. -_- 빌드가 잘 안되더라 했을 땐, no 가 중요한 일일 겁니다.
증복 설치나, ln 같은 건 미리 염두에 두시고 하시면, 일단 안됐다 했을 때 먼저 체크해보실 수 있을 것 같습니다.
실력은, 뭐 실력이라기보다는, 뭔가 안됐을 때 각 개인마다 대처하는 방식의 차이라고 봅니다. 안되면, 쌍시옷 안되네, 하고 그만 두거나, 질문을 하거나... 아니만, 안되네하고 삽들고 땅파거나 뭐 그런거요....
Orion Project : http://orionids.org
흐~
그 늬앙스는 느끼고 있었습니다. 제가 염려할만한 일이아니군요라고 받아들여서 완전히 마음을 놓은건 아닙니다. 염려할 필요가 없지만 염려는 해야한다랄까요.. 그런 느낌이 오네요. 빌드가 안된다면 configure가 진행이 되더라도 제대로 안된거라고도 볼 수 있을 것이고, 그렇게 되면 configure에서 no메세지가 단서가 될 테니깐요.
거의 대부분을 소스
거의 대부분을 소스 설치로 하는 젠투 사용 경험을 떠올리면 ./configure 수행할 때 no 메시지는 신경쓰실 필요 없습니다.
configure 명령이 하는 일은 아마도 '컴파일 환경 파악' 같습니다. yes, no를 된다, 안된다가 아니고 on, off 정도로 생각하시면 될 것 같습니다. 뭐 그 검사중에 개발자가 필수라고 선택해 놓은 사항이 no 라고 파악되면 에러를 뿜고 멈추지 않을까 생각 됩니다.
제가 살짝 신경쓰이는 것은 소스 컴파일을 굳이 하셔야 하는 상황이냐는 것인데요. 일반적인 리눅스 배포본 사용자 분들이 배포본의 패키지 관리자를 사용하지 않고 굳이 해당 패키지의 소스를 직접 받아다 설치하는 경우가 있는데 이는 명확한 이유가 없다면 불필요한 일이라고 말씀드리고 싶습니다.
다시 말해서 배포본에서 간단하게 설치가 지원되는 패키지인데 소스로 받아다 설치하고 계신 것은 아닌지... 이런 경우 컴파일시의 의존성을 가지고 있는 패키지들을 모두 설치해야 하므로 보통 환경에서는 컴파일이 안되는 상황이 계속 이어집니다.
--
마잇
--
마잇
흐흣~
저에겐 명확한 이유가 있습니다. 그래서 일부로 소스설치를 하고 있는거라서요. ㅎㅎ
저는 그냥 데스크탑으로 리눅스를 써보고자 하는 의도가 아니라, 컴퓨터의 시스템깊은 부분까지 다 알고 싶다는 생각이 발전해서 소스가 숨어있는 윈도우보단 소스가 공개되어있는 리눅스가 낫겠다라는 생각으로 리눅스를 접했습니다. 그래서 패키지 하나 설치되는것도 그게 어떤 원리로 어떤 과정에 의해 설치되는것인지 알고 싶은겁니다. ㅎㅎ.
아 제가 yes라고 한 건
1. 아 제가 yes라고 한 건 생각하신 이유가 맞다는 얘깁니다.
윗분들 얘기처럼 no라고 나와도 configure 에러가 발생한게 아니면 걱정하실 문제가 아닙니다.
2. 중복 설치 문제가 맞다면 예전걸 지우고 /usr에 새로 설치하든지, 아니면 라이브러리나 실행파일 경로를 추가해 주든지 등등의 조치가 필요할 듯 하네요.
3. 정말 진정한 순수 소스 설치를 원하신다면 'Linux from scratch'를 검색해서 살펴 보시기 바랍니다.
노루가 사냥꾼의 손에서 벗어나는 것 같이, 새가 그물치는 자의 손에서 벗어나는 것 같이 스스로 구원하라 -잠언 6:5
아..
아.. yes가 그런 뜻이군요. 그런데 예전걸 지우는건 방법이 아닌듯 합니다. 시냅틱에서 한번 glib을 검색해서 glib2.0-0이던가? 패키지를 제거하는 흉내를 내 봤더니, glib에 걸린 의존성이 장난이 아니었습니다. glib을 지운다는건 gnome을 없애는 말이더라구요. 후자를 택해야 할 것 같습니다. 아직 찾지못한 사이트네요. 감사합니다. 쭉 읽어 봐야겠네요.
댓글 달기