Note that we have always considered RHEL and CentOS to be the same, as far as binary compatibility is concerned, and I've been building stuff on CentOS and using it on RHEL for a few years (just versions 5 and 6, though), with zero issue.
On Fri, Nov 16, 2012 at 9:56 AM, David A. Desrosiers <[email protected]> wrote: > On Fri, Nov 16, 2012 at 9:38 AM, Steven Jenkins <[email protected]> > wrote: >> >> I agree with you that gratuitous changes to this are risky, but I do >> not have access to 32-bit systems, so I don't see a lot of choice on >> this (and various users have vendor-provided libraries that are >> 32-bit, so I have to support linking those). Note that I'm building >> with multilib support, so if I did produce 32-bit binaries (e.g., >> provide an x86-32.rhel.5, for example), then that would be >> cross-compiled anyway, not native. > > > In this specific case, I have a 32-bit ISO image, but no machine to build it > on, unless I was to bake it on my own VMware Workstation/Fusion-driven VM, > and use that. It wouldn't be joined to AD, wouldn't be visible from the > internal VPN or network, because it would be running on a machine not > attached to the network, so that may be a dead-end. I'll ping you the > location internally under separate cover, so you can play with it if you > want. > > The other solution is to build it on an equivalent CentOS 32-bit image, > which is RPM-for-RPM compatible with what RHEL provides, then copy the > binaries internally, and use -those- binaries to produce a compiled version > after that. > > I realize it's not the best solution, but may get you past this > cross-compile hurdle. > > _______________________________________________ > EFS-dev mailing list > [email protected] > http://mailman.openefs.org/mailman/listinfo/efs-dev > _______________________________________________ EFS-dev mailing list [email protected] http://mailman.openefs.org/mailman/listinfo/efs-dev
