[Buildroot] Libtool error with AVR32

[Buildroot] Libtool error with AVR32

[don]

I posted this error some time ago.  With all the recent AVR32 changes, I
decided to try again.  It is still happening.

The libdaemon configure script is saying

   "*** libtool.m4 and ltmain.sh have a version mismatch! ***"

I had thought that this was related to my host files.  However examining
the "configure" for for libdaemin-0.12 shows that this check and these
message are in that file.  Why doesn't everyone get this error?

The libdaemon-0.12 directory has the 1.5.22 version.
The requirement for 1.5.24 is hard coded into that "configure" script.

...
gentoo_lt_version="1.5.24"
gentoo_ltmain_version=`sed -n '/^[ 	]*VERSION=/{s/^[ 	]*VERSION=//;p;q;}' "$ltmain"`
if test "x$gentoo_lt_version" != "x$gentoo_ltmain_version" ; then
...

Interestingly, there are different versions of ltmain.sh in my build
tree, and this is a totally clean tree pulled from svn yesterday.

VERSION="1.5.22 Debian 1.5.22-2"
./build_avr32/pkg-config-0.21/ltmain.sh
VERSION="1.5.22 Debian 1.5.22-2"
./build_avr32/pkg-config-0.21/glib-1.2.8/ltmain.sh
VERSION="1.5.22 Debian 1.5.22-4"
./build_avr32/libdaemon-0.12/ltmain.sh
VERSION=1.4a-GCC3.0
./toolchain_build_avr32/gcc-4.1.2-avr32-2.0/ltmain.sh
VERSION=1.5.0a
./toolchain_build_avr32/gcc-4.1.2-avr32-2.0/libjava/libltdl/ltmain.sh
VERSION=1.4a-GCC3.0
./toolchain_build_avr32/gcc-4.1.2-avr32-2.0/libjava/classpath/ltmain.sh
VERSION=1.4a-GCC3.0
./toolchain_build_avr32/binutils-2.17-avr32-2.1.3/ltmain.sh
VERSION=1.5.24
./toolchain_build_avr32/gmp-4.2.2/ltmain.sh
VERSION="1.5.24 Debian 1.5.24-1"
./toolchain_build_avr32/mpfr-2.3.0/ltmain.sh



----- Forwarded message from don <don_reid@comcast.net> -----
Date: Thu, 27 Sep 2007 11:17:57 -0700
From: don <don_reid@comcast.net>
To: buildroot at uclibc.org
Subject: Libtool error with AVR32

I tried to use the latest AVR32 release from ATmel and got an error.
Is there somewhere else to post that other than this list?

The error is in build_avr32_nofpu/libdaemon-0.12 and is:

...
configure: WARNING: In the future, Autoconf will not detect cross-tools
whose name does not start with the host triplet.  If you think this
configuration is useful to you, please write to autoconf at gnu.org.
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether gfortran accepts -g... yes
checking the maximum length of command line arguments... 98304
checking command to parse /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-nm output from /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-gcc -Os -pipe  -I/home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/include -msoft-float object... ok
checking for objdir... .libs
checking for avr32-linux-ar... /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-ar
checking for avr32-linux-ranlib... /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-ranlib
checking for avr32-linux-strip... (cached) /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-strip
checking for correct ltmain.sh version... no
configure: error:

*** [Gentoo] sanity check failed! ***
*** libtool.m4 and ltmain.sh have a version mismatch! ***
*** (libtool.m4 = 1.5.24, ltmain.sh = "1.5.22 Debian 1.5.22-4") ***

Please run:

  libtoolize --copy --force

if appropriate, please contact the maintainer of this
package (or your distribution) for help.

make: *** [/home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/libdaemon-0.12/.configured] Error 1

----- End forwarded message -----

[Buildroot] Libtool error with AVR32

[Ivan Kuten]

> configure: error:
> 
> *** [Gentoo] sanity check failed! ***
> *** libtool.m4 and ltmain.sh have a version mismatch! ***
> *** (libtool.m4 = 1.5.24, ltmain.sh = "1.5.22 Debian 1.5.22-4") ***
> 
> Please run:
> 
>   libtoolize --copy --force
> 

Have you tried to run "libtoolize --copy --force" manually?


