Re: Multilib problem

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

Bryan, Cody, Yann, list,

Thanks for the update.

I will get on with adding my bits after work today.

On Wed, Feb 12, 2014 at 6:01 AM, Bryan Hundven <bryanhundven@gmail.com> wrote:
> 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