Microsoft MVP성태의 닷넷 이야기
Linux: 6. getenv, setenv가 언어/운영체제마다 호환이 안 되는 문제 [링크 복사], [링크+제목 복사]
조회: 13044
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 2개 있습니다.)
Linux: 6. getenv, setenv가 언어/운영체제마다 호환이 안 되는 문제
; https://www.sysnet.pe.kr/2/0/11846

Linux: 11. 리눅스의 환경 변수 관련 함수 정리 - putenv, setenv, unsetenv
; https://www.sysnet.pe.kr/2/0/11915




getenv, setenv가 언어/운영체제마다 호환이 안 되는 문제

C/C++ 프로그램을 만드는 경우 기본적으로 CRT(윈도우의 경우 msvcr, 리눅스의 경우 libc) 라이브러리에 링크하게 됩니다. 그리고 getenv, setenv는 그 CRT 라이브러리에서 제공하는 함수입니다. 문제의 원인은, CRT 라이브러리에 구현된 환경 변수의 처리가 프로세스(EXE, out)의 환경 변수를 직접 다루는 방식이 아니라는 점입니다.

CRT는 처음 초기화 시점에 프로세스의 환경 변수 문자열을 가져와 cache한 다음 이후의 getenv, setenv는 그 영역을 대상으로 처리를 하는 방식입니다. 아래는 이것 때문에 문제가 된 사례의 하나입니다.

When what you set is not what you get : SetEnvironmentVariable and getenv
; https://blogs.msmvps.com/senthil/2009/10/13/when-what-you-set-is-not-what-you-get-setenvironmentvariable-and-getenv/

단적인 예로, 윈도우의 경우 Visual C++가 CRT에 대한 정적 링크를 제공하므로 2개의 DLL을 만들어 CRT를 정적 링크를 하게 되면 DLL마다 각자의 CRT 환경 변수 메모리 영역이 할당되므로 각자 별도의 getenv, setenv가 동작하게 돼서 서로 환경 변수를 공유할 수 없게 됩니다. 게다가 동적 링크를 한다고 해도, 각각의 DLL이 다른 버전의 CRT와 링크를 하게 되면 그것들 간에도 역시 환경 변수 공유가 안 됩니다.

당연한 이야기지만, 이렇게 CRT의 setenv로 환경 변수를 다루는 것은 "Process Explorer"에서 제공하는 환경 변수 탭에서는 확인할 수 없습니다.




CRT가 이렇게, 프로세스가 아닌 독자적인 환경 변수를 가져가는 것은 사실 윈도우 환경에서는 크게 문제가 되지 않습니다. 왜냐하면 윈도우의 경우 프로세스 환경 변수 영역을 직접 다룰 수 있게 해주는 Win32 API를 제공하기 때문에,

SetEnvironmentVariable function
; https://learn.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-setenvironmentvariable

GetEnvironmentVariable function
; https://learn.microsoft.com/ko-kr/windows/desktop/api/winbase/nf-winbase-getenvironmentvariable

대개의 윈도우 프로그램들이 이를 이용하므로 환경 변수의 불일치로 인한 문제가 거의 없습니다. 물론 위에서 언급했지만 CRT의 getenv, setenv를 사용하면 윈도우에서도 문제가 됩니다.




반면 리눅스는 이것을 좀 특이하게 해결(?)합니다. 리눅스의 C/C++ 응용 프로그램은 윈도우처럼 프로세스의 환경 변수 영역을 대상으로 하는 API를 제공하지 않습니다. 따라서 무조건 libc의 getenv, setenv를 가져다 쓰게 되는데 리눅스의 libc 역시 런타임이 초기화되는 시점에 프로세스의 환경 변수를 복사하는 방식으로 동작합니다. 이로 인해, 일단 응용 프로그램이 실행되면 해당 프로세스에서 setenv로 변경한 환경 변수를 확인할 방법이 없습니다. 즉, cat /proc/...pid.../environ으로는,

Show the environment variables of a running process in Linux
; https://ma.ttias.be/show-the-environment-variables-of-a-running-process-in-linux/

libc의 setenv로 변경된 환경 변수가 안 나옵니다. (Win32 API를 사용한 윈도우에서는 Process Explorer로 확인할 수 있다는 점과 대조됩니다.)

재미있는 것은 지난번에도 언급했지만,

Linux 응용 프로그램의 (C++) so 의존성 줄이기(ReleaseMinDependency)
; https://www.sysnet.pe.kr/2/0/11845

일반적인 공유 라이브러리 유형의 리눅스 응용 프로그램은 libc를 정적 링크하는 것이 허용되지 않습니다. 덕분에 공통적인 libc 공유 라이브러리의 환경 변수 영역을 대상으로 getenv, setenv를 연산하므로 환경 변수 불일치 문제가 그나마 완화됩니다.

그런데, 리눅스의 그런 특성으로 잠재적인 문제가 있습니다. 말인즉, 모든 라이브러리들이 libc에 대한 공유 링킹을 해야 환경 변수 처리에 일관성이 있다는 것입니다. 예를 들어, 어셈블리 언어로 libc에 대한 의존성을 갖지 않는 프로그램을 만든다면 환경 변수는 따로 놀 수밖에 없습니다. 이와 유사하게 언어 간에 환경 변수가 따로 노는 문제가 있습니다. 예를 들어, .NET Core 런타임에서 Environment.SetEnvironmentVariable로 설정한 환경 변수를 DllImport로 가져온 C/C++ so 공유 라이브러리 측에서 getenv로 조회할 수 없습니다. 즉, .NET Core 런타임의 경우 libc에 대한 의존성 없이 /proc/...pid.../environ 환경 변수 값을 독자적으로 가져와 처리하고 있는 듯합니다.

이와 마찬가지로 python과 C/C++ 모듈 간의 환경 변수 처리에도 문제가 있습니다. 예를 들어 다음과 같은 shared1.so C/C++ 공유 라이브러리를,

#include <cstdio>
#include <stdlib.h>
#include "dllmain.h"

void test_set_env()
{
    {
        char* chValue = getenv("TEST");
        if (chValue == nullptr)
        {
            printf("[C/C++] TEST=(null)\n");
        }
        else
        {
            printf("[C/C++] TEST=%s\n", chValue);
        }
    }

    {
        setenv("TEST", "2", 1);
        char* chValue = getenv("TEST");
        printf("[C/C++] TEST=%s\n", chValue);
    }
}

다음과 같은 파이썬 코드에서 가져다 쓰면,

import os
import ctypes
import sys

os.environ['TEST'] = '1'
print(os.environ['TEST'])

fun = ctypes.CDLL('/home/usr32/projects/shared1/bin/x64/Debug/libshared1.so')
fun.test_set_env();

print(os.environ.get('TEST'))

os.environ['TEST'] = '3'
fun.test_set_env();

print(os.environ.get('TEST'))

이렇게 동작하는 것을 확인할 수 있습니다.

$ python test.py
1
[C/C++] TEST=1
[C/C++] TEST=2
1                 // C/C++ 측에서 setenv로 TEST=2를 설정했지만 python에서는 1로 반환
[C/C++] TEST=3
[C/C++] TEST=2
3                 

위의 동작을 정리해 보면, python의 경우 C/C++의 환경 변수 변화를 적용하지만 C/C++ 측에서는 python의 환경 변수 처리를 전혀 알지 못합니다. (참고로, 윈도우용 python에서는 os.environ은 내부적으로 Win32 API를 사용하므로 C/C++ 측에서도 Win32 API를 사용하면 환경 변수 공유가 됩니다.)




그렇다면 리눅스의 경우 /proc/...pid.../environ 파일을 대상으로 직접 환경 변수를 문자열 연산해서 set/get하면 되지 않을까요?...라고 생각했었습니다. ^^ 하지만 실제로 해당 프로세스의 정보를 보면,

$ ls /proc/19248/environ -l
-r-------- 1 root root 0  3월 15 09:42 /proc/19248/environ

read 권한만 있으며 설령 이것의 권한을 변경하려고 해도,

