Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 1개 있습니다.)

C/C++ - Windows 10 Version 1607부터 지원하는 /DEPENDENTLOADFLAG 옵션

아래의 글에,

How can I try to escape the disease-ridden hot-tubs known as the TEMP and Downloads directories?
; https://devblogs.microsoft.com/oldnewthing/20230328-00/?p=107978

새로운 옵션이 소개됐군요. ^^

/DEPENDENTLOADFLAG (Set default dependent load flags)
; https://learn.microsoft.com/en-us/cpp/build/reference/dependentloadflag

이 옵션은 LoadLibraryEx의 dwFlags 인자와 동일한 값을 취하고, 그 역할도 같습니다. 단지 차이점이라면, LoadLibraryEx는 사용자가 직접 호출하는 코드에 flags를 지정하게 되는 반면, /DEPENDENTLOADFLAG는 정적으로 링크된 DLL들에 대해 자동으로 적용된다는 점입니다.

일반적으로는 DLL은 다음의 문서에 따라,

Dynamic-link library search order
; https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

제법 복잡한 규칙으로 찾게 됩니다. 자세한 것은 저 문서를 읽어보시고 여기서는 ^^ 저 옵션을 간단한 예제로 테스트해 보겠습니다.




Visual Studio로 C/C++ Console Application과 Dynamic-Link Library 유형의 프로젝트를 각각 생성한 다음, DLL 프로젝트에는 다음과 같이 테스트용 함수를 하나 추가하고,

// Dll1.h

#pragma once

#ifdef DLL1LIB_EXPORTS
#define DLL1LIBRARY_API __declspec(dllexport)
#else
#define DLL1LIBRARY_API __declspec(dllimport)
#endif

extern "C" DLL1LIBRARY_API void test_func();

// pch.cpp

#include "pch.h"
#include "Dll1.h"
#include <stdio.h>

void DLL1LIBRARY_API test_func()
{
    printf("test_func");
}

Console Application에서는 위의 함수를 사용하는 코드를 다음과 같이 넣어둡니다.

#include <iostream>

#include "..\\Dll1\\Dll1.h"
#pragma comment(lib, "..\\x64\\debug\\Dll1.lib")

int main()
{
    std::cout << "Hello World!\n";

    test_func();
}

빌드 하면 ./x64/Debug/ 디렉터리에 각각 다음과 같은 파일들이 생성되고,

ConsoleApplication1.exe
Dll1.dll
...[필요 없는 파일 생략]...

당연히 저 디렉터리에서 실행하면 화면에는 Hello World와 test_func가 출력됩니다. 자, 그럼 여기서 Dll1.dll 파일을 그 부모 디렉터리로 이동한 다음, 그 x64 디렉터리에서 ConsoleApplication1.exe를 실행해 보면 어떻게 될까요?

C:\ConsoleApplication1\x64> dir /b /s
C:\ConsoleApplication1\x64\Dll1.dll
C:\ConsoleApplication1\x64\Debug\ConsoleApplication1.exe
...[필요 없는 파일 생략]...

C:\ConsoleApplication1\x64> .\Debug\ConsoleApplication1.exe

ConsoleApplication1.exe가 위치한 디렉터리에 Dll1.dll 파일이 없는데도 잘 실행이 될 것입니다. 왜냐하면, "Dynamic-link library search order" 문서에 나오듯이 "Current Directory"에서도, 즉 해당 응용 프로그램을 실행한 경로에서도 dll을 찾기 때문입니다.

이제 약간씩 변형을 줘볼까요? ^^ 우선, DEPENDENTLOADFLAG 옵션으로 0xa00 값을 줄 텐데요,

// Linker / Command Line의 "Additional Options"에 명시

/DEPENDENTLOADFLAG:0xa00

문서에 0xa00은 다음의 2개 플래그를 OR 연산한 것입니다.

LOAD_LIBRARY_SEARCH_APPLICATION_DIR 0x00000200
LOAD_LIBRARY_SEARCH_SYSTEM32 0x00000800

그러니까, DLL을 c:\windows\system32 디렉터리와 exe 파일이 있는 디렉터리에서만 찾으라는 의미입니다. 이렇게 빌드하고 다시 위와 같은 상황으로 실행하면 이번에는 다음과 같은 오류가 발생합니다.

