BFD does not support target avr32-unknown-none.
Per Arnold Blaasmo
root@sjogate2.atmel.com
Fri Feb 18 10:39:00 GMT 2011
On 18. feb. 2011 02:37, ng@piments.com wrote:
> On 02/17/11 17:41, ng@piments.com wrote:
>> On 02/15/11 16:07, Per Arnold Blåsmo wrote:
>>> Have a look at http://distribute.atmel.no/tools/opensource/
>>> for some patches.
>>>
>>> Regards
>>> Per A.
>>>
>>> On 15. feb. 2011 13:31, ng@piments.com wrote:
>>>> On 15/02/11 00:07, Yann E. MORIN wrote:
>>>>> Peter, All,
>>>>>
>>>>> On Monday 14 February 2011 23:39:19 ng@piments.com wrote:
>>>>>> I am attempting to use ct-ng to build a toolchain for avr32.
>>>>>>
>>>>>> I used the 'sample' included in 1.9.2 and it built OK. But when I
>>>>>> try to
>>>>>> add gdb it fails with an obscure error I have not been able to find
>>>>>> any
>>>>>> info on.
>>>>>>
>>>>>> nano /back/ts/ct-ng/x-tools/avr32-unknown-none/build.log
>>>>>> [ALL ] checking linker --as-needed support... yes
>>>>>> [ALL ] checking for cos in -lm... yes
>>>>>> [ALL ] *** BFD does not support target avr32-unknown-none.
>>>>>> [ALL ] *** Look in bfd/config.bfd for supported targets.
>>>>>
>>>>> It seems to me that avr32 is not supported in upstream gdb.
>>>>> It requires a patch, which you may get from Atmel (registration
>>>>> required):
>>>>> http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4118
>>>>>
>>>>> Look for:
>>>>>
>>>>> AVR32 GNU Toolchain 2.4.2 - Linux Source Code (102 MB, revision
>>>>> 2.4.2, updated 01/10) AVR32 GNU Toolchain Linux Source code
>>>>>
>>>>> I don't know what version of gdb is available in there, though. I am
>>>>> not registered.
>>>>>
>>>>> Going the hacker's way, would it be possible to replace the gdb BFD
>>>>> with
>>>>> the one from binutils? Hehe... Open-heart surgery. :-]
>>>>
>>>> Maybe not so hairy.
>>>>
>>>> from avr32-gdb.spec :
>>>>
>>>> # Remove the files that are part of a gdb build but that are owned and
>>>> # provided by other packages.
>>>> # These are part of binutils
>>>>
>>>> %__rm -rf $RPM_BUILD_ROOT/usr/share/locale/
>>>> %__rm -f $RPM_BUILD_ROOT%{_infodir}/bfd*
>>>> %__rm -f $RPM_BUILD_ROOT%{_infodir}/standard*
>>>> %__rm -f $RPM_BUILD_ROOT%{_infodir}/mmalloc*
>>>> %__rm -f $RPM_BUILD_ROOT%{_infodir}/configure*
>>>> %__rm -rf $RPM_BUILD_ROOT/usr/include/
>>>> %__rm -rf
>>>> $RPM_BUILD_ROOT/%{_libdir}/lib{bfd*,opcodes*,iberty*,mmalloc*}
>>>>
>>>>
>>>> If my, as yet limited understanding of this process is correct, it
>>>> seems that they are using the binutils bfd.
>>>>
>>>> Make sense?
>>>>
>>>> regards, Peter.
>>>>
>>>>
>>>>>
>>>>>> I know this build is marked experimental but I see a lot of stuff out
>>>>>> there that seems to suggest avr-gdb is working on linux
>>>>>
>>>>> Warning: avr != avr32. avr is 8-bit, avr32 is 32-bit. What you want is
>>>>> avr32-gdb.
>>>>>
>>>>> Regards,
>>>>> Yann E. MORIN.
>>>>>
>>>>
>>>>
>>
>>
>> Thanks Per, it looks like that is more upto date than what I was using
>> from the other download.
>>
>>
>> All:
>>
>> I added usual structures at the same level as the stock ct-ng patch
>> directory and added the patches . ct-ng build started well and binutils
>> patches all applied cleanly , but then it got confused in gcc-4.3.3.
>>
>>
>>
>>
>> diff -rupwN gcc/calls.c gcc/calls.c
>> --- gcc/calls.c 2008-06-24 02:58:17.000000000 -0500
>> +++ gcc/calls.c 2010-08-26 11:56:14.000000000 -0500
>> @@ -3466,7 +3466,7 @@ emit_library_call_value_1 (int retval, r
>> for (; count < nargs; count++)
>> {
>> rtx val = va_arg (p, rtx);
>> - enum machine_mode mode = va_arg (p, enum machine_mode);
>> + enum machine_mode mode = va_arg (p, int);
>>
>> /* We cannot convert the arg value to the mode the library wants here;
>> must do it earlier where we know the signedness of the arg. */
>> diff -rupwN gcc/config/avr32/avr32.c gcc/config/avr32/avr32.c
>> --- gcc/config/avr32/avr32.c 1969-12-31 18:00:00.000000000 -0600
>> +++ gcc/config/avr32/avr32.c 2010-08-26 11:59:24.000000000 -0500
>> @@ -0,0 +1,8090 @@
>> +/*
>>
>>
>> The latter snip "worked" because it created a new file (althought it
>> created it at the wrong level) , all other parts of the patch, like the
>> first snip here, failed to find the targer file.
>>
>>
>> here's the first binutls patch that did work:
>>
>> diff -Nwarup ./config/override.m4
>> ../avr32-binutils-trunk/config/override.m4
>> --- ./config/override.m4 2010-03-03 19:28:57.000000000 +0530
>> +++ ../avr32-binutils-trunk/config/override.m4 2010-04-01
>> 19:28:34.968750000 +0530
>> @@ -52,7 +52,7 @@ dnl Or for updating the whole tree at on
>> AC_DEFUN([_GCC_AUTOCONF_VERSION_CHECK],
>> [m4_if(m4_defn([_GCC_AUTOCONF_VERSION]),
>> m4_defn([m4_PACKAGE_VERSION]), [],
>> - [m4_fatal([Please use exactly Autoconf ]_GCC_AUTOCONF_VERSION[ instead
>> of ]m4_defn([m4_PACKAGE_VERSION])[.])])
>> + [m4_errprintn([Please use exactly Autoconf ]_GCC_AUTOCONF_VERSION[
>> instead of ]m4_defn([m4_PACKAGE_VERSION])[.])])
>> ])
>> m4_define([AC_INIT], m4_defn([AC_INIT])[
>> _GCC_AUTOCONF_VERSION_CHECK
>>
>>
>>
>> comparing the formats it seems like they were not created in the same
>> way.
>>
>> if I add ./ to all file names and add -a to diff it works:
>>
>> diff -rupwNa ./gcc/calls.c ./gcc/calls.c
>> --- ./gcc/calls.c 2008-06-24 02:58:17.000000000 -0500
>> +++ ./gcc/calls.c 2010-08-26 11:56:14.000000000 -0500
>>
>>
>> I guess this was some kind of error in preparation of those patches but
>> it's a headache.
>>
>> Can anyone suggest a simple means to correct this ? I presume ct-ng is a
>> bit stubborn about what format it expects so I'm looking for an
>> alternative to hand editing every line of each hunk.
>>
>> There's a lot of files with lots of hunks.
>>
>> Is there an obvious trick I'm missing?
>>
>> TIA,.
>>
>>
>>
>> --
>> For unsubscribe information see http://sourceware.org/lists.html#faq
>>
>>
>
> OK, after much grepping and sedding I have got all those patches into
> some kind of consistent state that ct-ng can deal with in one go.
>
> However, binutls fails during configure.:
>
> [ALL ] checking for zlib.h... yes
> [ALL ] checking linker --as-needed support... yes
> [ALL ] checking for cos in -lm... yes
> [ERROR] configure: error: *** unknown target vector bfd_elf32_avr32_vec
> [ERROR] make[2]: *** [configure-bfd] Error 1
>
>
> Any suggestions ?
Try preing binutils source folder with:
cd binutils
# Some sed magic to make autotools work on platforms with different
autotools version
# Works for binutils 2.20.1. May work for other versions.
sed -i 's/AC_PREREQ(2.64)/AC_PREREQ(2.63)/g' ./configure.ac ||
task_error "sed failed"
sed -i 's/AC_PREREQ(2.64)/AC_PREREQ(2.63)/g'
./libiberty/configure.ac || task_error "sed failed"
sed -i 's/ \[m4_fatal(\[Please use exactly Autoconf \]/
\[m4_errprintn(\[Please use exactly Autoconf \]/g' ./config/override.m4
|| task_error "sed failed"
autoconf || task_error "autoconf failed"
for d in bfd opcodes binutils ld gas gprof ; do
do_pushd ${d}
autoreconf || task_error "autoreconf in $d failed."
do_popd
done
Per A.
> TIA, , Peter.
>
>
>
> --
> 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