"합리적인" Linux 적용 범위를 얻으려면 몇 개의 바이너리가 필요합니까?

죄송합니다. 순전히 의견에 근거한 것입니다. 다른 곳에 물어봐야 하는지 알려주세요.

나는 바이너리 형태로 배포되어야 하는 무료 엔지니어링 소프트웨어(그래픽 없이 명령줄)를 작성하고 있습니다. 질문: "합리적인" 사용자 적용 범위를 얻으려면 몇 개의 서로 다른 바이너리를 생성해야 한다고 생각하시나요? 내 추측으로는 잠재 사용자의 약 70%가 전문적인 환경에 있고, 그 중 절반 이상이 RHEL6 또는 RHEL7의 파생 버전을 실행하고 있을 것입니다. 일부는 openSUSE를 실행할 수 있지만 데비안을 사용하는 사람은 없습니다.

나머지 30%는 아마도 학생/애호가 등일 것입니다. 이들 중 다수는 Ubuntu 또는 유사한 운영 체제를 실행하고 있을 것입니다. 나는 본업에 종사하고 있으며 실제로 많은 시간을 할애할 수는 없으므로 100% 적용 범위를 확보하고, x86_64가 아닌 아키텍처를 지원하고, 컴파일 및 테스트를 위해 여러 배포판을 다운로드하거나, 배포판은 최신이자 최고이기 때문입니다.

코드는 Centos-6에서 작성되었으며 테스트용 동적 및 정적 바이너리(Windows용 msys64 바이너리도 포함)를 생성합니다. 분명한 선택은 LSB 버전을 만드는 것이지만, 그것이 실제로 나에게 도움이 될지, 아니면 그냥 우분투를 설치하고 우분투 버전을 출시하는 것보다 더 나을지는 잘 모르겠습니다.

어떤 아이디어가 있나요?

편집 - 추가 정보:

어려운 외부 종속성이 없는 (C++) 코드 - ldd보고서

linux-vdso.so.1 =>  (0x00007ffd197cf000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000039cb400000)
libm.so.6 => /lib64/libm.so.6 (0x0000003e63e00000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000039cac00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003e63200000)
/lib64/ld-linux-x86-64.so.2 (0x0000003e62e00000)

정적 버전 -static -static-libgcc은 fileGNU/Linux 2.6.18과 연결되어 있다고 보고되는데, 이것이 문제가 될 수 있을 것 같습니다. 코드는 flex, bison 및 Antlr을 사용합니다. Bison 버전 관리는 새 시스템으로 포팅할 때 유일한 실제 문제이지만 지금은 이를 수정하기 위해 C++ 출력을 유지하고 있습니다.

나는 그것이 얼마나 강력한지 확인하기 위해 많은 시스템에서 정적 버전을 실행해야 할 수도 있다고 생각합니다.