Q:

GLEW 1.9.0 builds a 64-bit .so even with m32 argument?

I've been trying to compile a 32-bit shared library of GLEW-1.9.0 under a 64-bit RedHat 4 machine, but it seems no matter what I try, the shared library it produces is 64-bit (this is determined using "file libGLEW*" in the output directory).
It seems GLEW has its own system for detecting the architecture. Ultimately, this comes down to "shell uname -m", which I've attempted to change using "setarch i386". The output of "uname -m" after that call is "i686", which isn't i386, but should still be 32-bit.
I've been setting CFLAGS.EXTRA before my 32-bit build to "-m32 -Wl,-rpath,$(APPDIR32)/lib -fPIC", where $(APPDIR32) is the directory I'm outputting to, as well as where I'm linking libraries from. This worked just fine for my 64-bit build (except with the '32's in the string replaced with '64's).
I've been using GLEW's Makefile as follows (after setting the variables mentioned above, among other less relevant ones): "make -f Makefile all"
Setting LDFLAGS to -m32 or melf_i386 has no effect on the format of the output file, which always ends up in ELF_64 (not ELF_32). The libraries being linked are all 32-bit, and that's one of the reasons it complains, as a describe below.
During the build I get repeated warnings like the following...
/usr/bin/ld: warning: i386 architecture of input file `tmp/linux/default/shared/glew.o' is incompatible with i386:x86-64 output

One question: Is i686 a 32-bit architecture? The wikipedia page is unclear on this. I found a point in that page where it says some i686 processors have support for 64-bit instruction sets.
Another question: I haven't been able to find any useful information on building 32-bit shared libraries for GLEW in a 64-bit environment. Can you give me any pointers?
And the ultimate question: Can you see where I'm going wrong, or do you know about an additional action I need to take to get this building a 32-bit shared library?
In response to request for information about the exact command line and its output for the warning mentioned above, it is as follows...
cc -shared -Wl,-soname=libGLEW.so.1.9 -o lib/libGLEW.so.1.9.0 tmp/linux/default/shared/glew.o -L/usr/X11R6/lib -L/usr/lib -lXmu -lXi -lGL -lXext -lX11 
/usr/bin/ld: skipping incompatible /usr/lib/libXmu.so when searching for -lXmu
/usr/bin/ld: skipping incompatible /usr/lib/libXi.so when searching for -lXi
/usr/bin/ld: skipping incompatible /usr/lib/libGL.so when searching for -lGL
/usr/bin/ld: skipping incompatible /usr/lib/libXext.so when searching for -lXext
/usr/bin/ld: skipping incompatible /usr/lib/libX11.so when searching for -lX11
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
/usr/bin/ld: warning: i386 architecture of input file `tmp/linux/default/shared/glew.o' is incompatible with i386:x86-64 output

Here's my makefile, in case you get really excited and want more material. This makefile will work just fine if you put it in the same directory as GLEW-1.9.0's Makefile (that is until you try configure32). Just make sure to set TOPDIR. Use 'make -f  clean', 'make -f  configure32', 'make -f  all', 'make -f  install'.
APPLICATION = glew
VERSION = 1.9.0
FULLAPPLICATION = $(APPLICATION)-$(VERSION)

TOPDIR = /home/<username>/dev/project/third-party

APPDIRROOT  = $(TOPDIR)/apps-miles

ARCH=$(shell uname | sed -e 's/-//g')
SHELL = /bin/csh

MACHTYPE32= i386
APPDIR32                = $(APPDIRROOT)/$(ARCH)_$(MACHTYPE32)

MACHTYPE64= x86_64
APPDIR64                = $(APPDIRROOT)/$(ARCH)_$(MACHTYPE64)

#
#   Linux
#

ifeq ($(ARCH), Linux)
CC = gcc 
CXX = g++
CFLAGS.EXTRA32 += -m32 -Wl,-rpath,$(APPDIR32)/lib -fPIC
CFLAGS.EXTRA64 += -m64 -Wl,-rpath,$(APPDIR64)/lib -fPIC
PATH = /sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin
endif

#
# Darwin
#

ifeq ($(ARCH), Darwin)
CC = gcc 
CXX = g++
CFLAGS.EXTRA32 += -m32 -mmacosx-version-min=10.5 -fPIC
CFLAGS.EXTRA64 += -m64 -mmacosx-version-min=10.5 -fPIC
PATH = /usr/bin:/bin:/usr/sbin:/sbin
endif

V_M_EXIST = $(shell test -e CONFIG.mk && echo 1)
ifeq ($(V_M_EXIST), 1)
include CONFIG.mk
endif

ECHO = echo

all::
    make -f Makefile all

configure32::
    @-/bin/rm CONFIG.mk; touch CONFIG.mk
    @echo "GLEW_DEST = $(APPDIR32)" >> CONFIG.mk
    @echo "export GLEW_DEST" >> CONFIG.mk
    @echo "LIBDIR = $(APPDIR32)/lib" >> CONFIG.mk
    @echo "export LIBDIR" >> CONFIG.mk
    @echo "CFLAGS.EXTRA = $(CFLAGS.EXTRA32)" >> CONFIG.mk
    @echo "export CFLAGS.EXTRA" >> CONFIG.mk

configure64::
    @-/bin/rm VAPOR.mk; touch CONFIG.mk
    @echo "GLEW_DEST = $(APPDIR64)" >> CONFIG.mk
    @echo "export GLEW_DEST" >> CONFIG.mk
    @echo "LIBDIR = $(APPDIR64)/lib" >> CONFIG.mk
    @echo "export LIBDIR" >> CONFIG.mk
    @echo "CFLAGS.EXTRA = $(CFLAGS.EXTRA64)" >> CONFIG.mk
    @echo "export CFLAGS.EXTRA" >> CONFIG.mk

install::
    make -f Makefile install

clean::
    make -f Makefile clean

frog:: 
    @$(ECHO) APPDIR = $(APPDIR32)

A:

EDIT: updated to reflect seemingly working workaround  
First approach
As linking 32-bit code with 64-bit libs will not work on first sight the only problem seemed to be the following snippet of config/Makefile.linux starting on line 5: 
M_ARCH ?= $(shell uname -m)
ifeq (x86_64,${M_ARCH})
LDFLAGS.EXTRA = -L/usr/X11R6/lib64 -L/usr/lib64
LIBDIR = $(GLEW_DEST)/lib64
else
LDFLAGS.EXTRA = -L/usr/X11R6/lib -L/usr/lib
LIBDIR = $(GLEW_DEST)/lib
endif

hardcoding the library search path to 64-bit libraries. 
Second sight
As a first attempt trying something like:
make  LDFLAGS=-m32 M_ARCH=anything_but_not_x86_64

still failed it turned out that in addition disregarding common conventions LDFLAGS will not be passed to the linker in the Makefile going with rules like the one on line 108:
lib/$(LIB.SHARED): $(LIB.SOBJS)
    $(LD) $(LDFLAGS.SO) -o $@ $^ $(LIB.LDFLAGS) $(LIB.LIBS)

With LDFLAGS.whatever hardcoded to required switches.
Suggested workaround
While any of the workarounds like:

make LDFLAGS.SO="-L/usr/lib -L/usr/X11R6/lib -m32"

should work the most easy one to type seems to be the following one:

make LD="gcc -m32"

smuggling the -m32 switch into the LD macro.