BR,
Ivan

[Buildroot] Libtool error with AVR32

[don]

On Mon, Oct 15, 2007 at 02:34:34AM +0300, Ivan Kuten wrote:
> > configure: error:
> > 
> > *** [Gentoo] sanity check failed! ***
> > *** libtool.m4 and ltmain.sh have a version mismatch! ***
> > *** (libtool.m4 = 1.5.24, ltmain.sh = "1.5.22 Debian 1.5.22-4") ***
> > 
> > Please run:
> > 
> >   libtoolize --copy --force
> > 
> 
> Have you tried to run "libtoolize --copy --force" manually?

When I tried it before I must have not been in the right directory (or had
some other problem).  This time I ran that from build_avr32/libdaemon-0.12
and then went back to the top.  The build was able to continue, thanks.

-- 
Don

[Buildroot] Libtool error with AVR32

[don]

I tried to use the latest AVR32 release from ATmel and got an error.
Is there somewhere else to post that other than this list?

The error is in build_avr32_nofpu/libdaemon-0.12 and is:

...
configure: WARNING: In the future, Autoconf will not detect cross-tools
whose name does not start with the host triplet.  If you think this
configuration is useful to you, please write to autoconf at gnu.org.
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether gfortran accepts -g... yes
checking the maximum length of command line arguments... 98304
checking command to parse /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-nm output from /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-gcc -Os -pipe  -I/home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/include -msoft-float object... ok
checking for objdir... .libs
checking for avr32-linux-ar... /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-ar
checking for avr32-linux-ranlib... /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-ranlib
checking for avr32-linux-strip... (cached) /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-strip
checking for correct ltmain.sh version... no
configure: error:

*** [Gentoo] sanity check failed! ***
*** libtool.m4 and ltmain.sh have a version mismatch! ***
*** (libtool.m4 = 1.5.24, ltmain.sh = "1.5.22 Debian 1.5.22-4") ***

Please run:

  libtoolize --copy --force

if appropriate, please contact the maintainer of this
package (or your distribution) for help.

make: *** [/home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/libdaemon-0.12/.configured] Error 1

[Buildroot] Libtool error with AVR32

[Ulf Samuelsson]

tor 2007-09-27 klockan 11:17 -0700 skrev don:
> I tried to use the latest AVR32 release from ATmel and got an error.
> Is there somewhere else to post that other than this list?
> 
> The error is in build_avr32_nofpu/libdaemon-0.12 and is:
> ...
> configure: WARNING: In the future, Autoconf will not detect cross-tools
> whose name does not start with the host triplet.  If you think this
> configuration is useful to you, please write to autoconf at gnu.org.
> checking whether we are using the GNU Fortran 77 compiler... yes
> checking whether gfortran accepts -g... yes
> checking the maximum length of command line arguments... 98304
> checking command to parse /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-nm output from /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-gcc -Os -pipe  -I/home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/include -msoft-float object... ok
> checking for objdir... .libs
> checking for avr32-linux-ar... /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-ar
> checking for avr32-linux-ranlib... /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-ranlib
> checking for avr32-linux-strip... (cached) /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-strip
> checking for correct ltmain.sh version... no
> configure: error:
> 

The general rule is that the main buildroot mailing list is for the 
main buildroot trunk.
The atmel AVR32 specific buildroot at www.atmel.no/buildroot,
is, as documentation tells you, based on 2007-07-18.

Only a limited set of packages has seen testing in the Atmel trunk.
If you use a package, not tested, then problem like this can occur.
Your best alternative is likely to download the main trunk
and copy the contents of package/<package> to the Atmel trunk.

Best Regards
Ulf Samuelsson.


> *** [Gentoo] sanity check failed! ***
> *** libtool.m4 and ltmain.sh have a version mismatch! ***
> *** (libtool.m4 = 1.5.24, ltmain.sh = "1.5.22 Debian 1.5.22-4") ***
> 
> Please run:
> 
>   libtoolize --copy --force
> 
> if appropriate, please contact the maintainer of this
> package (or your distribution) for help.
> 
> make: *** [/home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/libdaemon-0.12/.configured] Error 1
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot

[Buildroot] Libtool error with AVR32

[don]

On Thu, Sep 27, 2007 at 10:53:58PM +0200, Ulf Samuelsson wrote:
> tor 2007-09-27 klockan 11:17 -0700 skrev don:
> > I tried to use the latest AVR32 release from ATmel and got an error.
> > Is there somewhere else to post that other than this list?
> > 
> > The error is in build_avr32_nofpu/libdaemon-0.12 and is:
> > ...
> > configure: WARNING: In the future, Autoconf will not detect cross-tools
> > whose name does not start with the host triplet.  If you think this
> > configuration is useful to you, please write to autoconf at gnu.org.
> > checking whether we are using the GNU Fortran 77 compiler... yes
> > checking whether gfortran accepts -g... yes
> > checking the maximum length of command line arguments... 98304
> > checking command to parse /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-nm output from /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-gcc -Os -pipe  -I/home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/include -msoft-float object... ok
> > checking for objdir... .libs
> > checking for avr32-linux-ar... /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-ar
> > checking for avr32-linux-ranlib... /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-ranlib
> > checking for avr32-linux-strip... (cached) /home/dev/AVR32/Buildroot/buildroot-avr32-2.1.0-rc5/build_avr32_nofpu/staging_dir/usr/bin/avr32-linux-uclibc-strip
> > checking for correct ltmain.sh version... no
> > configure: error:
> > 
> 
> The general rule is that the main buildroot mailing list is for the 
> main buildroot trunk.
> The atmel AVR32 specific buildroot at www.atmel.no/buildroot,
> is, as documentation tells you, based on 2007-07-18.
> 
> Only a limited set of packages has seen testing in the Atmel trunk.
> If you use a package, not tested, then problem like this can occur.
> Your best alternative is likely to download the main trunk
> and copy the contents of package/<package> to the Atmel trunk.

I did not select any packages, just copied the ntgw100_defconfig to
.config.

-- 
Don

[Buildroot] Libtool error with AVR32

[Bernhard Fischer]

On Thu, Sep 27, 2007 at 03:19:19PM -0700, don wrote:
>On Thu, Sep 27, 2007 at 10:53:58PM +0200, Ulf Samuelsson wrote:
>> tor 2007-09-27 klockan 11:17 -0700 skrev don:
>> > I tried to use the latest AVR32 release from ATmel and got an error.
>> > Is there somewhere else to post that other than this list?
>> > 
>> > The error is in build_avr32_nofpu/libdaemon-0.12 and is:

>I did not select any packages, just copied the ntgw100_defconfig to
>.config.

Ulf, can you point me to a known good revision (of buildroot) that built
that ntgw100 successfully, please? Modulo libdaemon, or other such
packages. This would help alot to pinpoint any possible problems.

Don, I'm still under the impression that you're using something
provided by atmel and not http://buildroot.uclibc.org/
This is not the appropriate place for the "latest AVR32 release from
ATmel" but for buildroot.

thanks,

[Buildroot] Libtool error with AVR32

[Ulf Samuelsson]

fre 2007-09-28 klockan 00:34 +0200 skrev Bernhard Fischer:
> On Thu, Sep 27, 2007 at 03:19:19PM -0700, don wrote:
> >On Thu, Sep 27, 2007 at 10:53:58PM +0200, Ulf Samuelsson wrote:
> >> tor 2007-09-27 klockan 11:17 -0700 skrev don:
> >> > I tried to use the latest AVR32 release from ATmel and got an error.
> >> > Is there somewhere else to post that other than this list?
> >> > 
> >> > The error is in build_avr32_nofpu/libdaemon-0.12 and is:
> 
> >I did not select any packages, just copied the ntgw100_defconfig to
> >.config.
> 
> Ulf, can you point me to a known good revision (of buildroot) that built
> that ntgw100 successfully, please? Modulo libdaemon, or other such
> packages. This would help alot to pinpoint any possible problems.
> 

No, everything has been failing during the last few months, and I dont
have anything working.
The www.atmel.no/buildroot. which is based on 20070718.
The binutils+uclibc+gcc+gdb tarballs are generated by
make *-unpacked 
for all packages (patching with Buildroot patches and atmel avr32
specific patches from the atmel buildroot), so the tarball
contents should be identical to the atmel buildroot.
It has to be something in the Makefile which screw up things.

I have been trying to autoreconfig the gcc-4.1.2 today to see if that
helps, obviously the configure's in the tarball does not reflect
the contents of configure.ac...



> Don, I'm still under the impression that you're using something
> provided by atmel and not http://buildroot.uclibc.org/
> This is not the appropriate place for the "latest AVR32 release from
> ATmel" but for buildroot.

Yes, he is building the Atmel buildroot.
www.avrfreaks.net Linux forum is a better place.


> 
> thanks,

[Buildroot] Libtool error with AVR32

[don]

On Fri, Sep 28, 2007 at 12:34:20AM +0200, Bernhard Fischer wrote:
> On Thu, Sep 27, 2007 at 03:19:19PM -0700, don wrote:
> >On Thu, Sep 27, 2007 at 10:53:58PM +0200, Ulf Samuelsson wrote:
> >> tor 2007-09-27 klockan 11:17 -0700 skrev don:
> >> > I tried to use the latest AVR32 release from ATmel and got an error.
> >> > Is there somewhere else to post that other than this list?
> >> > 
> >> > The error is in build_avr32_nofpu/libdaemon-0.12 and is:
> 
> >I did not select any packages, just copied the ntgw100_defconfig to
> >.config.
> 
> Ulf, can you point me to a known good revision (of buildroot) that built
> that ntgw100 successfully, please? Modulo libdaemon, or other such
> packages. This would help alot to pinpoint any possible problems.
> 
> Don, I'm still under the impression that you're using something
> provided by atmel and not http://buildroot.uclibc.org/
> This is not the appropriate place for the "latest AVR32 release from
> ATmel" but for buildroot.

I'm using an archive of buildroot that Atmel provides on their website.
I have tried to use the "current" svn buildroot many many times over
months, and it has never worked.  From the list I can see that buildroot
is highly unstable.

I had hoped that Atmel had a frozen version that works.  I'm sure it
does under some conditions.  

In this case I suspect that my up to date Gentoo host has a new version of
autoconf that is doing some new check.  I thought you might want to know
about this as it will probably come up again.

Have you considered creating buildroot releases, which are frozen
excerpt for simple bug fixes?  It seems that the rate of new "features"
is such that the trunk version is in constant flux.

Thank you
Don

[Buildroot] Libtool error with AVR32

[Ulf Samuelsson]

fre 2007-09-28 klockan 09:09 -0700 skrev don:
> On Fri, Sep 28, 2007 at 12:34:20AM +0200, Bernhard Fischer wrote:
> > On Thu, Sep 27, 2007 at 03:19:19PM -0700, don wrote:
> > >On Thu, Sep 27, 2007 at 10:53:58PM +0200, Ulf Samuelsson wrote:
> > >> tor 2007-09-27 klockan 11:17 -0700 skrev don:
> > >> > I tried to use the latest AVR32 release from ATmel and got an error.
> > >> > Is there somewhere else to post that other than this list?
> > >> > 
> > >> > The error is in build_avr32_nofpu/libdaemon-0.12 and is:
> > 
> > >I did not select any packages, just copied the ntgw100_defconfig to
> > >.config.
> > 
> > Ulf, can you point me to a known good revision (of buildroot) that built
> > that ntgw100 successfully, please? Modulo libdaemon, or other such
> > packages. This would help alot to pinpoint any possible problems.
> > 
> > Don, I'm still under the impression that you're using something
> > provided by atmel and not http://buildroot.uclibc.org/
> > This is not the appropriate place for the "latest AVR32 release from
> > ATmel" but for buildroot.
> 
> I'm using an archive of buildroot that Atmel provides on their website.
> I have tried to use the "current" svn buildroot many many times over
> months, and it has never worked.  From the list I can see that buildroot
> is highly unstable.
> 
> I had hoped that Atmel had a frozen version that works.  I'm sure it
> does under some conditions.

Do you do:
$ make atstk1000_defconfig or make atngw100_defconfig
followed by
$ make
?

This should work. Works for me.

Please note that this is what this is what the Atmel buildroot does.
It does not support that you enable any other application 
than what is supported by these two configs.

