This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: Misleading info given by glibcbug
- To: Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
- Subject: Re: Misleading info given by glibcbug
- From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
- Date: 27 Sep 1998 15:44:20 +0200
- Cc: libc-alpha@cygnus.com
- Mail-Copies-To: never
- References: <199809270125.VAA05725@sleipnir.valparaiso.cl>
>>>>> Horst von Brand writes:
>> Submitter-Id: net
>> Originator: Horst von Brand
>> Organization:
> Horst von Brand vonbrand@sleipnir.valparaiso.cl
> Casilla 9G, Viņa del Mar, Chile +56 32 672616
>>
>> Confidential: no
>> Synopsis: glibcbug returns the environment when _run_, not _built_
>> Severity: non-critical
>> Priority: low
>> Category: libc
>> Class: support
>> Release: libc-2.0.95
>> Environment:
> Host type: i586-pc-linux-gnu
> System: Linux sleipnir 2.1.123 #6 Wed Sep 23 21:07:17 CLT 1998 i586 unknown
> Architecture: i586
> Addons: crypt linuxthreads
> Build CFLAGS: -O2 -march=pentium
> Build CC: gcc
> Compiler version: egcs-2.92.11 19980921 (gcc2 ss-980609 experimental)
> Kernel headers: 2.1.123
> Symbol versioning: yes
> Build static: yes
> Build shared: yes
> Build pic-default: no
> Build profile: yes
> Build omitfp: yes
> Build bounded: no
> Build static-nss: no
> Stdio: libio
>> Description:
> The above environment information is all wrong: I didn't build
> glibc-2.0.95 just now, but when it came out :-)
What is wrong? Compiler version, kernel headers, system, architecture
and machine are wrong (from glibcbug runtime not from configure time)
- but the rest should be ok. Or did I miss something?
>> How-To-Repeat:
> run glibcbug
>> Fix:
> I'd suggest to squirrel away the information given when building,
> and save as, e.g. $(exec_prefix)/glibcbug-$(version), and make
> $(exec_prefix)/glibcbug a symlink to this one. For linux (and other)
> experimental systems it might also be worthwile to state the
> environment when run.
It might be possible to add compiler version, kernel headers and uname
at configure time - and additionally uname and compiler version at
glibcbug run time.
Anybody volunteering to enhance glibcbug?
Do you really think using glibcbug-$(version) will help? I don't see
the necessity for it.
Andreas
--
Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de