sja@sirius.hut.fi (Sakari Jalovaara) (09/25/90)
[Thread started in alt.sys.sun.] > I have the X11r4 shared libraries in /usr/lib, and LD_LIBRARY_PATH set to > "/usr/openwin/lib:/usr/lib". This works - but I'd rather not do it because if I then compile an X program that program will want the non-standard OW versions of the X libraries (I assume Sun/AT&T/whoever changed libX11 instead of changing the library revision number just for fun.) My programs might end up relying on those changes. They wouldn't benefit from the latest MIT public patches. Also, I'd have to set LD_LIBRARY_PATH on remote machines to run OW programs remotely - and I'd have to coax all users to do that too. No way. I'm tempted to throw the OW libXt and libX11 away and install the other OW libraries in /lib. I see two problems: Whenever someone runs an OW program it will bitch about old library versions. Maybe I'll end up binary-patching the library version number in all OW programs. (I don't want to install the real MIT libraries with newer revision numbers, that would just move the problem elsewhere.) Some programs may depend on Sun's/AT&T's changes in the OW libXt and libX11. If this becomes a serious problem, I'll recommend that no-one here use those programs - or the entire OW. Sun shouldn't give "standard" names to non-standard libraries. I installed OW last week but I haven't yet told the users it is there because I want to solve this library problem first. (Real solution? Sun should use the standard MIT X libraries and, if they need fixing, give those fixes to MIT. Until that, I'll consider OpenWindows a beta-test curiosity that can't live with the rest of the system. Too bad, NeWS seems really nice.) ++ Private opinions - $0.02 each - hand-picked this morning. ++sja
Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (09/26/90)
>>>>> On 25 Sep 90 13:23:51 GMT, sja@sirius.hut.fi (Sakari Jalovaara) said: > I have the X11r4 shared libraries in /usr/lib, and LD_LIBRARY_PATH set to > "/usr/openwin/lib:/usr/lib". Sakari> This works - but I'd rather not do it because if I then compile an Sakari> X program that program will want the non-standard OW versions of Sakari> the X libraries (I assume Sun/AT&T/whoever changed libX11 instead Sakari> of changing the library revision number just for fun.) My programs Sakari> might end up relying on those changes. They wouldn't benefit from Sakari> the latest MIT public patches. Also, I'd have to set Sakari> LD_LIBRARY_PATH on remote machines to run OW programs remotely - Sakari> and I'd have to coax all users to do that too. No way. I agree. In case it makes anyone feel better, OSF made similar incompatible changes to libXt. (I recently had to recompile xdvi to allow it to work correctly under olwm.) #pragma BEGIN FLAME ARGH! What's the use of a "standard" when implementors muck around with the semantics?!?! If they want to create their own _additional_ libraries (e.g. Interviews), great. JUST DON'T CHANGE THE INTERFACE OR SEMANTICS OF EXISTING LIBRARIES! Not everyone has source code to the applications they run, allowing them to recompile to be compatible with your incompatibilities. Software vendors should not be required to produce different binaries for olwm, mwm, twm, etc. It defeats the whole purpose of X! #pragma END FLAME Whew! Now I feel better. :-) Sakari> Private opinions - $0.02 each - hand-picked this morning. I'll see that $0.02 and raise $0.02 more. :-) #include <std/disclaimer.h> -- Chuck Phillips MS440 NCR Microelectronics chuck.phillips%ftcollins.ncr.com 2001 Danfield Ct. Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckp