On gio, 2008-03-27 at 23:42 +0100, Imre Kaloz wrote:
> On 2008.03.27. 23:37:47 Luigi 'Comio' Mantellini <[EMAIL PROTECTED]> wrote:
>
>
>
> > Ok. Anyway the compiler gcc4.3 supports a lot new cpus (like the
> > coldfire) :) opening new development horizons.
> >
>
> Sure, as AVR32 uses gcc 4.2.3.
On 2008.03.27. 23:37:47 Luigi 'Comio' Mantellini <[EMAIL PROTECTED]> wrote:
> Ok. Anyway the compiler gcc4.3 supports a lot new cpus (like the
> coldfire) :) opening new development horizons.
>
Sure, as AVR32 uses gcc 4.2.3.. Some targets work better with newer
compilers, others do not. Spice t
Il giorno gio, 27/03/2008 alle 23.10 +0100, Imre Kaloz ha scritto:
> On 2008.03.27. 23:03:59 Robert P. J. Day <[EMAIL PROTECTED]> wrote:
>
> >
> > is there any inherent difficulty in bumping up the software versions
> > of the toolchain components? say, binutils to 2.18 and gcc to 4.2.3?
> >
On 2008.03.27. 23:03:59 Robert P. J. Day <[EMAIL PROTECTED]> wrote:
>
> is there any inherent difficulty in bumping up the software versions
> of the toolchain components? say, binutils to 2.18 and gcc to 4.2.3?
> i realize you can always do that *manually* but if those values are
> the *defaul
I am getting an automake version mismatch when compiling libsamplerate.
This worked for me:
define Build/Compile
pushd $(PKG_BUILD_DIR) && aclocal && automake && popd
.
I can make that an official patch if you would like.
//.ichael Geddes
__
is there any inherent difficulty in bumping up the software versions
of the toolchain components? say, binutils to 2.18 and gcc to 4.2.3?
i realize you can always do that *manually* but if those values are
the *defaults*, it's more likely that people will use them and will
identify build proble
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
fix a syntax error i introduced when i added support for
binutils-2.18. oops.
diff --git a/toolchain/binutils/Config.in b/toolchain/binutils/Config.in
index 8fabf4c..1e21ecb 100644
--- a/toolchain/binutils/Config.in
+++ b/toolchain/bin
a while back, i proposed having the build check if any of the
already-installed host tools were suitable so that you didn't have to
download and build them -- "sed" being the perfect example since
almost everyone has a relatively recent "sed" on their system. has
anyone done anything along thos
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
i'm not sure why this patch wouldn't apply cleanly. it applies
perfectly cleanly against the latest git tree with patchlevel 1 on my
system. can anyone else verify this? thanks.
package/fuse/Makefile|
On Thu, 27 Mar 2008, Florian Fainelli wrote:
> Hi Robert,
>
> Le lundi 17 mars 2008, Robert P. J. Day a écrit :
> > Given that fuse-2.7.1 generates a build error, upgrade to fuse-2.7.3,
> > which involves upgrading the Makefile and all of the patches.
> >
>
> Your patch does not apply cleanly by m
On Thu, 27 Mar 2008, Florian Fainelli wrote:
> Hi Robert,
>
> Le lundi 17 mars 2008, Robert P. J. Day a écrit :
> > Given that fuse-2.7.1 generates a build error, upgrade to fuse-2.7.3,
> > which involves upgrading the Makefile and all of the patches.
> >
>
> Your patch does not apply cleanly by m
Hi Robert,
Le lundi 17 mars 2008, Robert P. J. Day a écrit :
> Given that fuse-2.7.1 generates a build error, upgrade to fuse-2.7.3,
> which involves upgrading the Makefile and all of the patches.
>
Your patch does not apply cleanly by me. Can you please update it ?
Thank you very much.
--
Best
Hi Roberto,
Le jeudi 27 mars 2008, Roberto Riggio a écrit :
> Would it be possible to merge this patch in the svn since otherwise
> it is not possible to build openwrt for x86.
Applied in [10672]. Thanks !
--
Best regards, Florian Fainelli
Email : [EMAIL PROTECTED]
http://openwrt.org
---
Would it be possible to merge this patch in the svn since otherwise
it is not possible to build openwrt for x86.
Bye
R.
- "Roberto Riggio" <[EMAIL PROTECTED]> wrote:
> I apologize for the mess. I just wanted to send a patch compliant
> with
> your guidelines (the previous one was embedded in
14 matches
Mail list logo