May of the buildroot packages have not been ported to AVR32.
Also, there are general purpose issues with a lot of the packages in
buildroot.
I know that libdaemon has been updated in the main trunk since the
AVR branch was spun off.
Before the release, I expect that the Atmel trunk will be 
brought up to date with the main trunk.

I have made considerable progress today with the main trunk.
Previously "configure" would configure the assembler, linker
and other programs as beeing totally empty.

gcc-4.1.2-final/gcc/as would contain

#bin/bash
exec "$@"

where it should be
#bin/bash
exec "$(TARGET_CROSS)as $@"

so basically everything would fail.

I have now managed to build a lot of libraries,in gcc,
but it still bombs with libssp, which in libtool
insists on linking using $(CC) which is of course "/usr/bin/gcc" :-)

I believe the fixes I have been working on may also 
allow --sysroot to work on gcc-4.1.2, but have to get things done 100%
before I can confirm this.

Best Regards
Ulf Samuelsson

> In this case I suspect that my up to date Gentoo host has a new version of
> autoconf that is doing some new check.  I thought you might want to know
> about this as it will probably come up again.
> 
> Have you considered creating buildroot releases, which are frozen
> excerpt for simple bug fixes?  It seems that the rate of new "features"
> is such that the trunk version is in constant flux.
> 
> Thank you
> Don

[Buildroot] Libtool error with AVR32

[don]

On Fri, Sep 28, 2007 at 06:38:02PM +0200, Ulf Samuelsson wrote:
> fre 2007-09-28 klockan 09:09 -0700 skrev don:
> > On Fri, Sep 28, 2007 at 12:34:20AM +0200, Bernhard Fischer wrote:
> > > On Thu, Sep 27, 2007 at 03:19:19PM -0700, don wrote:
> > > >On Thu, Sep 27, 2007 at 10:53:58PM +0200, Ulf Samuelsson wrote:
> > > >> tor 2007-09-27 klockan 11:17 -0700 skrev don:
> > > >> > I tried to use the latest AVR32 release from ATmel and got an error.
> > > >> > Is there somewhere else to post that other than this list?
> > > >> > 
> > > >> > The error is in build_avr32_nofpu/libdaemon-0.12 and is:
> > > 
> > > >I did not select any packages, just copied the ntgw100_defconfig to
> > > >.config.
> > > 
> > > Ulf, can you point me to a known good revision (of buildroot) that built
> > > that ntgw100 successfully, please? Modulo libdaemon, or other such
> > > packages. This would help alot to pinpoint any possible problems.
> > > 
> > > Don, I'm still under the impression that you're using something
> > > provided by atmel and not http://buildroot.uclibc.org/
> > > This is not the appropriate place for the "latest AVR32 release from
> > > ATmel" but for buildroot.
> > 
> > I'm using an archive of buildroot that Atmel provides on their website.
> > I have tried to use the "current" svn buildroot many many times over
> > months, and it has never worked.  From the list I can see that buildroot
> > is highly unstable.
> > 
> > I had hoped that Atmel had a frozen version that works.  I'm sure it
> > does under some conditions.
> 
> Do you do:
> $ make atstk1000_defconfig or make atngw100_defconfig

Yes, the later.

> This should work. Works for me.
> 
> Please note that this is what this is what the Atmel buildroot does.
> It does not support that you enable any other application 
> than what is supported by these two configs.

I did not do anything else like enable any other packages.

> I have made considerable progress today with the main trunk.

Thanks for all your work.  I will try the main trunk again an a few
days.

-- 
Don

[Buildroot] Libtool error with AVR32

[Bernhard Fischer]

On Fri, Sep 28, 2007 at 09:09:19AM -0700, don wrote:

>> Don, I'm still under the impression that you're using something
>> provided by atmel and not http://buildroot.uclibc.org/
>> This is not the appropriate place for the "latest AVR32 release from
>> ATmel" but for buildroot.
>
>I'm using an archive of buildroot that Atmel provides on their website.

>Have you considered creating buildroot releases, which are frozen
>excerpt for simple bug fixes?  It seems that the rate of new "features"

Well, I'm thinking about doing this, yes. The problem with a project
like buildroot (or any distribution) is that it's a moving target per
definition. Software receives bug-fixes (upstream) or fancy features
that you may want to use, so you have to update packages sometimes.