$ sudo chmod 755 /proc/21060/environ
chmod: '/proc/21060/environ'의 권한 설정 중: 명령을 허용하지 않음

라고 오류가 떨어집니다. 혹시, 리눅스에서 윈도우의 SetEnvironmentVariable/GetEnvironmentVariable처럼 프로세스 자체의 환경 변수에 접근해 처리하는 방법을 알고 계신 있다면 덧글 부탁드립니다. ^^





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

[연관 글]






[최초 등록일: ]
[최종 수정일: 12/21/2023]

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

비밀번호

댓글 작성자
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13605정성태4/23/2024231닷넷: 2246. C# - Python.NET을 이용한 파이썬 소스코드 연동파일 다운로드1
13604정성태4/22/2024245오류 유형: 901. Visual Studio - Unable to set the next statement. Set next statement cannot be used in '[Exception]' call stack frames.
13603정성태4/21/2024375닷넷: 2245. C# - IronPython을 이용한 파이썬 소스코드 연동파일 다운로드1
13602정성태4/20/2024715닷넷: 2244. C# - PCM 오디오 데이터를 연속(Streaming) 재생 (Windows Multimedia)파일 다운로드1
13601정성태4/19/2024766닷넷: 2243. C# - PCM 사운드 재생(NAudio)파일 다운로드1
13600정성태4/18/2024784닷넷: 2242. C# - 관리 스레드와 비관리 스레드
13599정성태4/17/2024822닷넷: 2241. C# - WAV 파일의 PCM 사운드 재생(Windows Multimedia)파일 다운로드1
13598정성태4/16/2024850닷넷: 2240. C# - WAV 파일 포맷 + LIST 헤더파일 다운로드2
13597정성태4/15/2024820닷넷: 2239. C# - WAV 파일의 PCM 데이터 생성 및 출력파일 다운로드1
13596정성태4/14/20241043닷넷: 2238. C# - WAV 기본 파일 포맷파일 다운로드1
13595정성태4/13/20241050닷넷: 2237. C# - Audio 장치 열기 (Windows Multimedia, NAudio)파일 다운로드1
13594정성태4/12/20241067닷넷: 2236. C# - Audio 장치 열람 (Windows Multimedia, NAudio)파일 다운로드1
13593정성태4/8/20241074닷넷: 2235. MSBuild - AccelerateBuildsInVisualStudio 옵션
13592정성태4/2/20241215C/C++: 165. CLion으로 만든 Rust Win32 DLL을 C#과 연동
13591정성태4/2/20241190닷넷: 2234. C# - WPF 응용 프로그램에 Blazor App 통합파일 다운로드1
13590정성태3/31/20241078Linux: 70. Python - uwsgi 응용 프로그램이 k8s 환경에서 OOM 발생하는 문제
13589정성태3/29/20241150닷넷: 2233. C# - 프로세스 CPU 사용량을 나타내는 성능 카운터와 Win32 API파일 다운로드1
13588정성태3/28/20241255닷넷: 2232. C# - Unity + 닷넷 App(WinForms/WPF) 간의 Named Pipe 통신 [2]파일 다운로드1
13587정성태3/27/20241168오류 유형: 900. Windows Update 오류 - 8024402C, 80070643
13586정성태3/27/20241324Windows: 263. Windows - 복구 파티션(Recovery Partition) 용량을 늘리는 방법
13585정성태3/26/20241106Windows: 262. PerformanceCounter의 InstanceName에 pid를 추가한 "Process V2"
13584정성태3/26/20241059개발 환경 구성: 708. Unity3D - C# Windows Forms / WPF Application에 통합하는 방법파일 다운로드1
13583정성태3/25/20241175Windows: 261. CPU Utilization이 100% 넘는 경우를 성능 카운터로 확인하는 방법
13582정성태3/19/20241433Windows: 260. CPU 사용률을 나타내는 2가지 수치 - 사용량(Usage)과 활용률(Utilization)파일 다운로드1
13581정성태3/18/20241607개발 환경 구성: 707. 빌드한 Unity3D 프로그램을 C++ Windows Application에 통합하는 방법
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...