multilib-list

multilib-list

[Trevor Woerner]

Hi everyone,

The help text for crosstool-NG's MULTILIB configuration option states:

"The list of variants is dependent on the architecture, and is
hard-coded in gcc, so it is not possible to say what variants to
support, only whether hard-coded variants should be supported or not."

Isn't this the purpose of gcc's --with-multilib-list option? Doesn't
this allow the user to select which multilib variants to build?

Best regards,
    Trevor

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

Re: multilib-list

[Ray Donnelly]

Hi Trevor,

 AFAIK --with-multilib-list is only supported on intel and sh and in
GCC 4.9 it's also supported for arm.

If you're interested in multilib support, a few of us have been
contributing to the following patch queue:

https://bitbucket.org/bhundven/crosstool-ng-multilib

On Wed, Feb 26, 2014 at 5:19 PM, Trevor Woerner
<trevor.woerner@linaro.org> wrote:
> Hi everyone,
>
> The help text for crosstool-NG's MULTILIB configuration option states:
>
> "The list of variants is dependent on the architecture, and is
> hard-coded in gcc, so it is not possible to say what variants to
> support, only whether hard-coded variants should be supported or not."
>
> Isn't this the purpose of gcc's --with-multilib-list option? Doesn't
> this allow the user to select which multilib variants to build?
>
> Best regards,
>     Trevor
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>

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

Re: multilib-list

[Trevor Woerner]

Hello Ray,

On 02/26/14 13:33, Ray Donnelly wrote:
>  AFAIK --with-multilib-list is only supported on intel and sh and in
> GCC 4.9 it's also supported for arm.

Specifically I have been working with the gcc-arm-embedded code from
https://launchpad.net/gcc-arm-embedded (and I've noticed some of the
contributors to that project are also subscribed to this list). I assume
it is this work which will eventually be the gcc-4.9 you mention?

> If you're interested in multilib support, a few of us have been
> contributing to the following patch queue:
>
> https://bitbucket.org/bhundven/crosstool-ng-multilib

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.

Why not just have a patch that allows the user to specify the list
themselves?

diff -r 043b9b789b7d config/target.in
--- a/config/target.in  Wed Feb 26 13:53:25 2014 -0500
+++ b/config/target.in  Wed Feb 26 14:45:22 2014 -0500
@@ -77,6 +77,15 @@
       NOTE: The multilib feature in crosstool-NG is not well-tested.
             Use at your own risk, and report success and/or failure.
 
+config MULTILIB_LIST
+    string
+    prompt "Additional multilib architectures to support"
+    depends on MULTILIB
+    default ""
+    help
+      Provide GCC with a comma-separated list of additional
architectures for
+      which to build multilib support.
+
 #--------------------------------------
 config ARCH_SUPPORTS_BOTH_MMU
     bool
diff -r 043b9b789b7d scripts/build/cc/gcc.sh
--- a/scripts/build/cc/gcc.sh   Wed Feb 26 13:53:25 2014 -0500
+++ b/scripts/build/cc/gcc.sh   Wed Feb 26 14:45:22 2014 -0500
@@ -377,6 +377,9 @@
 
     if [ "${CT_MULTILIB}" = "y" ]; then
         extra_config+=("--enable-multilib")
+        if [ -n "${CT_MULTILIB_LIST}" ]; then
+            extra_config+=("--with-multilib-list=${CT_MULTILIB_LIST}")
+        fi
     else
         extra_config+=("--disable-multilib")
     fi


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

Re: multilib-list

[Ray Donnelly]

On Wed, Feb 26, 2014 at 7:52 PM, Trevor Woerner
<trevor.woerner@linaro.org> wrote:
> Hello Ray,
>
> On 02/26/14 13:33, Ray Donnelly wrote:
>>  AFAIK --with-multilib-list is only supported on intel and sh and in
>> GCC 4.9 it's also supported for arm.
>
> Specifically I have been working with the gcc-arm-embedded code from
> https://launchpad.net/gcc-arm-embedded (and I've noticed some of the
> contributors to that project are also subscribed to this list). I assume
> it is this work which will eventually be the gcc-4.9 you mention?

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.

crosstool-ng had limited broken multilib support and this series attempts to
fix that.