We don't add much new "features", really. Except for huge experimental
bundles like xorg only a small number of packages are added (which is a
good thing since they cost time to keep uptodate).

cheers,

[Buildroot] Libtool error with AVR32

[Ulf Samuelsson]

fre 2007-09-28 klockan 18:51 +0200 skrev Bernhard Fischer:
> On Fri, Sep 28, 2007 at 09:09:19AM -0700, don wrote:
> 
> >> Don, I'm still under the impression that you're using something
> >> provided by atmel and not http://buildroot.uclibc.org/
> >> This is not the appropriate place for the "latest AVR32 release from
> >> ATmel" but for buildroot.
> >
> >I'm using an archive of buildroot that Atmel provides on their website.
> 
> >Have you considered creating buildroot releases, which are frozen
> >excerpt for simple bug fixes?  It seems that the rate of new "features"
> 
> Well, I'm thinking about doing this, yes. The problem with a project
> like buildroot (or any distribution) is that it's a moving target per
> definition. Software receives bug-fixes (upstream) or fancy features
> that you may want to use, so you have to update packages sometimes.

It is easily fixed if all targets has

ifeq ($(<PACKAGE>_VERSION),)
<PACKAGE>_VERSION:=<latest_version>
endif

Then the user can supply whatever

<PACKAGE>_VERSION:=<my own version>

he/she wants.


> 
> We don't add much new "features", really. Except for huge experimental
> bundles like xorg only a small number of packages are added (which is a
> good thing since they cost time to keep uptodate).
> 
> cheers,

[Buildroot] Libtool error with AVR32

[Ivan Kuten]

> 
> Well, I'm thinking about doing this, yes. The problem with a project
> like buildroot (or any distribution) is that it's a moving target per
> definition. Software receives bug-fixes (upstream) or fancy features
> that you may want to use, so you have to update packages sometimes.
> 
> We don't add much new "features", really. Except for huge experimental
> bundles like xorg only a small number of packages are added (which is a
> good thing since they cost time to keep uptodate).
> 

I think it would be good to create a -testing branch and to push in this
branch fixes and additions. And main branch keep stable as possible.

Also it would be useful to create something like this "http://kegel.com/crosstool/crosstool-0.43/buildlogs/"
but for package/target status.

I can help if we decide to do something in that direction.

Best regards,
Ivan

--------------------------------
Embedded Linux engineer,
Promwad Company: http://www.promwad.com/
Homepage : http://www.ivankuten.com/
--------------------------------

[Buildroot] Libtool error with AVR32

[Thiago A. Corrêa]

On 9/28/07, Ivan Kuten <ivan.kuten@promwad.com> wrote:
> I think it would be good to create a -testing branch and to push in this
> branch fixes and additions. And main branch keep stable as possible.
>
> Also it would be useful to create something like this "http://kegel.com/crosstool/crosstool-0.43/buildlogs/"
> but for package/target status.

I was trying to setup a buildbot for buildroot/avr32 but then had to
put out some fires and didn't had the time to go back to manual
reading/etc.... I was trying to setup a buildmaster, but if someone
closer to the project would like to setup an official buildmaster, I
would gladly join as a buildbot.

Anyway, if someone would like to help figuring out how to setup a
buildmaster, I don't have an issue with it running on my server :)

> I can help if we decide to do something in that direction.

I would be glad to help as well.


Friendly Regards,
    Thiago A. Correa

[Buildroot] Libtool error with AVR32

[Bernhard Fischer]

On Fri, Sep 28, 2007 at 08:17:18PM +0100, Thiago A. Corr?a wrote:
>On 9/28/07, Ivan Kuten <ivan.kuten@promwad.com> wrote:

>> Also it would be useful to create something like this "http://kegel.com/crosstool/crosstool-0.43/buildlogs/"
>> but for package/target status.
>
>I was trying to setup a buildbot for buildroot/avr32 but then had to
>put out some fires and didn't had the time to go back to manual
>reading/etc.... I was trying to setup a buildmaster, but if someone
>closer to the project would like to setup an official buildmaster, I
>would gladly join as a buildbot.

IIRC we already have a buildbot for uClibc. Not sure how loaded the
participants are, though.