[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Thu, 2008-07-03 at 22:43 +0100, Rob Beard wrote: > Hi folks, > > I was wondering if someone might possibly be able to help. I'm in the > process of trying to compile a custom version of Darkice which has been > modified to record audio to disk (it's a radio legal logger system > called DarkLog). > > Now the problem is, this program is fairly old. It's got a Makefile > which has been created with Automake 1.6. Do you mean Makefile, Makefile.in or Makefile.am ? Is there a configure.ac or configure.in as well as configure? Is there an autogen.sh script? > I've tried with no success > compiling it on Ubuntu 8.04 and Debian 4.0 but it appears that both > these distros don't have packages for Automake 1.6. I see that Debian > Sarge does have Automake 1.6 but now it's no longer supported. (and for good reasons - horribly buggy and even if you could install it, you would probably have to downgrade your compiler to match.) > I wondered, is it easy to convert the Automake files to Automake 1.6? No. Is there no upstream activity? Either: If you have Makefile.am and configure.ac or configure.in, you can upgrade the autotools but the package is likely to break somewhere else due to changes elsewhere in the build toolchain. Each version of automake and the other autotools is matched against the default version of gcc at the time of development. Changes in gcc dictate changes in autotools and changes in gcc bring in new checks for the codebase, new warnings and errors that were not errors before. This means fixing the actual source code to avoid bugs that have been discovered via other packages. A lot of these bugs are portability bugs, a lot are just updated checks to catch particularly ugly hacks in the source code. The older the source code, the more likely it is that the source code contains one or more of these nasty, ugly, hacks. This is the process known as bitrot. Or If you only have configure and Makefile, you are faced with a major overhaul of the autotools (recreating the Makefile.am and configure.ac from scratch), updating the m4 macros and the pkg-config dependencies, fixing the main source code and matching against the compiler and toolchain issues. You will, in effect, become the new upstream and you will be best off actually uploading the source code using your preferred RCS to somewhere public and making a release of the next version. Makefile.in without Makefile.am isn't much use. > I had a quick look in the Makefile and it has a line which says... > > AUTOMAKE = automake-1.6 > > Now I wondered if it would be a simple case of altering that line to > point to automake-1.10? NO. If this package depends on code unsupported since Sarge, it is a serious case of bitrot. I would estimate it would take me a significant amount of time (read months) to create a new upstream release from such a package. It would probably take a few weeks to even get something that compiles. Remember, Debian isn't known for rapid release cycles and you are looking at code that was out of date *before the PREVIOUS release* at a time when Debian is approaching the NEXT release. *That makes it a LONG, LONG time since the code was current* -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html