Hi all!

I'm trying to compile apache2 to 32bit instead of 64bit using configure command with parameter but I receive this error output:

...
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
...

In the config.log I cant' find any helpful information about the compiler's error.

This is the output of command:
Linux SDC09 2.6.9-11.ELsmp #1 SMP Fri May 20 18:25:30 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux

My machine runs Red Hat Enterprise Linux AS release 4 (Nahant Update 1)

Also I run configure:
If I use CFLAGS="-m64" instead of CFLAGS="-m32" the configure doesn't generate errors.

Anyone can help me?

The config.log will have a test program that failed, that's how it figured out that the C compiler can't create executables. Take a closer look at the config.log and post the appropriate section if your don't understand what you find.

I am having the same issue... I am trying to compile a 32-bit version of Apache 1.3.41 on a 64-bit OS (Ubuntu Server 8.04.1), and it is failing. Specifically:

# ./configure --prefix=/apache --enable-module=so CFLAGS=-m32
Configuring for Apache, Version 1.3.41
+ using installation path layout: Apache (config.layout)
configure:Error: invalid option 'CFLAGS=-m32'


There does not appear to be a config.log created, as this error happens immediately. I have also tried a few variations on that CFLAG line, such as -m32-bit.

Am I doing something completely retarded?

Ok, I have, maybe, gotten a little bit further. Basically I gave up trying to set it as a commandline configure flag, an instead just set CFLAGS=-m32 as an environment variable..

Now, when I ran the configure line, I got:

# ./configure --prefix=/apache --enable-module=so
Configuring for Apache, Version 1.3.41
+ using installation path layout: Apache (config.layout)
Creating Makefile
Creating Configuration.apaci in src
Creating Makefile in src
+ configured for Linux platform
+ setting C compiler to gcc
+ setting C pre-processor to gcc -E
+ using "tr [a-z] [A-Z]" to uppercase
+ checking for system header files
+ adding selected modules
+ using builtin Expat
+ checking sizeof various data types
+ doing sanity check on compiler and options
** A test compilation with your Makefile configuration
** failed. The below error output from the compilation
** test will give you an idea what is failing. Note that
** Apache requires an ANSI C Compiler, such as gcc.

======== Error Output for sanity check ========
cd ..; gcc -DLINUX=22 -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite -m32 `./apaci` -o helpers/dummy helpers/dummy.c -lm
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.4/../../../libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/bin/ld: cannot find -lm
collect2: ld returned 1 exit status
make: *** [dummy] Error 1
============= End of Error Report =============

Aborting!

So... My next step was to install the ia32-libs package, create a symbolic link so that it would find the 32-bit version of libm.so before the 64 bit version... That seems to have resolved that specific error, however now I get:
======== Error Output for sanity check ========
cd ..; gcc -DLINUX=22 -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite -m32 `./apaci` -L /home/lukeb -o helpers/dummy helpers/dummy.c -lm
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.4/libgcc.a when searching for -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.2.4/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
collect2: ld returned 1 exit status
make: *** [dummy] Error 1
============= End of Error Report =============

Aborting!

---

Basically, at this point I think I should just compile it on a 32-bit system and then install it on the 64-bit one. Does anyone forsee any problems deriving from such an approach?

What are you trying to accomplish running a 32 bit app on a 64 bit server?

And no, it probably won't work to compile it somewhere and use it somewhere else. The executable is the last piece of the puzzle, you have to get all the library files in the right places, and it means a lot of work for presumably no benefit, but that depends on your answer to my initial question.

Peace,
JimBass

Yeah, I found that out last night... Apache compiled elsewhere seemed to install and run OK, however when it came to adding PHP and MYSQL? Couldn't even do a make install successfully.

Essentially, we have a legacy proprietary module that requires 32-bit Apache 1.3 and PHP 4. I am running Ubuntu Server 8.04.1, 64-bit.

This sounds like a gigantic headache any way we cut it, though.

In that case, there's 2 easy/not so easy options that jump out. The first is probably the "truly best", but also costly and time consuming, and thats to contact the software authors and ask them to port it to 64 bit. That of course assumes that they are a company and not somebody who used to work at your office. Even if you get the port done successfully, you probably won't see any better behavior out of it.

The cheaper and probably much easier way to do things would be to install a virtual server inside your 64 bit server. VMware and Virtualbox are the names I see most often for virtualization, but they are far from the only ones. The same way so called "IT" people are happy they can run apache on a RHEL box inside of Windows server 2003, you could run a virtual 32bit Ubuntu inside your 64bit Ubuntu. It truly is 32 bit, so there's no compatibility issues. Apache 1 can be installed on the virtual machine, and with the addition of the kernel headers, make, and tools like that, you should have it working.

Peace,
JimBass

Yeah, I was afraid it was going to be something like that. It is, indeed, a module that was written by people who are long-departed from the company, and we do not even have the code anylonger, only the module itself. Such is life.

As for running it within a virtual machine (we usually use xen), the problem then becomes the allocation of system resources. The host OS is installed onto a 3TB RAID 5 array, and it is being built as a replacement for an older server that is desperately short of space. So, any virtual machine would need access to that huge disk space. I could do it through an NFS export mounted by the guest machine, but that seems like an extremely lumpy solution.

I think at this point I am going to pong it back at the developers/webd00dz and tell them to try to figure out some alternative.

Thanks for all your help, it is very much appreciated.