for what is worth I have some _expensive_ EDA tools from Incisive which bundle 64bit binaries in the supposedly 32bit toolchain as well as an IBM tool which requires a 32bit OS lib in its _64_bit toolchain....
On 24 January 2014 16:00, Todd Rinaldo <toddr@cpanel.net> wrote:
Could I ask what the use case is for i386 support? I know that the pointers are smaller but memory is cheap. Is this a speed or a hardware or a can it be done goal?
On Jan 24, 2014, at 4:29 PM, Karanbir Singh <mail-lists@karan.org> wrote:
> On 01/24/2014 10:26 PM, Manuel Wolfshant wrote:
>> On 01/25/2014 12:13 AM, Karanbir Singh wrote:
>>> Hi
>>>
>>> Whats the plan for EPEL i686 / EL7 ? Does anyone know if there is even
>>> going to be a multilib attempt or is everything going to stay x86_64 clean ?
>> they build for x86_64 and ppc64 only,
>
> So then the question is - what is the process to enable i686 there ( or,
> do we then need to own all of EPEL - atleast some subset ) locally if we
> are going to attempt a i686 CentOS build ?
>
> - KB
There are several items I see i686 support being needed:
1) Memory is not cheap in cloud and hosted environments. Especially in cloud where you might be firing up a thousand hosts at a time.2) Multiple Virtual Machines don't do well in the transition from 32 bit to 64 bit in that their memory usage doesn't go up by *2 but can be ^2 depending on the workload. Python is a perfect example of this but there are cases in java and other 'virtual machine' environments where it happens.3) As nice as having i686 compat libraries are for some commercial apps you end up needing a lot more than what is provided by the OS. This really comes up when you have to run a mixed set of commercial binaries that need something that only EL7 provides but also needs stuff that EL6 had. Thus you end up needing i686 everything.