| Summary: | SDL: configure doesn't find xrandr on CentOS 5.11 | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Zenitur |
| Component: | build | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED WONTFIX | QA Contact: | Sam Lantinga <slouken> |
| Severity: | minor | ||
| Priority: | P2 | CC: | philipp.wiesemann |
| Version: | 2.0.3 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Attachments: |
#1 configure log
#2 strings output |
||
Created attachment 2344 [details]
#2 strings output
Sorry for my bad English.
Thank you for reporting this problem. Maybe a newer version of Xrandr is required because there is a check in configure which tests for 1.2 (see "configure.in"). The string might be in the binary because SDL tries to load some libraries at runtime (without linking them before). (In reply to Philipp Wiesemann from comment #2) Can libsdl team make compability with 1.1? CentOS is the base of LSB 4 standard. And libSDL 2 can be successfully compiled there (even no GCC 4.7 enabling required)! The only multi-monitor configurations doesn't work. I can upgrade libXrandr on my build farm. But this is a losing of compability with Enterprise Linux 5. Also I can't put libXrandr with app's tar.gz, it will not work. (In reply to Zenitur from comment #0) > P.S. I really have libEGL (update Mesa from 6.5.1 to 6.5.3). But I haven't > OpenGL ES (not in Mesa and not in proprietary videodrivers). How did > "libGLESv2.so.2" got in strings output? This comes from these lines in SDL/src/video/SDL_egl.c ... #define DEFAULT_OGL "libGL.so.1" #define DEFAULT_EGL "libEGL.so.1" #define DEFAULT_OGL_ES2 "libGLESv2.so.2" #define DEFAULT_OGL_ES_PVR "libGLES_CM.so.1" #define DEFAULT_OGL_ES "libGLESv1_CM.so.1" ...those #defines are used to dlopen() an OpenGL ES library at runtime, if necessary. On desktop Linux, it's usually rare to do so, but support for GLES _is_ available. --ryan. (In reply to Zenitur from comment #3) > Can libsdl team make compability with 1.1? We can not; XRandR 1.1 was intended to control the resolution of a single physical monitor. XRandR 1.2 allows controlling multiple monitors within a larger virtual desktop, and we require this. SDL currently requests XRandR 1.3, but I can't remember why, and the 1.3 protocol summary doesn't suggest we need anything from it, but we definitely need at least 1.2. The configure script looks for XRRScreenResources in libXrandr.so.*, specifically because it's a symbol introduced in 1.2, and this is presumably why it thinks XRandR isn't available on your build machine. Is it really necessary to target RHEL5? Steam doesn't officially support any Linux before 2012, for example...that seems extreme in the other direction, but maybe dropping OS releases from 2007 is worthwhile. --ryan. Hello ryan! Thank you for spent time on me, and for detailed response! > Is it really necessary to target RHEL5? Steam doesn't officially support any > Linux before 2012, for example...that seems extreme in the other direction, > but maybe dropping OS releases from 2007 is worthwhile. I have a dream to make repository, where apps are working in all distros. Not like in Opensuse OBS (that build 50+ RPMs/DEBs), but one binary for all systems. Like a Flash Player, or first releases of Humble Bundle (I've got inspired by them, not by Steam). The reason is I have a good memories about an old Linux (with KDE3, GNOME2, Amarok 1.4, Beagle and Beryl). Sometimes I run Ubuntu 7.10 or SUSE 10.1, and I want to start modern apps there. If proprietary software are distro-independent, it's a problem to get the newest office app on an old distro. In my dream, there are a page in Humble Bundle style, but with apps for work, not games. Fresh versions of Pidgin, LinuxDC++, aMule, Scribus, Inkscape, Dia, KiCad. Ffmpeg + codecs + frontend. The modern version of RPMfusion repo with LSB-compatible Open Source apps. First try was Neko Mario (deps: libSDL 1.2): https://yadi.sk/d/VU8tPelkZrBd7 Second was an Minecraft launcher (deps: Qt 5.3, there was a lot of patching): https://yadi.sk/d/mGDe4DJ6fNLMm Third - PCSX2 (wxWidgets 2.8 had rescued me from unbind this app from GTK 2.24 or put this as a bundled lib) https://yadi.sk/d/AvfHpArKkPzfL Now I have an experiment with app that depends of SDL 2, not 1.2. So I report this feauture request. > We can not; XRandR 1.1 was intended to control the resolution of a single > physical monitor. XRandR 1.2 allows controlling multiple monitors within a > larger virtual desktop, and we require this. If I build Xrandr 1.3 on CentOS 5 build farm, will these binaries work on non-modified CentOS? In theory, this function will hook up when avaliable. I really like what you doing with dlopen(), because when I tried Linux first time, I have many troubles with applications that wants libraries, which are not in repository (and provide functionality that is needed in rare cases). LibSDL isn't crash if I haven't directfb or libjack. (In reply to Zenitur from comment #6) > If I build Xrandr 1.3 on CentOS 5 build farm, will these binaries work on > non-modified CentOS? In theory, this function will hook up when avaliable. I > really like what you doing with dlopen(), because when I tried Linux first > time, I have many troubles with applications that wants libraries, which are > not in repository (and provide functionality that is needed in rare cases). > LibSDL isn't crash if I haven't directfb or libjack. This is the goal; it needs a newer Xrandr mostly for the newer Xrandr headers when compiling SDL, but on the end user system, it won't link directly to the library (so if it's incompatible, or even missing entirely, SDL simply won't use Xrandr). On older systems, your SDL binary will probably try Xrandr, see it can't offer version 1.3, and try to get its work done with Xinerama (which _does_ support multiple monitors) or XVidMode extensions (which doesn't, but that's probably okay)...both of these have been around for a long long time, including into RHEL5. SDL tries to do this in every subsystem, but generally the problem you'll run into on older machines is glibc. You'll link against strcpy() or something totally simple and an older machine will say "oh, you linked against strcpy() version "GLIBC_2.2.5", but I only offer strcpy without a version." (did you know strcpy() has a version number? Surprise!) Anyhow, the short answer is your goal is (mostly) achievable...all SDL needs is the thing installed on your machine so it knows how to talk to libraries like Xrandr, but it'll try to do the right thing no matter what the end-user's system looks like. Go ahead and upgrade your xrandr package and try it out. SDL will only link directly against glibc by default. I'm closing this bug as WONTFIX, because we can't aim for an older Xrandr, but Xinerama and XVidMode will satisfy older machines and your specific concern is (I think?) addressed now. --ryan. |
Created attachment 2343 [details] #1 configure log Hello! I always build binaries for distributing with CentOS 5. They're working on maximum count of desktops before Wayland era. If source code wants new GCC, I enable devtoolset. SDL 2.0.3 have been compiled without errors. But there is no xrandr support! Logs are attached. # yum search xrandr =============================== Matched: xrandr ================================ libXrandr.i386 : X.Org X11 libXrandr runtime library libXrandr-devel.i386 : X.Org X11 libXrandr development package # yum info libXrandr-devel.i386 | grep Version Version : 1.1.1 P.S. I really have libEGL (update Mesa from 6.5.1 to 6.5.3). But I haven't OpenGL ES (not in Mesa and not in proprietary videodrivers). How did "libGLESv2.so.2" got in strings output?