multilib-list

[Cody P Schafer]

On 02/26/2014 04:37 PM, Ray Donnelly wrote:
> Hey Trevor, Brian, all on list,
>
> On Wed, Feb 26, 2014 at 11:39 PM, Trevor Woerner
> <trevor.woerner@linaro.org> wrote:
>> Hello Ray, Brian, and everyone else,
>>
>> On 02/26/14 15:05, Ray Donnelly wrote:
>>> AFAIK, Bryan Hundven was going to exclude --with-multilib-list for arm
>>> if gcc < 4.9, and exclude it altogether for all arches other than Intel,
>>> arm and sh.
>>
>> It seems like a lot of initial (and on-going) work (multilib_add_archs)
>> to keep track of which architectures and which versions have multilib
>> support. I guess it would help users from accidentally creating invalid
>> configurations, but on the other hand I can't help think it would be
>> easier and more flexible to have the option always available (when
>> multilib is selected) and include a strongly worded help message instead :-)
>>
>
> multilib_add_archs isn't about hand-holding or sanitising the multilib variants
> based on the arch (though there are other patches in the queue that do some
> of that), instead, that bit is about determining the correct triplet to use
> to configure {e}glibc given the C flags for that multilib variant and the
> 'major' target triplet.The stub implementations are just NYI.
>
> To give a concrete example, on my multilib Arch system:
> $ gcc --print-multi-lib
> .;
> 32;@m32
> .. so we know there's 2 variants, one with extra_flags of "" and one with
> extra_flags of "-m32". We need to build {e}glibc twice then, once for
> i686-unknown-linux-gnu and once for x86_64-unknown-linux-gnu.
> This is done from glibc-eglibc.sh-common:
> target=$(CT_DoArchMultilibTarget "${extra_flags}" ${CT_TARGET})
>
> The other important thing this patch queue adds is to ask gcc where
> these {e}glibcs should be installed using -print-multi-os-directory:
> lib_dir=/usr/lib/$("${cross_cc}" -print-multi-os-directory ${extra_cc_args})
> (where extra_cc_args is extra_flags plus potentially some user requested
> flags). This allows removing all of the symlinks from lib to lib32/lib64 that
> were being made previously ( dont-make-lots-of-lib-symlinks-if-mutlilib )
> and also removing the ugly block "Fixing up multilib location"
> ( use-multi-os-directory )

AFAIK newlib (which I expect Trevor is using for embedded arm targets) 
doesn't need any target mangling for multilib to work correctly. Which 
means for newlib targets multilib should work almost as-is.

--
For unsubscribe information see http://sourceware.org/lists.html#faq