Support for cc -m32

[Dimitry Andric]

On 2010-08-30 22:09, Tijl Coosemans wrote:
> On Monday 30 August 2010 20:36:36 M. Warner Losh wrote:
>> :>  http://people.freebsd.org/~tijl/cc-m32-1.diff
>> :>  http://people.freebsd.org/~tijl/cc-m32-2.diff
>> :>  http://people.freebsd.org/~tijl/cc-m32-3.diff
>> :>
>> :>  *cc-m32-1.diff* : Let ld and cc find 32 bit libraries.
...
>> I have been trying to get the tbemd patches into the tree and these
>> patches conflict with them.  Can we hold off until I get them in?
>> I've had to rebase things myself a dozen times and each time I've only
>> been able to get part of the patches in...
>>
>> I still have the objections from before, but I'll take a look at the
>> new patches to see if they are addressed or not.
>
> Ok, no problem.

Could we please commit that first diff, at least?  As it is now, -m32
cannot even produce 'hello world', so it will only be an improvement.
It doesn't seem to clash with tbemd changes either.

This will also help with binutils 2.17 and certain ports, such as
valgrind.  Apparently our current ld just warns about arch mismatch, but
produces a .so file anyway (!!):

...
cc -L/usr/lib32 -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -fpic -O -g -fno-omit-frame-pointer -fno-strict-aliasing -Wno-long-long -O2 -pipe -fno-strict-aliasing -Wno-pointer-sign -fno-stack-protector -nodefaultlibs -shared -Wl,-z,interpose,-z,initfirst -L/usr/lib32 -m32  -o vgpreload_core-x86-freebsd.so vgpreload_core_x86_freebsd_so-vg_preloaded.o
/usr/bin/ld: warning: i386:x86-64 architecture of input file `/usr/lib/crti.o' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file `/usr/lib/crtbeginS.o' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file `/usr/lib/crtendS.o' is incompatible with i386 output
/usr/bin/ld: warning: i386:x86-64 architecture of input file `/usr/lib/crtn.o' is incompatible with i386 output

But in later versions of ld this was changed to a (more appropriate)
fatal error. :)

Of course the 2nd and 3rd diffs mess around with headers and such, so
they'll need more scrutiny, but the first one should be no problem,
IMHO.