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 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |