Commit graph

9 commits

Author SHA1 Message Date
Gabriel C
656a3f7978 scripts/ver_linux use 'gcc -dumpversion'
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>
2008-05-25 23:02:43 +02:00
Jesper Juhl
cc9eefdb9e kbuild: scripts/ver_linux : correct printing of binutils version
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-12 21:15:31 +02:00
Jesper Juhl
9cc3ef3034 kbuild: ver_linux fix glibc version print
Fix ver_linux glibc version printing (for real this time)

Alexey Dobriyan reported that commit
4a645d5ea6
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-10-12 21:15:31 +02:00
Jesper Juhl
4a645d5ea6 kbuild: fix up printing of Linux C Library version in scripts/ver_linux
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>
2007-07-25 21:14:20 +02:00
Valdis Kletnieks
319e799abb [PATCH] ver_linux additions
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-12-07 08:39:38 -08:00
Alexey Dobriyan
ea88df9bf8 ver_linux: don't print reiser4progs version if none found
Sam: did the same for reiserprogs

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-04-05 13:10:19 +02:00
Alexey Dobriyan
580b2e3c01 [PATCH] Adapt scripts/ver_linux to new util-linux version strings
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-09-07 16:57:33 -07:00
Steven Cole
1694145854 [PATCH] 2.6.12-rc1-mm3 Fix ver_linux script for no udev utils.
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-18 21:57:33 -07:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00