Re: multilib-list

[Ray Donnelly <mingw dot android at gmail dot com>]

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 )

> In my case I'd like to use it to build multilib toolchains using the
> "custom" version. Could that scenario be added too? It looks like that
> won't be easy. I think it would be safe to assume if a user is
> performing a build using custom versions that they're knowledgeable
> enough to know if they want multilib. It reminds me of the patches you
> have to add snapshots and additional versions.
>

I'm not sure what you mean about "custom" version. At core, these patches
are about asking the previous-stage gcc for the exact flags and folders
that it expects for each multilib it has been compiled for and trying to
make sure we build a libc for in the right place for each.

> I still think it would just be best to provide the list option if the
> user selects multilib since there's a decent chance they might know what
> they're doing and a missing multilib list isn't a problem.

I'm ambivalent about whether to allow options that will either fail or not give
the intended results at the end. I don't have enough experience of
crosstool-ng to say what the "crosstool-ng way" is with these sorts of things.
I will always specify that I want every multilib going, but
I'm greedy like that.

>
> It looks like your focus is on 32-bit versus 64-bit tools and libraries.
> All I'm looking for is to specify multiple architectures (e.g. armv6-m
> armv7e-m). I'm not sure the work you're doing will accommodate my
> use-case too. But I'll do some investigation and testing and let you
> know how it goes.

Our focus is I think fixing multilibs with as little qualification on that as
possible. I guess Arm hasn't been as considered as that needs gcc 4.9
so it's not quite on my radar yet. I know from past dealings with Android
toolchains that they support quite a few multilib variants out of the box:

/arm-linux-androideabi-gcc -print-multi-lib
.;
armv7-a;@march=armv7-a
thumb;@mthumb
armv7-a/thumb;@march=armv7-a@mthumb

.. and I don't see anything in the configure line that asks for this explicitly.
It may be down to some android specific file (t-android?), I'm not sure. But
given the above list of multilibs, our current patch would make libc 4 times
into 4 different lib-dirs, which looks correct to me.

When discussing multilibs, sometimes you can end up in multi-arch-land
which is a Debian thing that IMHO muddies the already muddy enough
waters ..

>
>
>> Any chance you could point me to some information on how to use a second
>> remote patch queue with mercurial? I would like to work with these
>> patches, but I'm rather new to mercurial, never mind its queue add-on.
>>
>>
>> I'm also quite new to mercurial, so someone may need to correct me.
>> Tutorial:
>> http://mercurial.selenic.com/wiki/MqTutorial
>
> Thank you so much for that list! The "qclone" and "qpush -a" commands
> were especially helpful!
>
> Best regards,
>     Trevor

Cheers,

Ray.

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