Re: Proprietry Software - The Pain!
On Tue, 5 Feb 2002, Paul Sargent wrote:
> This might not be classed as a debian problem per-se, but I'm
> wondering if anybody here has any suggestions to get me out of this
> hole, a hole which is probably more political than technical. Maybe
> somebody else has been in a similar situation.
It looks to me like a library incompatibility issue. Differences in the
way the libc handles malloc can cause weird problems for programs that
have memory allocation bugs. Since glibc changes the behavior of malloc
on a quite regular basis, and redhat likes to patch their stuff anyway,
it's quite possible that the bug-tolerance is different between the two.
The simplest thing IMO is to just keep them on separate boxes :}
A worse problem is a kernel difference. Although I think this is unlikely
due to the nature of the error. The possible good news here is that it's
likely that you can find a kernel that will run both applications,
although it might not be supported by one of the developers. Look into
the possibility that the kernel you are using suffers from one of the
miscellaneous Athlon bugs (or rather, Athlon motherboard bugs). I doubt
this is the problem, but it wouldn't hurt to check.
Installing a hard drive containing their supported system and booting that
would allow you to rule out a hardware problem.
Another option is to just put the entire RedHat system into a directory
tree on your Debian system, use chroot to access it, and see if that
works. If it does, it rules out a kernel problem and it rules out any
problems with running system services. On the other hand, it will create
new problems pertaining to the Jekyll-and-Hyde nature of a system that has
two /etc/passwd files, etc. etc.
You might consider having Vendor B send you a completely statically linked
binary that doesn't use dynamically linked anything, including (or rather
especially) libc. This is marginally less efficient in terms of memory
use, but if it runs on your system, you know the problem is a library
incompatibility. (the memory wastage is pretty small; unless you run a
lot of simultaneous copies of the application, you probably don't have to
worry about it - unless it's a really big X application, and maybe not
even then given the size of your system).
Or, you might copy the libraries off of the supported system into
/usr/local/lib/redhat, or some such. Use LD_LIBRARY_PATH to cause
Application B to use this set of libraries, instead of the regular ones.
It's not necessarily just libc that could be at fault. Any system library
might be responsible - the X libraries tend to be a nuisance as well.
> and the other hide it? My guess is that it's to do with the memory
> setup (see below) changing the address space that the app is living
> in, but that's just a guess.
There should be no problems resulting from address space. The app should
see the address space the same regardless of the situation with the
physical memory (if my understanding of the large-memory patches is
correct).
> Has anybody else ever found themselves in a similar situation? Any
> suggestions for how to get out?
It is a continous and ongoing nuisance in HP/UX :}
Reply to: