Multilib problem

Ray Donnelly mingw.android@gmail.com
Tue Feb 4 18:39:00 GMT 2014


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.

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



More information about the crossgcc mailing list