This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch]: Fix multilib/non-multilib build for 4.6 for *-w64-mingw32
2010/5/1 Joseph S. Myers <joseph@codesourcery.com>:
> On Sat, 1 May 2010, Kai Tietz wrote:
>
>> It checks for multilib configuration as logic
>>
>> s-mlib: $(srcdir)/genmultilib Makefile
>> ? ? ? ? if test @enable_multilib@ = yes \
>> ? ? ? ? ? ?|| test -n "$(MULTILIB_OSDIRNAMES)"; then \
>>
>> which means that a target supporting MULTILIB_OSDIRNAME always get
>> multilib configuration, which seems for me wrong.
>
> No, on x86_64-linux the standard[*] directory configuration always uses
> lib64 for 64-bit libraries, independent of whether you have the 32-bit
> library packages installed and so are able to configure with multilibs
> enabled. ?Likewise for mips64-linux the names lib32, lib64, lib for n32,
> n64, o32 do not depend on which multilibs are present or whether multilibs
> are enabled.
>
> [*] Non-Debian/Ubuntu.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>
Well, I see the point, but for win32-targets (cygwin, mingw) it isn't
right. Those targets expecting for non-multilib (and only about this I
am talking here), that /lib is the folder to be choosen. By this logic
here, it alters this behavior for those targets.
But I see that I will have to set the MULTILIB_OSDIRNAMES for
non-multilib builds for those targets explicit to an empty string.
This should fix the issue here.
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination