#2815 gnuplut v6.0.3 for OS/2 doesn't support OS/2
gnuplut v6.0.3 is NOT compatible with OS/2, but probably works with another (rebranded) operating system. Please stop referring to OS/2, when OS/2 isn't supported anymore. It's a bit like a gnuplot for Windows 95, which requires Windows XP.
A common problem, due to bad library management of people in charge. Or rather lacking management. No problem with dropping OS/2 support as such, but please stop calling software "for Windows XP " software "for Windows 95".
A technical problem appears to be GCC321M.DLL, which requires a specific version of a EMXLIBCM.DLL. Which is not included, and which may be too "modern" for OS/2. My OS ships with a EMXLIBCM.DLL, which may be "too old".
GNUPLOT_X11.EXE also wont work, due to the same implied requirement. And X11.DLL doesn't work, for the same reason.
You have have to rename the OS_-part of the file name to "ArcaOS", while claimed OS/2-software should be 80386-software.
A solution could ne to include a 80386-compatible DLL, or link such a DLL statically. Otherwise it's probably not OS/2-software anymore.
If the problem only applies to using X11, I don't know that nor have I checked that, then another option could be a release for OS/2 without X11 support, and optionally a release for a rebranded OS with X11 support.
So options may be to rename the non-OS/2-product by dropping OS/2-support, to release a version for OS/2 without X11-support (a a version for another OS with X11-support) if only that is affected, xor to include a 80386-compatible EMXLIBCM.DLL (DLLs statically linked, preferably).
Screenshot, which shows the probem, included. Most likely it requires an informal version of EMXLIBCM.DLL, which doesn't support OS/2 anymore but probably pretends to be OS/2-software. Like I stated, it's a bit like still calling 100% Windows XP-software "software for Windows 95", and I would still be using Windows 95 in that case.
Thank you for testing the new package and providing feedback, as well as your appreciation of my attempt to provide executables on this dated platform. In an attempt to provide technical clarification, I will not get involved in the discussion if a product not being shipped by IBM may be called "OS/2", though.
gnuplot.exe is the main executable. It is compiled using gcc 9.2 by Bitwiseworks. The compiler and the libraries were installed using yum/rpm using packages from the Netlabs and ArcaNoe repositories on an eCS 1.2 system. They all assume a Pentium4 CPU or newer and executables depend on the LIBC next and LIBCX runtime libraries. I will add the CPU requirement - which I assume to be your issue - to the README. The zip file should include all non-system libraries required. Note that gnuplot.exe does not depend on emxlibcm.dll. If the CPU is not the issue, it would be helpful if you could explain the actual failure mode,
gnuplot_x11 is the X11 "terminal" executable (i.e. not something you would start yourself normally). It is compiled with A. Zabalotny's version of gcc 3.2.1 in order to be able to use libX11 which relies on the EMX libraries. The "special" version of emxlibcm I am using is the plain old EMX 0.9d fix 4, dated 2001. https://www.os2site.com/sw/dev/emx/emx_v09d/emxfix04.zip This (or an earlier version) are very likely to be available on any OS/2 system. I have no idea why it would not load on your system. Note that gnuplot_x11 is not even started unless you use the "x11" terminal in gnuplot.
Your technical conclusion about a dependency on anything specific to ArcaOS (or eComStation) seems premature. Of course it could be that in particular the LIBCN/LIBCX libraries would introduce such a dependency, but I would not now about it.
The DLL situation can indeed be challenging and frustrating. The package attempts to address this by including the required DLLs. If that is failing, I would like to understand why and how to possibly resolve that. AFAIK the yum/rpm repos I use only provide shared libraries. If there is an alternative providing compiled static libraries, please let me know.
While the README.OS2 file should reflect (and probably also the file name of the package) the requirement for a Pentium 4 CPU, I strongly disagree that that alone would make the package "non-OS/2".