| Message ID | 530E45F5.1040404@linaro.org |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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
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