On 09/23/2011 05:23 PM, iggi wrote: > Yann, > > Thank you for the response, but it looks like they moved from CVS after that > date.
Erik moved from CVS to SVN around 2005, and then the git was cloned from the SVN, so the full history back to 2000 _is_ in the git archive. The reason the full _project_ history isn't in the archive is that the project goes back long before Erik, for gory details see: http://web.archive.org/web/200102051514/http://cvs.uclinux.org/uClibc.html (And yes, I hate the way thunderbird wraps links and that there's no obvious way to prevent it from doing that.) Unless I am missing something, I can't find way to get a tarball from > that time. Unfortunately, the really old versions predate uClibc and busybox having their own website, back when the release tarballs were on ftp://oss.lineo.com. The website is archived in the wayback machine, but the _ftp_ site wasn't. And lineo went under in the dotcom bust... That said, the version you're looking for _has_ to be in the git archive because if you go back to the beginning: git log | tail -n 1000 A couple of the early commits are: commit 7b9cd2baf91a1f7f0cd364758102cec4e0f9c2c1 Author: Erik Andersen <[email protected]> Date: Wed May 17 02:16:00 2000 +0000 More tests. Seems malloc isn't working... -Erik commit 9b7a1c1c4b4cbb1257b19caa92ccd9b765b1f01b Author: Erik Andersen <[email protected]> Date: Tue May 16 05:38:45 2000 +0000 Add in the "_start" symbol in asm. Fix a makefile (that needs to be abstracted I suppose for platforms (though I am doing fine w/o libcrt*) and add function prototype for exit into stdlib.h (it was missing... odd). Compiles vs uC-libc are less noisy now. -Erik commit d2d67c9856355f732c83f060e0c69b2e520db65e Author: Erik Andersen <[email protected]> Date: Mon May 15 22:10:56 2000 +0000 Finished porting stuff to x86 and supporting the Linux 2.2 kernels. It now compiles.... -Erik So if it works for you at ALL you're using something after that. (The first commit didn't even COMPILE, then it didn't _link_, and then malloc didn't work for quite some time while Erik checked in test cases...) Ooh, here's an interesting one: commit 38b20649403f2cbffc4581211f1b61868e3b358f Author: Eric Andersen <[email protected]> Date: Mon Jun 19 21:51:18 2000 +0000 Add in a version number so apps can tell uclib is being used. -Erik Let's see... git show 38b20649403f2cb is where the version numbers were first added (0.9.1), and that touched include/features.h so let's look at a log of _that_ file... commit 0ea968c3e603da9da9c8ae8f81382d105127ab2d Author: Eric Andersen <[email protected]> Date: Thu Dec 21 16:21:27 2000 +0000 Sync version number with Makefile And _that_ one sets it to 5, but implies that it got changed somewhere else first. So let's look at the _big_ log starting from that commit... I really, really, really hate git. "Show a file at a revision" should not be esoteric knowlege. (What's git's equivalent of "hg cat -r revision? It's not _quite_ "git show 0ea968c3e603da9 -- Makefile" because that just shows me the CHANGE to that one file. Oh well, "annotate" is overkill but shows me the darn data... and Makefile has no version stamp? Huh? Ok, "mkdir sub; git archive 0ea968c3e603da9 | tar xC sub" and... doesn't seem to be in Rules.mak either? Or in any of the subdir Makefiles) What on _earth_ was Erik talking aboutin the commit message then? Let's see, $ make help Rules.mak:25: Config: No such file or directory make: *** No rule to make target `Config'. Stop. Beautiful. The version number was probably in a Config file that wasn't checked in... Ah, and note this commit in 2002: 58bd16ab173a4df7b -/* Major and minor version number of the uClibc library package. Use - these macros to test for features in specific releases. */ -#define __UCLIBC__ 0 -#define __UCLIBC_MAJOR__ 9 -#define __UCLIBC_MINOR__ 5 +/* This macro indicates that the installed library is uClibc. Use + * __UCLIBC_MAJOR__ and __UCLIBC_MINOR__ to test for the features in + * specific releases. */ +#define __UCLIBC__ 1 + +/* Major and minor version number of the uClibc library package are + * can be used to test for features in specific uClibc releases. + * + * Now included from bits/uClibc_config.h */ +#if 0 +/* For uClibc release 0.9.12, these numbers would be: */ +#define __UCLIBC_MAJOR__ 0 +#define __UCLIBC_MINOR__ 9 +#define __UCLIBC_SUBLEVEL__ 12 +#endif So yeah, versions 5-11 all identified themselves as 5. (Are you sure you actually _have_ 5?) But _that_ was also identifying MINOR_VERSION in Rules.mak, so let's trace back the changes to that line with a lot of "git annotate $VERSION^1 -- Rules.mak" and... git annotate aa6ece75^1 -- Rules.mak | grep MINOR 8f2286fd (Eric Andersen 2001-04-27 07:09:41 +0000 28)MINOR_VERSION=9.5 So uClibc started identifying itself as version 9.5 in Rules.mak with commit 8f2286fd, and stopped with commit aa6ece75. I note that BEFORE it was minor 9.5 it was minor "95", so apparently ".5" covered a long range of stuff and there's no way to know if you're using a random CVS snapshot or what. Honestly, dude: 10 year old version of early development software and you didn't save your source. The version you want IS in the source control repo somewhere (unless they applied local patches: is your binary vanilla?) but tracking it down is nontrivial, and This is why we make all this fuss about source code to the point I write RANTS about it: http://busybox.net/license.html At this point you either have to do a lot of forensic work identifying what the heck you have, or else pay a consultant to do it, or else rip it out and replace it with something maintainable. Have you thought about static linking? Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
