Re: [OpenWrt-Devel] any problems with bumping up the toolchain versions?
On Thu, 27 Mar 2008, Imre Kaloz wrote: > 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 *defaults*, it's more likely that people will use them and will > > identify build problems if they exist. > > > > i think it's more valuable to push the toolchain along, just so if > > there are issues hiding in the newer versions, they're identified as > > quickly as possible. > > > > The reason why we stick to 4.1.2 is simply the fact that it compiles > good code. 4.2 is broken on ARM, misscompiles some stuff on x86, not > to mention that probably noone tested all platforms out there. We > slowly bumb toolchain versions when the toolchain is known to work > nicely for some time for a developer. ok, i didn't realize the situation WRT to gcc. but is there anything stopping upgrading the default of binutils to 2.18? does that not work well with any of the architectures? as i mentioned before, unless there's an actual issue, i'm a big fan of pushing version upgrades so that any problems can be identified sooner rather than later. if a newer version of some toolchain component works on all but one architecture, i think it's more useful to bump the default version, except in the case of that one architecture (which is what the binutils Config.in would be doing anyway WRT to avr32, which doesn't have patches for binutils-2.18). anyway, just my $0.02. rday p.s. and what about gdb? currently, it's sitting at 6.3 while 6.7.1 is out. -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Libsamplerate not building - autoconfig version mismatch
On Fri, 28 Mar 2008, Michael wrote: > > 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. there's been a ticket on this for a while: https://dev.openwrt.org/ticket/2851 rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] any problems with bumping up the toolchain versions?
On Thu, 27 Mar 2008, 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.. Some targets work better with newer > compilers, others do not. Spice this is up with uClibc, and you have > fun everytime you play with toolchain combinations ;) > > rday already sent a preliminary 4.3 patch top the list, if you > volunteer to fix it up, we are happy to add it :) Same goes for your > platform :) that was a first attempt, i was making no guarantees. :-) will post more on this later. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [Patch] Libsamplerate not building - autoconfig version mismatch
On Fri, 28 Mar 2008 04:49:49 pm Robert P. J. Day wrote: > On Fri, 28 Mar 2008, Michael wrote: > > 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. > > there's been a ticket on this for a while: > > https://dev.openwrt.org/ticket/2851 > > rday Contrary to the bug - this works for me for a 2.4 - as long as I run aclocal and automake. The only question is whether pushd and popd should be used or whether cd / cd - would be sufficient. Signed-off-by: Michael Geddes --- Index: libs/libsamplerate/Makefile === --- libs/libsamplerate/Makefile (revision 10654) +++ libs/libsamplerate/Makefile (working copy) @@ -42,6 +42,7 @@ endef define Build/Compile + pushd $(PKG_BUILD_DIR) && aclocal && automake && popd $(MAKE) -C $(PKG_BUILD_DIR) all $(call libtool_fixup_libdir,$(PKG_INSTALL_DIR)) $(MAKE) -C $(PKG_BUILD_DIR) DESTDIR="$(PKG_INSTALL_DIR)" install ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Libsamplerate not building - autoconfig version mismatch
On Fri, 28 Mar 2008, Michael wrote: > > 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. apparently, simply upgrading to libsamplerate-0.1.3 solves the problem, and obviates the need for the libtool patch that's necessary for 0.1.2. i can submit a patch for that, but i'm not sure what this line represents in the libsamplerate Makefile: PKG_FIXUP = libtool since there's no further patch for libtool, should i assume this line can be removed? then i'll send in a patch. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] any problems with bumping up the toolchain versions?
> as i mentioned before, unless there's an actual issue, i'm a big fan > of pushing version upgrades so that any problems can be identified > sooner rather than later. if a newer version of some toolchain > component works on all but one architecture, i think it's more useful > to bump the default version, except in the case of that one > architecture (which is what the binutils Config.in would be doing > anyway WRT to avr32, which doesn't have patches for binutils-2.18). Although I can appreciate your enthusiasm for new versions (I run Gentoo), the unfortunate truth is that it takes a great deal of QA to get a particular portion of the toolchain working for an architecture. Unless a new feature (like processor support) is utterly necessary or the current tool is actually broken, I believe it a much better use of a development team's time to focus on bug-squashing and adding their own features rather than ensuring compatibility with fubar-2.81.6.4-r20. Of course, that needs to be balanced in order to avoid a situation like RedHat encountered with gcc-2.95, but all things in balance. More often than not, allowing revisions to "languish" provides a good buffer to allow the very problems you are concerned with to be sorted out at the originator's level. That doesn't mean developers shouldn't be aware of upcoming features and code themselves into corners, but unless there's a dedicated toolchain person or team, the toolchain treadmill is a big one to avoid. In my not-so-informed opinion, early problem identification is not a sufficient nor particularly reasoned justification for attempting to keep up with the ragged edge of toolchain development. Developers for project X are there to work on project X, and not typically to troubleshoot interactions with the toolchain. RB ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