ConsoleApplication1.exe - System Error
The code execution cannot proceed because Dll1.dll was not found. Reinstalling the program may fix this problem. 

또한 이벤트 로그에는 다음과 같은 "정보" 항목이 남습니다.

Log Name:      System
Source:        Application Popup
...[생략]...
Event ID:      26
Task Category: None
Level:         Information
User:          SYSTEM
Description:
Application popup: ConsoleApplication1.exe - System Error : The code execution cannot proceed because Dll1.dll was not found. Reinstalling the program may fix this problem. 

왜냐하면, Dll1.dll 파일이 exe와 같은 디렉터리이거나, system32에만 있어야 하기 때문입니다. 대충 느낌이 오시죠? ^^ 그렇다면, 다음의 옵션(LOAD_LIBRARY_SEARCH_SYSTEM32)으로 주고 빌드하면 어떻게 될까요?

/DEPENDENTLOADFLAG:0x800

그럼 dll 파일을 오직 system32 디렉터리에서만 찾기 때문에 exe와 dll 파일이 같은 디렉터리에 있어도 실행되지 않습니다. 따라서 위의 옵션을 주었다면 의존하는 dll을 모두 system32로 복사해야만 합니다.




해보는 김에, 혹시 LOAD_LIBRARY_SEARCH_APPLICATION_DIR만 주면 어떻게 될까요?

/DEPENDENTLOADFLAG:0x200

현재 예제에서는 Visual C++ Debug 빌드를 했기 때문에 다음의 DLL들에 대한 의존성이 있습니다.

msvcp140d.dll
msvcp140_1d.dll
ucrtbased.dll
vcruntime140d.dll
vcruntime140_1d.dll

Visual Studio를 설치한 경우 위의 DLL들은 모두 c:\windows\system32 디렉터리에 있기 때문에 LOAD_LIBRARY_SEARCH_APPLICATION_DIR 옵션만으로 빌드하게 되면 위의 DLL들을 찾을 수 없어 System Error가 발생합니다. 따라서 해당 DLL들을 exe와 같은 디렉터리에 복사해,

C:\ConsoleApplication1\x64\Debug> dir /b
ConsoleApplication1.exe
Dll1.dll
msvcp140d.dll
msvcp140_1d.dll
ucrtbased.dll
vcruntime140d.dll
vcruntime140_1d.dll
...[필요 없는 파일 생략]...

실행하면 정상적으로 구동됩니다. 여기서 재미있는 것은, windows의 시스템 DLL(예를 들어, combase.dll, gdi32.dll, imm32.dll 등)은 이전처럼 system32 디렉터리에서 로드한다는 것입니다. 다시 말해 LOAD_LIBRARY_SEARCH_APPLICATION_DIR 옵션을 줘도 시스템 DLL들은 예외인 것입니다. (사실, 편의상 예외로 할 수밖에 없었을 것입니다. ^^)




비록 이 옵션의 지원은 Windows 10 Version 1607부터지만 개발자에게 있어 지금도 충분한 의미가 있습니다. 위의 설명을 이해하셨다면 눈치채셨을 텐데요, ^^ 보통, 개발된 응용 프로그램을 다른 PC에서 실행할 때 의존성 문제로 고생하는 경우가 있습니다. 바로 그럴 때, 저 옵션을 주고 실행해 보면 되는 것입니다. 최종적으로 실행이 잘 되면, 그 상태의 출력 디렉터리를 xcopy로 복사해 배포하면 끝입니다.

