Matthias Juchem wrote:
> BTW, lots of version dependencies found in older Changes document (i.e.
> for 2.3.11) were removed now (2.4.0 shows only 9 where the old one had
> 22). Have the removed ones been completely unnecessary?
Quoting from 2.4.0's Changes file:
[snip]
> trying life on the Bleedi
On 7 Jan 2001, Ulrich Drepper wrote:
> Why don't you, as the other script suggested, execute libc.so.6?
> Symlinks can be missing or can be wrong.
I'll have a look at this shell script and take the best out of both to
make a new one.
BTW, lots of version dependencies found in older Changes docu
Keith Owens <[EMAIL PROTECTED]> writes:
> 5)
> # glibc versions. Take the last symbolic link,
> # extract the version number from the file it points to.
> if [ `expr "X$1" : 'Xl'` -eq 2 ]
> then
On Sun, 07 Jan 2001 06:43:14 -0800,
David Ford <[EMAIL PROTECTED]> wrote:
>Matthias Juchem wrote:
>> My script is intended for the one who likes to provide bug reports but is
>> too lazy to look up all the information or simply is not sure about what
>> to include.
>
>Why can't it be done in sh?
Alan Cox writes:
> > ./arch/arm/lib/extractconstants.pl
>
> None of these are needed for normal build/use/bug reporting work. In fact
> if you look at script_asm you'll see we go to great pains to ship prebuilt
> files too
Whoops. ;(
I've already got a fix for this one though using grep and sed
On Sun, 7 Jan 2001, David Ford wrote:
> > Why can't I assume that perl is installed? It can be found on every
> > standard Linux/Unix installation.
>
> No it can't. Perl isn't on any of my distributions as part of the standard
> installation.
Ok, I was wrong. I'm used to perl, I've seen perl on
Matthias Juchem wrote:
> Why can't I assume that perl is installed? It can be found on every
> standard Linux/Unix installation.
No it can't. Perl isn't on any of my distributions as part of the standard
installation.
> My script is intended for the one who likes to provide bug reports but is
On Sun, 7 Jan 2001, Alan Cox wrote:
> None of these are needed for normal build/use/bug reporting work. In fact
> if you look at script_asm you'll see we go to great pains to ship prebuilt
> files too
Well, DocBook documentation isn't need for normal builds either and has
jade as dependency - so
> ./drivers/scsi/script_asm.pl
> ./drivers/usb/serial/ezusb_convert.pl
> ./arch/ppc/treeboot/elf.pl
> ./arch/arm/lib/extractconstants.pl
> ./scripts/checkconfig.pl
> ./scripts/checkhelp.pl
> ./scripts/checkincludes.pl
None of these are needed for normal build/use/bug reporting work. In fact
if yo
On Sun, 7 Jan 2001, Alan Cox wrote:
> The kernel doesnt require perl. I don't want to add a dependancy on perl
Well, I wouldn't be a dependancy as you do not have to use it. Why not add
it as an option. I guess most of the installations have a perl
interpreter.
BTW:
# find . -name \*.pl
./drive
> This is a patch against 2.4.0. It introduces a new bug reporting script
> (scripts/bugreport.pl) that tries to simplify bug reporting for users. I
> have also added a small hint to this script to REPORTING-BUGS.
The kernel doesnt require perl. I don't want to add a dependancy on perl
-
To unsub
On Sun, 7 Jan 2001, Paul Gortmaker wrote:
> BTW, people have a nasty habit of tacking their entire .config file
> onto bug reports to linux-kernel. Can you mention "grep ^C .config"
> somewhere in there (or have the script do it) since the number of
> config options isn't going to decrease anyti
Ulrich Drepper wrote:
>
> Matthias Juchem <[EMAIL PROTECTED]> writes:
>
> > Or is the file name scheme reliable (/lib/libc.so.5.x.y)?
>
> Yes, since this was how HJ named the releases. You have to find out
> which version is actually used (there might be several .so files
> there).
Can also d
Hi there,
what do you think of this fragment ?
to me, it looks sort of large, but I wanted to cover all cases..
i'm going to optimize it a little bit.
$v_libc5 = '';
$v_libc6 = '';
# first, find the path of the concerning lib with the highest version
if ( exists_prog("ldconfig"
On Sun, 7 Jan 2001, Matthias Juchem wrote:
> I guess if you use a development version the above returns nothing. If I'm
> right, a pre-release libc was recommended for use with 2.2.0 (I'm not
> sure).
Here is a random idea.
get the pathname of the library(ies) then this sed expression:
sed \
'
On Sun, Jan 07, 2001 at 08:43:12PM +1100, Brett wrote:
>
> Taking a guess here
>
> strings /lib/libc* | grep "release version"
>
> I'm not sure how reliable this method is either :)
That returns nothing here.
I do find this in it:
"@(#) The Linux C library 5.4.46"
Kurt
-
To unsubscribe
On Sun, 7 Jan 2001, Brett wrote:
> Taking a guess here
>
> strings /lib/libc* | grep "release version"
>
> I'm not sure how reliable this method is either :)
>
I guess if you use a development version the above returns nothing. If I'm
right, a pre-release libc was recommended for use with 2.
On Sun, 7 Jan 2001, Matthias Juchem wrote:
> On 6 Jan 2001, Ulrich Drepper wrote:
>
> > This is wrong. You cannot execute libc.so.5. This only works with
> > glibc.
>
> I already thought of something like that (I was not able to test it...).
> Can you tell me a reliable way to get the version
On 7 Jan 2001, Ulrich Drepper wrote:
> have libc5 out of the way in a separate subdir. Your best bet is to
> use ldconfig:
>
> /sbin/ldconfig -p|grep libc.so.5
>
Hmm, ok. Well, I was reading the Changes document when doing this first
and did not use my head. This document advises to deduct th
Matthias Juchem <[EMAIL PROTECTED]> writes:
> # c library 5
> -if ( -e "/lib/libc.so.5" ) {
> - ( $v_libc5 = `/lib/libc.so.5`) =~ m/GNU C Library .+ version (\S+),/;
> - $v_libc5 = $1;
> -} else {
> - $v_libc5 = "not found";
> +opendir LIBDIR, "/lib" or die "/lib/ not
Hi Alan.
My previous patch contained a few bugs (i.e. libc5 was not found). Here is
a patch that depends on the previous one.
Regards,
Matthias
On 6 Jan 2001, Ulrich Drepper wrote:
> This is wrong. You cannot execute libc.so.5.
[..]
--- scripts/bugreport.pl.orig Sun Jan 7 09:57:42 2001
+
Matthias Juchem <[EMAIL PROTECTED]> writes:
> Or is the file name scheme reliable (/lib/libc.so.5.x.y)?
Yes, since this was how HJ named the releases. You have to find out
which version is actually used (there might be several .so files
there).
--
---. ,-.
On 6 Jan 2001, Ulrich Drepper wrote:
> This is wrong. You cannot execute libc.so.5. This only works with
> glibc.
I already thought of something like that (I was not able to test it...).
Can you tell me a reliable way to get the version other than just looking
for the version appended to the f
Matthias Juchem <[EMAIL PROTECTED]> writes:
> +# c library 5
> +if ( -e "/lib/libc.so.5" ) {
> + ( $v_libc5 = `/lib/libc.so.5`) =~ m/GNU C Library .+ version (\S+),/;
> + $v_libc5 = $1;
> +} else {
> + $v_libc5 = "not found";
> +}
This is wrong. You cannot execute li
Hi Alan,
could you please consider this patch for inclusion in your tree?
This is a patch against 2.4.0. It introduces a new bug reporting script
(scripts/bugreport.pl) that tries to simplify bug reporting for users. I
have also added a small hint to this script to REPORTING-BUGS.
To all: Pleas
25 matches
Mail list logo
