This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Ray, Cody, Yann, list, On Tue, Feb 4, 2014 at 10:39 AM, Ray Donnelly <mingw.android@gmail.com> wrote: > Just an FYI, > > I will merge some of Cody's work into mine (the get_multilib_target () > part) and post a new version of patch #3 a bit later. > > Cody, I will add a Signed-off-by: in your name, apologies if this is > too presumptuous, obviously we'd need your permission before any merge > could happen. I've updated my wip patch-queue: https://bitbucket.org/bhundven/crosstool-ng-wip I think what it needs now is some guidance, and a little bit of Ray's help to fix the multilib directory issues. Let me know, -Bryan > On Tue, Feb 4, 2014 at 6:29 PM, Bryan Hundven <bryanhundven@gmail.com> wrote: >> Danny, >> >> On Tue, Feb 4, 2014 at 9:44 AM, Danny Gale >> <Daniel.Gale@coloradoengineeringinc.com> wrote: >>> On 02/03/2014 06:12 PM, Bryan Hundven wrote: >>>> >>>> eh, >>>> >>>> On Mon, Feb 3, 2014 at 5:11 PM, Bryan Hundven <bryanhundven@gmail.com> >>>> wrote: >>>>> >>>>> Danny, list, >>>>> >>>>> On Mon, Feb 3, 2014 at 5:08 PM, Bryan Hundven <bryanhundven@gmail.com> >>>>> wrote: >>>>>> >>>>>> The notice in your email caused me some problems. >>>>>> >>>>>> My message was (with the notice removed): >>>>>> >>>>>> On Mon, Feb 3, 2014 at 5:04 PM, Bryan Hundven <bryanhundven@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>> Danny, >>>>>>> >>>>>>> On Mon, Feb 3, 2014 at 4:59 PM, Danny Gale >>>>>>> <Daniel.Gale@coloradoengineeringinc.com> wrote: >>>>>>>> >>>>>>>> We do have another build system on top of CT-NG that pulls it down, >>>>>>>> patches >>>>>>>> it as necessary, and shoves our configration where it needs to be. >>>>>>>> Those >>>>>>>> tags you see, like [WORK_DIR], are replaced before we invoke CT-NG. >>>>>>> >>>>>>> Ah, ok. I'll look at the build log again :) >>>>>>> >>>>>>>> The arch-suffix of -e6500 results in "powerpc64-e6500-linux-gnu", >>>>>>>> which >>>>>>>> seems reasonable to me. >>>>>>> >>>>>>> You should use CT_TARGET_VENDOR instead. >>>>>>> >>>>>>>> >>>>>>>> On Monday, February 03, 2014 5:39:29 PM, Bryan Hundven wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hello, Daniel, all, >>>>>>>>> >>>>>>>>> On Thu, Jan 23, 2014 at 2:37 PM, Danny Gale >>>>>>>>> <Daniel.Gale@coloradoengineeringinc.com> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I've successfully compiled my powerpc64-e6500-linux-gnu toolchain! >>>>>>>>>> Hooray! >>>>>>>>>> :) >>>>>>>>>> >>>>>>>>>> Now, the trouble is that U-Boot doesn't support 64-bit powerpc >>>>>>>>>> builds, so >>>>>>>>>> the toolchain needs to have multilib enabled. The compiler itself is >>>>>>>>>> built >>>>>>>>>> with no problem, but during the "Building for multilib subdir='32'" >>>>>>>>>> step, >>>>>>>>>> the build fails with this error: >>>>>>>>>> [ALL ] ../sysdeps/powerpc/powerpc64/start.S: Assembler messages: >>>>>>>>>> [ALL ] ../sysdeps/powerpc/powerpc64/start.S:50: Error: reloc 1 not >>>>>>>>>> supported by object file format >>>>>>>>>> [ALL ] ../sysdeps/powerpc/powerpc64/start.S:51: Error: reloc 1 not >>>>>>>>>> supported by object file format >>>>>>>>>> [ALL ] ../sysdeps/powerpc/powerpc64/start.S:52: Error: reloc 1 not >>>>>>>>>> supported by object file format >>>>>>>>>> >>>>>>>>>> Those lines in that file look like this: >>>>>>>>>> /* function descriptors so don't need JUMPTARGET */ >>>>>>>>>> .quad BP_SYM(main) >>>>>>>>>> .quad __libc_csu_init >>>>>>>>>> .quad __libc_csu_fini >>>>>>>>>> >>>>>>>>>> Anybody know what this could be about, and how to fix it? >>>>>>>>>> >>>>>>>>>> My config and the tail of my log are attached. >>>>>>>>>> >>>>>>>>>> Thanks for your help, >>>>>>>>>> Danny >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I have some questions about your configuration. >>>>>>>>> >>>>>>>>> In your attached config.txt, you have things like: >>>>>>>>> >>>>>>>>> CT_WORK_DIR="[WORK_DIR]" >>>>>>>>> >>>>>>>>> and an arch suffix "-e6500" (iow: -e6500powerpc64-unknown-linux-gnu) >>>>>>>>> doesn't really make sense to me. >>>>>>>>> >>>>>>>>> I'm surprised this config works at all. >>>>>>>>> >>>>>>>>> Are you making this config with another external tool, such as >>>>>>>>> buildroot or a custom wrapper script? That may make some of my >>>>>>>>> confusion go away. >>>>>>>>> >>>>>>>>> -Bryan >>>>>>>>> >>>>>>>>> (PS, I have an updated config I'll post after I test it.) >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Danny Gale >>>>>>>>> Engineer >>>>>> >>>>>> ... >>>>> >>>>> Beyond that, with the attached config, I got the same failure. >>>>> I think Cody is right about the arch name in the tuple. >>>> >>>> Forgot to attach. I know that some of the settings are wrong, and I >>>> need to add them from your build log, so: v1 >>>> >>>>> I'm gonna poke at this for a second. >>>>> >>>>> -Bryan >>>>> >>>>> >>>>> -- >>>>> For unsubscribe information see http://sourceware.org/lists.html#faq >>> >>> I've switched my configuration over to use the CT_TARGET_VENDOR instead of >>> the arch-suffix for e6500. I had also been having problems with the >>> CT_ARCH_TUNE setting, so I left it out. >> >> Right, arch-suffix is for say, you have an alpha64 gnu/linux toolchain >> that is specifically for ev56. >> The arch-suffix would be: "ev56" >> So that the tuple would be: alpha64ev56-unknown-linux-gnu >> (which is legit in config.sub) >> >> e5500 or e6500 would be the vendor (unknown in our alpha64 case). Just >> as e500v2/e500mc is in their samples. >> The vendor field is pretty arbitrary, but used by toolchain "vendors" >> (you and me in this case) to identify between our powerpc-405 build >> and our powerpc64-e500v2 build. >> >> Send a full build log (from when ct-ng starts to when it ends) so I >> can see what flags are set in the beginning. >> >>> With regard to some of the settings I have in my configuration, gcc 4.7.2 >>> doesn't natively support the e6500 core. Freescale patched it to do so, and >>> I'm using their patches. (They have a git repo here: >>> http://git.freescale.com/git/cgit.cgi/ppc/sdk/gcc.git/ that I diffed against >>> gnu gcc 4.7.2 to generate the patches). GCC introduced support for the e6500 >>> in 4.8. >> >> Good info! I always forget about freescale's git. >> I'm looking at Cody and Ray's patches and a few build logs. >> I have a few other multilib targets I want to test. >> >>> Thanks for all the help, >>> Danny >> >> -- >> For unsubscribe information see http://sourceware.org/lists.html#faq >> -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |