본문 바로가기

GCC

(23)
MinGW(gcc) 에서 pthread 를 찾을 수 없을때. 회사에서 쓰던 pthread 를 집에서 동일하게 사용하기 위해 소스를 컴파일 하는 순간, pthread 를 찾을 수 없다는 컴파일러 오류 메시지를 보게 되는 경우가 생겼습니다.차이를 비교 해 보니, PC에 설치된 컴파일러 버젼이 차이가 있었습니다.(단, 이 방법은 말 그대로 Windows 에서 minGW 를 빌드 할때만 적용 됩니다.) 회사 : minGW 4.4.1집 : minGW 4.7.1 (TDM64-1) 과거를 되돌아 보니, 이전에 집에 설치한 minGW 4.5 버젼대는 FLTK 를 빌드할때 symbol 을 찾을 수 없다는 오류가 발생 하여 빌드를 할 수 없었던 것이 떠올랐습니다. 그래서 TDM package 로 내려받은 2013년2월11일 기준 최신 버젼을 유지해 본 것인데, 4.7 버젼 부터는 ..
MSYS : Windows 에서 리눅스 소스 빌드의 영광을 - -- 이번엔 어떠한 사진도 없습니다, MSYS 에 사진 따위는 사치 ... (라지만 올릴 사진이 없다는 것이 함정) -- Windows 는 애시당초 상용 OS 임에도 불구 하고, 자체 어플리케이션을 개발 할 수 있는 컴파일러나 환경을 전혀 지원 하지 않습니다. 일반적으로 Windows 를 단지 "단순한" 용도로만 쓰는 사람들이야 이런 개발환경을 고려 하거나 생각해야 할 부분이 전혀 없습니다만, 조금이나마 "무엇인가를 만들어 보겠다." 라는 창의성을 가진 사람이라면 이런 폐쇠적인 환경이 얼마나 (OS값이라고 지불해야 하는 금액을 생각하면) 불합리하고 오만한 Microsoft 의 환경에 자신이 처해 있는가를 알 수 있습니다. 혹시나 Visual Studio나 MFC 가 있는데 뭐가 걱정이지요? 하는 질문을 ..
MinGW 4.4.1 이상에서 GDI+ 사용시 컴파일 오류 날 시 이전에 올린 MinGW 에서 GDI+ 사용하기로 제공한 소스를 ...MinGW 4.4.1 또는 그 이상의 버젼의 컴파일러에서 GDI+ 를 쓰기 위해 기존 코드를 이용할 경우 다음 두 오류가 발생 합니다. GdiplusStringFormat.h:243: error: extra qualification 'Gdiplus::StringFormat::' on member 'GetTrimming'GdiplusMetafile.h:350: error: extra qualification 'Gdiplus::Metafile::' on member 'EmfToWmfBits' 이는 다음과 같이 해결 될 수 있는데, 좀 더 요긴 한 처리가 필요하긴 합니다. 먼저, GdiplusStringFormat.h 에서 (242~243 라..
RageDCMV , Free DCM read/write library for standard C++ DCM 파일을 읽고 쓰는 라이브러리를 공개 합니다. 이 소스 코드는 제가 직접 만든 것이며, 누구나 사용하고 활용 할 수 있되, 이 코드에 대한 저작권만 지켜 주신다면 아무런 제한없이 사용할 수 있습니다. 단, 저작권을 벗어난 권리행사 외에는 어떠한 책임을 지지 않으며, 본 소스코드로 제작하신 바이너리나 코드에 대해서는 일절 support 가 가능하지 않음을 먼저 알립니다. source code 는 gcc 에서 빌드 되도록 만들어 졌으며, CodeBlocks 10.05 에서 project 파일이 생성 되었습니다. 32bit, 64bit, MBCS, Unicode 모두 감안하여 만들어 졌습니다. 사용법이나, 활용에 대해서는 main.cpp 를 참조하시기 바라며, 개선하거나 변경 한 소스에 대해서는 반드시 ..
Cygwin+GCC/G++ 에서 POSIX path 지정 오류 발생. (해결) 이전의 문제점 이던, CodeBlocks 에서 새로운 Cygwin w/ gcc/g++ 컴파일 오류는 다음과 같이 해결이 가능했습니다. 간단히, Cygwin 내에서 /usr/bin/ 내용을 확인 해 보니, 다음과 같이 연결 되어 있더군요. /usr/bin/g++.exe 는 /etc/alternatives/g++.exe 를 symbolic-link. /etc/alternatives/g++.exe 는 다시 /user/bin/g++-4.exe 를 서로 symbolic-link 하고 있었던 것 입니다. 그래서 CodeBlocks 에서 직접 /usr/bin 에 있는 g++.exe 를 실행 해서는 컴파일 결과를 얻을 수 없었던 것 입니다. 이 문제는 CodeBlocks 내의 옵션을 다음과 같이 설정 해 주면 됩니다...
Cygwin+GCC/G++ 에서 POSIX path 지정 오류 발생. (원인) 우분투에서 개발이 좀 어려운 면이 있어, console application 개발용으로 Cygwin 과 g++ 를 CodeBlocks 10.05 에서 사용 중 이었습니다만, 구 버젼 cygwin 의 gcc 가 3.4.4 인 관계로 wstring 과 wostream, wistream 등에서 문제가 발생 했습니다. 그래서 gcc 4.5.1 을 쓰는 마지막 cygwin version 을 사용 했더니, 여전히 위와 같이 컴파일 하면 아무런 동작을 하지 않습니다. 혹시나 해서 cygwin shell 에서 컴파일을 해 보니, nodosfilewarning 을 지정하라는 말이 나옵니다. 아무래도 DOS 형태의 지정은 POSIX 에 위배 되는 행우 이겠죠. 일단, 이 nodosfilewarning 이란 오류를 안보기 ..
Visual Studio 에서 import 한 프로젝트를 Code Blocks (gcc/minGW) 에서 빌드 실패 할때. 정말 많은 이유로 Visual Studio 를 싫어 하는 이유중, 그중 하나가 바로 위 이미지처럼 나오는 뭔가의 DLL 이 없어서 오류가 나는 경우 입니다. 멍청한 M$놈들이 지들이 만든 DLL 의 참조 오류가 많아지자, manifest 개념을 도입해서 DLL 특정 위치 해결 점을 어찌저찌 해 보고자 해 놓고선, 컴파일러 자체가 Visual Studio 에서 개발에서 쓰는 DLL 이 없으면 표준 WindowsAPI 로 도는 프로그램이 돌지도 못하게 해 놓은 것이죠. M$ 개발자들이 편하니, 사용자가 되는 VS 개발자가 개노가다 해야 하는 겁니다. 참으로 븅신같은 현상이 아닐수가 없죠. 분명히 프로젝트를 표준 Windows API 만을 사용하는 프로젝트로 만들어도, 저놈의 알수도 없는 DLL 참조 오류는 ..
DICOM tag reader/writer ... 그냥 내가 만들어 쓴다 -> 만들었다. 인터넷을 아무리 뒤져도 ... 그놈의 DCM 파일 읽고 쓰는 라이브러리 만 구하려니 .. 다 상용에다 쓰기도 빡센 이상한 애들 뿐. 그래서 회사에서 팀장님이 구해 준 C# 소스를 주워다 보고 C++ 로 그냥 새로 만들었다. (아 ... C# 으로 만들면 정말 얼마나 낭비가 심한지 다시금 깨닫게 되는 계기가 되기도 ... ) Tag 를 Element 단위로 읽어 들이고 써 주기 때문에 필요한 것 만 수정해서 다시 DCM 으로 만들수 있다. minGW 를 이용해서 만들어 진 상태이며, 코드상에 포인터 계산이나 이런 부분이 모두 integer-safe 코드 이므로 32bit/64bit 모두 사용이 가능하며, little-endian 및 big-endian 모두 사용이 가능하다. 아직은 처음 버젼이라 JPEG,..