Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Jul 2010 14:11:15 +0200
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        Tijl Coosemans <tijl@coosemans.org>
Cc:        pluknet <pluknet@gmail.com>, freebsd-arch@freebsd.org
Subject:   Re: Support for cc -m32
Message-ID:  <4C52C163.9010601@freebsd.org>
In-Reply-To: <201007301053.27407.tijl@coosemans.org>
References:  <201007291718.12687.tijl@coosemans.org>	<4C520044.5020002@freebsd.org> <201007301053.27407.tijl@coosemans.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 07/30/10 10:53, Tijl Coosemans wrote:
> On Friday 30 July 2010 00:27:16 Nathan Whitehorn wrote:
>    
>> On 07/29/10 17:18, Tijl Coosemans wrote:
>>      
>>> I've put the initial version of some patches online to support cross
>>> compilation of 32 bit binaries on amd64. It's modelled after how NetBSD
>>> does this.
>>>
>>> With these patches something like "cc -m32 -o test test.c -pthread -lm"
>>> generates a program that runs on FreeBSD/i386.
>>>
>>> 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.
>>>        
>> Why not use the GCC multilib code for what patch 1 does? There is
>> already code in cc_tools/Makefile to handle this for powerpc64 (where
>> cc -m32 already works).
>>      
> Thanks, it's indeed better to specify this per architecture so I've
> updated the patch. It changes the output of -print-search-dirs though.
>    
> With the previous patch "cc -m32 -print-search-dirs" printed:
>
>    install: /usr/libexec/
>    programs: =/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/
>    libraries: =/usr/lib32/:/usr/lib32/
>
> And now it prints:
>
>    install: /usr/libexec/
>    programs: =/usr/bin/:/usr/bin/:/usr/libexec/:/usr/libexec/:/usr/libexec/
>    libraries: =/usr/lib/32/:/usr/lib/../lib32/:/usr/lib/:/usr/lib/
>
> That works, but it's not entirely correct.
>    
That's just an artifact of the way multilib works, I'm afraid. Is there 
a reason it could be harmful?
-Nathan




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C52C163.9010601>