I wasn't making an assertion about this point in time, but rather the general expectation.
At any given instant there may or may not be skew among the major distributions. When the sizes of system data types, alignments and a variety of other things change, they don't synchronize across all distros at once. During such periods of time, the portability of executables and even libraries is impaired. Some Linux distros are deliberately conservative about changes while others change w/o regard to the consequences. I don't like Linux because of the prevalence of the latter. Well written application libraries are generally portable at object level. Executables are generally not. Choice of compiler flags can result in both executables and libraries that only run in certain places. At present 32 vs 64 bit is a compatibility issue. A 64 bit executable will not run on a 32 bit OS instance. Changing the offset in an fseek(3c) call from 32 to 64 bits was a big deal. So was making filenames longer than 14 characters and going from 16 to 32 bit words. The odd thing is people keep getting blindsided by things that have happened before. Because they didn't know or ignored history and got to repeat it. FWIW I have systems w/ drive caddies that let me swap disk drives and a home made rack w/ 20+ drive caddies w/ various OS versions installed. These exist entirely to allow me to test software across multiple OSes. I currently have Solaris, OpenIndiana, several flavors of Linux, FreeBSD and Plan 9 available and spare drives if I want to do something new. I've found this very satisfactory. It takes very little effort to do a default OS install onto a bare disk. If it doesn't work, I just don't test that OS. It's a great use for disks which would otherwise be too small to have any use. All the systems that the disks plug into are obsolete, but good enough for software testing. I routinely test across Linux, Solaris and OpenIndiana using this setup and would include FreeBSD and others if I were serious about something. At present, it's limited to cases where someone has a problem in a particular environment and asks well considered questions. I'll load what they're using on a disk and sort it out. Have Fun! Reg BTW I don't like top posting, but yahoo forces me if I reply to rich text. If anyone knows how to fix that please let me know. --- On Wed, 4/10/13, Andrew Makhorin <[email protected]> wrote: From: Andrew Makhorin <[email protected]> Subject: Re: [Help-glpk] Linux GLPK library To: "Reginald Beardsley" <[email protected]> Cc: "glpk" <[email protected]> Date: Wednesday, April 10, 2013, 6:15 PM > Unfortunately, the general case is that it will not work. > > The reason is that there is skew among the various Linux distros > particularly relative to libc with the result that executables tend to > dump core if run on a different distro. This is the reason that > commercial software running on Linux has very specific system > requirements. > > Since I don't have an access to different Linux distributions, I tried to check a statically linked glpsol executable (built under Debian) with http://ispras.linuxbase.org/index.php/About_Linux_Application_Checker , and that checker didn't find incompatibilities at least for main Linux distributions. So your comment puzzles me.
_______________________________________________ Help-glpk mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-glpk
