This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ 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] |
On 18. feb. 2011 11:40, ng@piments.com wrote: > > On 02/18/11 10:11, Per Arnold Blaasmo wrote: >> 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. > > Thanks Per, > > I ran those lines from the shell but had to iterate the for loop by > hand. It went cleanly but what context where you intending that to be run? They are actually run from a bash script. > > It seems to have cleared the last error but when I restart ct-ng build I > get a whole string of errors of the same type: > > [INFO ] Installing binutils > [EXTRA] Configuring binutils > [EXTRA] Building binutils > [ERROR] > /back/ts/ct-ng/targets/src/binutils-2.20.1/bfd/elf32-avr32.c:168: error: > 'BFD_RELOC_AVR32_DIFF32' undeclared here (not in a function) > [ERROR] > /back/ts/ct-ng/targets/src/binutils-2.20.1/bfd/elf32-avr32.c:169: error: > 'BFD_RELOC_AVR32_DIFF16' undeclared here (not in a function) > > Have I missed a patch somewhere ? No, but for binutils there is an extra step when building: binutils/configure \ --with-pkgversion="Whatever version string you would like"\ --with-bugurl="http://www.atmel.com/avr"\ --target=avr32 \ --host=<host_platform> \ --build=<build_platform> \ --prefix=<PREFIX>\ --disable-nls \ --disable-werror make all-bfd TARGET-bfd=headers # force reconfiguring rm bfd/Makefile make configure-host make See if this sequence helps! Per A. > > regards, Peter. > > -- > 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] |