마지막으로 유의해야 할 점은, 저 옵션은 정적 링크된 DLL에 대해서만 통용된다는 점입니다. 코드상에서 LoadLibrary로 DLL 로딩을 시도하면, 그에 대해서는 "Dynamic-link library search order" 문서의 규칙을 적용받습니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 3/29/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 16  17  18  19  20  21  22  23  24  25  26  27  [28]  29  30  ...
NoWriterDateCnt.TitleFile(s)
12945정성태1/28/20226610오류 유형: 791. SQL 서버 로그인 시 localhost는 되고, 127.0.0.1로는 안 되는 문제
12944정성태1/28/20229055.NET Framework: 1143. C# - Entity Framework Core 6 개요
12943정성태1/27/20227880.NET Framework: 1142. .NET 5+로 포팅 시 플랫폼 호환성 경고 메시지(SYSLIB0006, SYSLIB0011, CA1416)파일 다운로드1
12942정성태1/27/20228143.NET Framework: 1141. XmlSerializer와 Dictionary 타입파일 다운로드1
12941정성태1/26/20229530오류 유형: 790. AKS/k8s - pod 상태가 Pending으로 지속되는 경우
12940정성태1/26/20226892오류 유형: 789. AKS에서 hpa에 따른 autoscale 기능이 동작하지 않는다면?
12939정성태1/25/20227624.NET Framework: 1140. C# - ffmpeg(FFmpeg.AutoGen)를 이용해 MP3 오디오 파일 인코딩/디코딩하는 예제파일 다운로드1
12938정성태1/24/20229977개발 환경 구성: 633. Docker Desktop + k8s 환경에서 local 이미지를 사용하는 방법
12937정성태1/24/20227812.NET Framework: 1139. C# - ffmpeg(FFmpeg.AutoGen)를 이용해 오디오(mp2) 인코딩하는 예제(encode_audio.c) [2]파일 다운로드1
12936정성태1/22/20227753.NET Framework: 1138. C# - ffmpeg(FFmpeg.AutoGen)를 이용해 멀티미디어 파일의 메타데이터를 보여주는 예제(metadata.c)파일 다운로드1
12935정성태1/22/20227981.NET Framework: 1137. ffmpeg의 파일 해시 예제(ffhash.c)를 C#으로 포팅파일 다운로드1
12934정성태1/22/20227552오류 유형: 788. Warning C6262 Function uses '65564' bytes of stack: exceeds /analyze:stacksize '16384'. Consider moving some data to heap. [2]
12933정성태1/21/20228070.NET Framework: 1136. C# - ffmpeg(FFmpeg.AutoGen)를 이용해 MP2 오디오 파일 디코딩 예제(decode_audio.c)파일 다운로드1
12932정성태1/20/20228511.NET Framework: 1135. C# - ffmpeg(FFmpeg.AutoGen)로 하드웨어 가속기를 이용한 비디오 디코딩 예제(hw_decode.c) [2]파일 다운로드1
12931정성태1/20/20226548개발 환경 구성: 632. ASP.NET Core 프로젝트를 AKS/k8s에 올리는 과정
12930정성태1/19/20227281개발 환경 구성: 631. AKS/k8s의 Volume에 파일 복사하는 방법
12929정성태1/19/20227075개발 환경 구성: 630. AKS/k8s의 Pod에 Volume 연결하는 방법
12928정성태1/18/20227172개발 환경 구성: 629. AKS/Kubernetes에서 호스팅 중인 pod에 shell(/bin/bash)로 진입하는 방법
12927정성태1/18/20226955개발 환경 구성: 628. AKS 환경에 응용 프로그램 배포 방법
12926정성태1/17/20227486오류 유형: 787. AKS - pod 배포 시 ErrImagePull/ImagePullBackOff 오류
12925정성태1/17/20227532개발 환경 구성: 627. AKS의 준비 단계 - ACR(Azure Container Registry)에 docker 이미지 배포
12924정성태1/15/20229055.NET Framework: 1134. C# - ffmpeg(FFmpeg.AutoGen)를 이용한 비디오 디코딩 예제(decode_video.c) [2]파일 다운로드1
12923정성태1/15/20227929개발 환경 구성: 626. ffmpeg.exe를 사용해 비디오 파일을 MPEG1 포맷으로 변경하는 방법
12922정성태1/14/20227027개발 환경 구성: 625. AKS - Azure Kubernetes Service 생성 및 SLO/SLA 변경 방법
12921정성태1/14/20225917개발 환경 구성: 624. Docker Desktop에서 별도 서버에 설치한 docker registry에 이미지 올리는 방법
12920정성태1/14/20226697오류 유형: 786. Camtasia - An error occurred with the camera: Failed to Add Video Sampler.
... 16  17  18  19  20  21  22  23  24  25  26  27  [28]  29  30  ...