Unfortunately,  proprietary vendor applications for which the vendor 
does NOT release source, or does so with a dependence upon libraries or 
other applications for which source is not available, typically are 
impossible to port but instead require a "container" if the application 
requires a specific base dynamic (.so) library that fundamentally 
conflicts with the base Linux system.  Most such vendors do not produce 
a self-contained version or a version using only static libraries (.a) 
to avoid dynamic dependencies.  Some do provide full environments (e.g., 
Qoppa PDF Studio Pro that I use as a Linux replacement for Adobe PDF 
editing and composition applications), but these typically are "small".

That is one of the issues with RHEL as a base -- RHEL quickly gets quite 
far behind the current enthusiast distributions (e.g., Ubuntu), and 
purportedly significantly "behind" SuSE Enterprise. Note that a number 
of specialist vendors seem to be using a SuSE Enterprise base for 
building because that distribution seems to strike a different 
compromise between security, stability, and a more current environment 
than does RHEL.  For my work, I insist on EL on all primary 
servers/workstations, although a colleague at our site is maintaining a 
small OpenSuSE based system for our own testing and compatibility 
purposes (OpenSuSE is similar in concept to a Fedora Red Hat system, but 
significantly more stable).  We do not have a SuSE Enterprise license, 
and no one seems to have produced something akin to SL but based upon 
SuSE Enterprise. Does anyone on this list have current production SuSE 
Enterprise in use?  Off list replies are fine.

Yasha Karant

On 07/09/2014 05:48 PM, Nico Kadel-Garcia wrote:
> On Wed, Jul 9, 2014 at 8:19 PM, Yasha Karant <[log in to unmask]> wrote:
>> This post is a follow-up to Re: [SCIENTIFIC-LINUX-USERS]
>> glibc-2.15-60.el6.x86_64.rpm [correction].  I had forgotten this trick, but
>> I received an off-list email that explained what to do. This sort of
>> information should be kept in a central SL (or EL or CentOS, etc.)
>> repository -- a practicum of how-to workarounds -- as it used to be for BSD
>> and SunOS a rather long time in the past.  As the correspondent did not use
>> the SL list, I am assuming that she/he wishes not to be the public author of
>> the commentary below (slightly edited).
> This was me. I thought I'd sent it to the list: it's all cool.
>
>
>> Quote.
>>
>> Use rpm2cpio to unbundle the glibc into an alternative location in
>> "/opt". Put shell wrappers in $HOME/bin that set LD_LIBRARY_PATH,
>> MANPATH, etc. to the new location. Install the binary, as well, in ta
>> parallel location in /opt., also accessed by the wrapper. Try using
>> the shell wrappers to summon the binaries with those variables set to
>> point to the new library
>>
>> *DO NOT*  use RPM to install this,  even if you succeed you're likely
>> to seriously break the system. It's like replacing the motor on a car
>> while it's running, replacing a diesel with a Wankel motor.
> Yeah, you can kind of tell it's me from that part....
>
>
>> End quote.
>>
>> Note that after I update a major library, I do not attempt to keep the
>> system running, but reboot, with the pre-updated libraries available in such
>> a form that I can use the shell from a rescue DVD (or USB if one must) to
>> redo the links.  (E.g., if this is libmajor.so.M and it is replaced by
>> libmajor.so.N, N .ne. M, then before any such attempted installation, I do a
>> cp -pr of libmajor.so.M to orig-libmajor.so.M, and if the rescue method must
>> be used, mv libmajor.so.N to new-failed-libmajor.so.N and mv
>> orig-libmajor.so.M to libmajor.so.M.  Note that is a time consuming  set of
>> steps that requires physical access.  Polymorphic virtualisation of file
>> systems nominally could avoid this methodology, but has other problems and
>> risks.)  I do thank the private correspondent for the workaround.
>> Hopefully, the shell wrappers will work (a shell wrapper for each
>> application file that requires the other environment.)
>
> The other dirty trick would be to use something like 'mock' to build a
> chroot cage, and put your tools inside the chroot cage. Then set aside
> the chroot cage for that application, specifically.
>
> Attempts to provide application 'containers' that start to include
> core components like glibc...... start getting very bulky, very fast,
> and lose the performance advantages of a consistent library cache in
> use throughoutt an operating system's  working environment. It's
> *feasible*, and there are reasons to do it to segregate applications.
> But it gets really resource expensive, really fast, and Linux is *not*
> designed around it.