차가운 달빛의 lovian

흔하디 흔한 LD_LIBRARY_PATH 또는 SHLIB_PATH에 안잡힌 경우.실행 파일이 32bit로 작동하는데 라이브러리가 64bit에 잡힌 경우. (또는 이 반대의 경우)java vm이 32비트 모드인데 라이브러리가 64bit인 경우. (vm에 따라 -d32 -d64로 설정할 수 있다.)희한하게도 hp의 java vm은 .sl이 아닌 .so파일을 찾는다. 때문에 .sl파일을 찾으려다 실패하는 경우가 종종있었고, 이때마다 해당 .sl 을 .so로 symbolic link로 걸어 해결했다.SHLIB_PATH search가 disable인 경우chart 명령으로 해당 바이너리의 dynamic library 탐색 방법을 보면 위의 값이 disable인 경우가 있다. 이때는 chart명령으로 바꿀 수는 있..

원문: (어디인지 찾는 중..) 동적 실행파일 내에 위치한 코드는 보통 PIC이고, 메모리상에 고정된 주소에 연결되어 있다. 반면에 공유 객체들(Shared Objects)는 다른 프로세스들과 다른 메모리 주소들에 놓여(be loaded)질 수 있다. PIC는 명확한 주소에 묶여 있지 않다. 이 독립성은 이 코드가 이 코드를 사용하는 각 프로세스의 다른 주소에서 효율적으로 실행할 수 있게 해준다. 컴파일러는 -K pic 옵션을 주어 PIC를 생성할 수 있다. 만일 공유객체가 PIC로 만들어졌다면, 텍스트 세그먼트는 실행시(runtime)에 부분적인 변경을 요구 할 수 있다. 이 변경은 재배치 가능한 참조들(reallocatable references)을 그 객체가 놓여(loaded)질 위치에 설정할 수 ..

서블릿 필터 개발시 주의할 점 요놈의 필터를 개발할때에 반 필수적으로 ServletRequest, ServletResponse 인터페이스를 구현하거나 상속 받는다. 가장만만한 것이 랩핑을 이용하는 것이다. 뭐 자세한 방법이야 다들 알아서 잘들 할테지만, 최근 사정상 gzip 필터를 이용할 일이 있었는데, 문제 되는 것들이 많이 보였다. 요약하자면, ServletResponse는 문자열 용으로 쓸 PrintWriter, 바이너리 용으로 쓸 ServletOutputStream 두가지를 사용하는데, 문제있는 gzip filter 들은 요, ServletOutputStream 만을 고려하여 만들어져 있었다. 물론 filter를 적용한 Web Application Server에 따라서 다를 수 있겠지만, 본인이 ..

프로세스의 정보를 알아내기 위해서 pstat_getproc 를 이용하기로 하였다. 마침 원하는 정보가 있었기에 아무 부담없이 사용하며 잘 작동하였다. 처음에는 64비트로 테스트를 했었는데, 문득 32비트가 궁금해서 테스트를 시도했더니. ERRNO 72 EOVERFLOW와 함께 실패했다. 사유를 알아본 즉. 32비트 모듈이 32비트 프로세스의 정보를 pst_status(pstat_getproc에 넘겨줄 정보를 넣을 구조체)에 입력하는데에 아무 지장이 없겠지만. HP-UX머신에는 32/64 바이너리가 혼재하여 있으므로 64비트 프로세스의 정보를 32비트 구조체에 정보를 입력하는데에 문제가 발생한다고 한다. 이번에도 컴파일 플래그로 해결이 되었다. 그리고 그 값은 _PSTAT64 이다. 예를 들면 cc -D_..

more undefined references to `__stack_chk_fail_local' follow linux에서 빌드를 하다보면 이런 링크 에러메시지를 만날 수 있다. 당최 어디있는지도 모를 것을 왜 참조하는지 궁금하다. gcc 4.x 이상부터 있는 stack protector란 녀석을 사용하기 위해서 자동으로 링크되는 것으로 보인다. gcc 4.x 에서 빌드한 라이브러리를 gcc 3..x 에서 링크하여 쓸려고 했기 때문에 이런 문제가 발생한다. 해결책은. 4.x 이상에서 빌드할때에 -fno-stack-protector 옵션을 주라고 한다. 해보진 않았다 ㅋㅋ

정말 사람 이상하게 만드는 메시지다. 단지 웹으로 CVS 내용을 보고 싶어서 들어가면, 이 메시지가 떠 볼 수 없는 경우가 있었다. Apache와 연동시켜 돌아가고 있는데 이 메시지로는 아무런 해결을 볼 수 없었고. StandardAlone으로 작동시켜보니 rlog 파일이 없다는 메시지를 확인했다. 확인해 보니 정말로 존재하지 않았다. 해당 바이너리를 구해서 넣어주자 올바르게 작동했다.

웹서비스 클라이언트는 보통 세가지 종류로 만들어진다. 사용 환경이나 목적에 따라서 Static Stub, Static Proxy, Dynamic Invocation Interface 를 사용한다. 어떤 것을 사용하던간에 jaxrpc의 Call, Service 인터페이스를 가져올 수 있는 것으로 보인다. 하여간 첨부를 하려면 해당 자료형을 변화하는 (De)Serializer가 필요하다, DataHandler에 대한 시리얼라이저는 따로 제공되지 않기 때문에, WAS에 있는 것을 사용해야한다. 시리얼라이저를 등록하기 위해서는 TypeMapping 인터페이스를 사용하면 된다. Service 인터페이스에서 TypeMappingRegistry 를 가져오고 TypeMappingRegistry에서 시리얼라이저를 QNa..

XSLT를 이용하여 XML문서 변환을 하려고 xalan을 이용할 수 있다. 그런데 희한하게도 이 xalan이 적용이 되지를 않는다. 그렇다고 특정 Class가 존재하지 않는 것도 아니다. JDK 버젼에 따라 다를 수 있는데, 1.4.x 이상 부터는 xalan가 rt.jar에 포함되어 있다. xalan의 버그패치나, 신 기능을 사용할 것이 아니라면 xalan을 따로 가지고 다닐 필요가 없다는 말이다. 혹시라도 최신 xalan을 사용하려면 endorsed에 집어 넣는 법을 사용해야겠다.

무엇인가에 대해서 기억해야하지만, 사람의 기억에는 한계가 있기 마련이므로 메모를 하게 된다. 나도 기억력이라면 남 서러워할 정도로서 메모가 필수적인 인간이다. 그럼에도 메모를 잘하지는 않지만, 컴퓨터가 전공인지라, 컴퓨터로 관리할 생각을 많이 한다. 그렇지만, 도저히 지킬수 없는 약속이나 다름없었다. 내가 기억해야할 것들은 보통 일상적인 것이니까, 밖에 나가서는 아무 쓸모 없는 것다. 다이어리를 들고 다니기에는 잊어버릴 것 같기도 하고 귀찮기도 하고 여러모로 불편하다. 그래서 간단한 메모지를 주머니에 구겨넣고 필요할 때에 꺼내보며 다닌다. 왠만한 메모지는 모양이 서로 달라 들쑥날쑥한데 아래에 소개된 사이트에서는 A4용지를 접어 작은 다이어리 만드는 법을 소개한다. 제법 괜찮은 생각이다. 그러나.. 이 저..

내가 담당하고 있는 서버에 하드디스크 공간이 부족하다. 물론 필요없는 내용을 날려버리거나 백업하면 되지만, 날리는 것은 당연히 문제가 있고, 백업하기에는 좀 찝찝하다. 그래서 하드디스크를 추가하기로 하였다. format -> format -> label -> partition -> label 이런 순으로 커맨드를 입력하여 포맷까지는 완료하였으나 파티셔닝과 마운트를 도저히 할 수가 없었다. 결국 검색 끝에 여기 에서 설명한 것을 그대로 따라하여 성공하였다. 내가 부족했던 것은. newfs로 파일 시스템을 생성후에 마운트의 디바이스를 하드웨어로 설정한 것이다. 즉 /dev/rdsk/c#t#d#s# 으로 설정하여 파티션을 못찾았고 /dev/dsk/c#t#d#s#으로 설정하자 올바르게 마운트 되었다.