>
>> If you're interested in multilib support, a few of us have been
>> contributing to the following patch queue:
>>
>> https://bitbucket.org/bhundven/crosstool-ng-multilib
>
> 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

Some useful commands to get started (I grabbed these from my bash history).
To clone:
hg qclone -p https://bitbucket.org/bhundven/crosstool-ng-multilib
http://crosstool-ng.org/hg/crosstool-ng crosstool-ng-multilib
To list the patches in-order:
hg qseries
To see where you are in the list:
hg qapplied (I think hg log will also do this, I do hg log | less as
otherwise it's a bit spew happy)
To push (apply) all patches:
hg qpush -a
To pop (un-apply) all patches:
hg qpush -a
(you can use a name from the series instead of -a to push / pop to that point)
To change the patch you're currently at with your working tree
hg qrefresh
To change the message of the patch
hg qrefresh -e

> Why not just have a patch that allows the user to specify the list
> themselves?
>
> diff -r 043b9b789b7d config/target.in
> --- a/config/target.in  Wed Feb 26 13:53:25 2014 -0500
> +++ b/config/target.in  Wed Feb 26 14:45:22 2014 -0500
> @@ -77,6 +77,15 @@
>        NOTE: The multilib feature in crosstool-NG is not well-tested.
>              Use at your own risk, and report success and/or failure.
>
> +config MULTILIB_LIST
> +    string
> +    prompt "Additional multilib architectures to support"
> +    depends on MULTILIB
> +    default ""
> +    help
> +      Provide GCC with a comma-separated list of additional
> architectures for
> +      which to build multilib support.
> +
>  #--------------------------------------
>  config ARCH_SUPPORTS_BOTH_MMU
>      bool
> diff -r 043b9b789b7d scripts/build/cc/gcc.sh
> --- a/scripts/build/cc/gcc.sh   Wed Feb 26 13:53:25 2014 -0500
> +++ b/scripts/build/cc/gcc.sh   Wed Feb 26 14:45:22 2014 -0500
> @@ -377,6 +377,9 @@
>
>      if [ "${CT_MULTILIB}" = "y" ]; then
>          extra_config+=("--enable-multilib")
> +        if [ -n "${CT_MULTILIB_LIST}" ]; then
> +            extra_config+=("--with-multilib-list=${CT_MULTILIB_LIST}")
> +        fi
>      else
>          extra_config+=("--disable-multilib")
>      fi
>

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

Re: multilib-list

[Trevor Woerner]

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 :-)

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 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.

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.


> 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

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

Re: multilib-list

[Ray Donnelly]

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

Re: 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

Re: multilib-list

[Trevor Woerner]

On 02/26/14 19:37, Ray Donnelly wrote:
>> 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.

Under "Paths and misc options" a user can specify a "Directory
containing custom source components" (CT_CUSTOM_LOCATION_ROOT_DIR). Then
under "Binary utilities" (for example) when choosing the "binutils
version" the user can select "Custom". If no "Full path to custom
binutils source" (CT_BINUTILS_CUSTOM_LOCATION) is provided, crosstool-NG
will look in:

    ${CT_CUSTOM_LOCATION_ROOT_DIR}/binutils

for the binutils source. The same is true for the C compiler version, C
library version, gdb version, and probably others.

This is (IMHO) a very nice feature! In my case I'm investigating using
crosstool-NG to build a toolchain based on the gcc-arm-embedded
sources[1]. Unfortunately the sources for this toolchain are provided as
one tarball which contains the tarballs of all the sub-components (i.e.
gcc, newlib, binutils, etc). Having this feature in crosstool-NG makes
working with these sources much easier and I'm very glad such a thing is
available.

In this case, the gcc-arm-embedded source, although indicated as 4.8.3,
does include multilib capabilities. If the multilib support in
crosstool-NG requires gcc-4.9 or better for ARM toolchains I won't be
able to provide the list of multilib targets for this build.

I think if a crosstool-NG user is making use of the "custom" feature,
there's a chance they're working with pre-release software. In which
case making the multilib facility available would be a good idea. Either
that or abandon trying to determine a priori (based on version number +
architecture alone) which combinations should allow a user to specify
the multilib list :-)



[1] https://launchpad.net/gcc-arm-embedded

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