1. Can we move the gcc file?
2. What happen if some of the products/RPMs running on the system require the original gcc?
3. Whether we can have a multiple gcc?

As I want to install the OHS 32-bit in 64 bit CEDRT machine, I need to do below work around suggested by Oracle.

2.1.1.2 Linux Operating Systems

A 32-bit Linux version of Oracle Web Tier may be installed on a 64-bit Linux platform by doing the following:

1. Run the following command before starting the installer:

2.
3. linux32 bash
4. During the installation, you will receive an error during the linking phase. To work around this error:

a. Login as root user.

b. Move the existing /usr/bin/gcc file to /usr/bin/gcc.orig with the mv command:

c. mv /usr/bin/gcc /usr/bin/gcc.orig
d. Using a text editor such as vi, create a new file called gcc41 that contains the following content:

e.
f. #!/bin/sh
g. exec /usr/bin/gcc.orig -m32 -static-libgcc
h. -B/usr/lib/gcc/i586-suse-linux/2.95.3/ $*
Note:
The file i586-suse-linux/2.95.3 may differ slightly depending on the exact version of your Linux operating system. Verify the exact version of your Linux operating system in use; search for the 32bit directory in /usr/lib/gcc and obtain the exact file name.
i. Change the file permission for the gcc41 file using the following command:

j. chmod 755 /usr/bin/gcc41
k. Create a symbolic link to /usr/bin/gcc with the following command

GCC is a compiler and you won't really notice it missing or broken until you or an installer script call it. Typically GCC is used to install programs from source code. It looks like the instructions you have give some directions to move the original GCC binary to a backup file called gcc.orig. If your concerned about taking these steps it would be a good idea to do a full backup of your system first. It would be an even better idea to test these steps on another non-production machine to see if this will break anything. The instructions are reversible as well, so you should be able to restore the original version of GCC by reversing the process , restoring the original gcc binary and linking it to the correct locations. It looks like your trying to compile and run a 32bit binary on a 64bit system, is that correct?

1 members found this post helpful.

I would have thought there was some less drastic way to get a specific install to do a 32-bit build. But I don't know the details.

I don't know what OHS is, so maybe I'm misunderstanding, but I think you only need to modify gcc temporarily, during the install of OHS. After OHS is installed, I think you can put gcc back to normal and still use OHS.

I think the lines you labeled as g. and h. in the instructions were originally one line and will not work as two lines, but now look like they are two lines (as a result of something someone did wrong when copying them).

Most of what you asked is answered by the beginning of tekhead2's reply, so I won't duplicate that.

2 members found this post helpful.

as above G and H ?????
that is ONE line not two

should be a text file called "gcc41" ( and that suse 2.95 is NOT 4.1 )
with this in it
BUT that is a VERY VERY odd line for Oracle Linux ???

Oracle is RED HAT and NOT Novell

so what EXACT operating system are you using ?
if one of the oracle rebuilds of red hat
Then WHY are you fallowing Novell SUSE linux instructions

the two OS's are NOT compatible


but that is a VERY odd way to set the SUSE gcc 2.95 to gcc 4.1
i would also have to question using the antique gcc 2.95 ????
you might want to talk to the Oracle tech support people

1 members found this post helpful.

As an example of how you can run 32-bit application software on a 64-bit operating system is Slackware. Slackware is released in two "pure" forms, 64-bit and 32-bit. If you've installed 64-bit Slackware, 32-bit won't run; however, you can install a set of packages that add 32-bit libraries to Slackware 64-bit so that 32-bit software can execute.

Solaris has been 64-bit for years and years but it comes with 32-bit libraries already installed and will detect a 32-bit binary and link the 32-bit libraries needed. Slackware does essentially the same thing in slightly different ways.

What Slackware does is the 64-bit libraries are in directories such as /usr/lib64 and /lib64. With the installation of 32-bit, the necessary 32-bit are installed in /lib and /usr/lib (where they're found on a 32-bit system).

One of the Slackware developers, Eric Hameleers, who goes by the alias AlienBOB, developed and supports what he has called multilib, explained at http://www.slackware.com/~alien/multilib/. Multilib allows you to run and compile 32-bit software on a Slackware 64-bit system.

Essentially, you cannot run 32-bit on a 64-bit system without doing something similar to multilib (if that capability was not installed by the distribution in the first place); i.e., you must have 32-bit libraries available for a 32-bit binary to execute.

You do not want to remove GCC -- if you do, you'll never be able to build a kernel or any other software from source (or install, say, VirtualBox which has to build kernel modules on the platform).

As an alternative you might want to install VirtualBox and install the 32-bit version of the operating system you need to run your 32-bit application as a guest operating system (that will work just fine, you can install and use a 32-bit operating system on 64-bit hardware). That may be your best bet -- but don't go removing software where you might wind up with a boat anchor or expensive door stop.

Hope this helps some.

1 members found this post helpful.

Multilib: also available in RHEL http://au.redhat.com/magazine/009jul...ures/multilib/

Multilib lets you easily run 32-bit applications in 64-bit RHEL. It lets you install from source as 32-bit, but not as easily. Running the default make sequence to install from source may give you a 64-bit build.

Still missing some details on what/why the OP needed to do, but it requires at least adding certain options every time gcc is invoked by the make procedure and likely also requires using a different version of gcc.

The design of gcc makes it easy to have multiple versions installed at once. But only one is the default version and others must be selected on each use.

Many make procedures use an environment variable (such as $CC) to let you override the choice of gcc version to any other version you have installed and/or add options to the command.

Editing the make procedure is sometimes a decent approach when you need to force such changes but no provision exists for that in the make procedure.

The first post implies someone decided those methods wouldn't work and suggested an alternate method for forcing gcc version and options during the make procedure.

and using the 2.95 compiler set AS the 4.1