[lug] 32bit and 64bit

Davide Del Vento davide.del.vento at gmail.com
Tue Jan 24 09:04:12 MST 2012

There is no problem to have a mixed 32-64bit environment. There might be
management headaches because you have to properly track each library (32 or
64) required by each application (32 or 64) since you cannot mix-and-match
32bit applications with 64bit libraries or vice-versa. The distribution
might do the management for you (haven't used RHEL or CentOS, so I can't
say), in which case it will be super-straightforward - I did it years ago
on a Mandrake or Mandrivia, IIRC, and it was a piece of cake.

On Tue, Jan 24, 2012 at 07:48, Mitheesh CS <mitheesh at gmail.com> wrote:

> Server Configuration
> Red Hat Enterprise Linux (RHEL) 5 Server for x86 (64-bit)
> Domino v8.5.3, 32-bit
> Requirement from the Application Team/Customer
> Make available a C compiler on a server to allow recompiling C program
> tools used by the Domino team. Need to be able to compile 32-bit programs.
>    I am very much looking explanation for the below queries ?
> 1. Is it advisable to install gcc 32 bit & 64 bit on the same server which
> is running on RHEL 5.3 64 bit (if we install both in the same server will
> this create any stability issues like crash etc)?
> 2. As per the general OS expectations,we can install only 64 bit GCC
> compiler in this server ? Am I correct ?
> 3. I understand that 64 bit compiler only can be installed in this
> server.However 32 bit domino is running on this server and if the
> application wants to do compilation as part of their support schedule,is
> there any alternative way to compilation ?
> Regards
> Mitheesh
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20120124/d75a2a45/attachment.html>

More information about the LUG mailing list