summaryrefslogtreecommitdiff
path: root/scripts/ver_linux
AgeCommit message (Collapse)AuthorFilesLines
2008-05-26scripts/ver_linux use 'gcc -dumpversion'Gabriel C1-4/+1
These magic greps and hacks in ver_linux to get the gcc version always break after some gcc releases. Since now gcc >4.3 allows compiling with '--with-pkgversion' ( which can be everything 'My Cool Gcc' or something ) ver_linux will report random junk for these. Simply use 'gcc -dumpversion' to get the gcc version which should always work. Signed-off-by: Gabriel C <nix.or.die@googlemail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-10-12kbuild: scripts/ver_linux : correct printing of binutils versionJesper Juhl1-3/+1
Currently scripts/ver_linux prints "Binutils" or other random information for the version number in the "binutils" output line on some distributions. This patch corrects that. When I initially submitted a patch to correct that, I was not aware that the output from "ld -v" could differ as much as it turned out it can, so my original fix turned out to not cover all bases. This patch works correctly with all the different "ld -v" output that people posted in replys to my first patch, so it should be a clear win over what we have currently. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-10-12kbuild: ver_linux fix glibc version printJesper Juhl1-3/+2
Fix ver_linux glibc version printing (for real this time) Alexey Dobriyan reported that commit 4a645d5ea65baaa5736bcb566673bf4a351b2ad8 broke ver_linux when glibc has a 3 digit version number, and proposed a patch. Al Viro then suggested a simpler way to solve the problem which I've then simply put into patch form. Signed-off-by: Alexey Dobriyan <adobriyan@sw.ru> Signed-off-by: Al Viro <viro@ftp.linux.org.uk> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2007-07-25kbuild: fix up printing of Linux C Library version in scripts/ver_linuxJesper Juhl1-2/+2
I noticed, when running scripts/ver_linux on both a Gentoo system and a Slackware system, that the line printing the C library version looked a little odd. So I fixed it up to be in line with all the rest. Old output: Linux C Library > libc.2.5 New output: Linux C Library 2.5 Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-12-07[PATCH] ver_linux additionsValdis Kletnieks1-0/+8
scripts/ver_linux needed some minor clean-ups, as follows: 1) Add reporting of actual oprofile release 2) Add reporting of actual wireless-tools release 3) Add reporting of actual pcmciautils release Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-05ver_linux: don't print reiser4progs version if none foundAlexey Dobriyan1-2/+2
Sam: did the same for reiserprogs Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2005-09-08[PATCH] Adapt scripts/ver_linux to new util-linux version stringsAlexey Dobriyan1-2/+4
Tested with 2.12i and 2.13-pre2. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-19[PATCH] 2.6.12-rc1-mm3 Fix ver_linux script for no udev utils.Steven Cole1-1/+1
Without the attached patch, the ver_linux script gives the following if udev utils are not present. ./scripts/ver_linux: line 90: udevinfo: command not found The patch causes ver_linux to be silent in the case of no udevinfo command. Signed-off-by: Steven Cole <elenstev@mesatop.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-17Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+95
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!