Jim Meyering wrote on 2009-08-25: > No. That package *does* use the error module. > However, per m4/error.m4, when building on a glibc-based system, > error.c is not compiled. > > Your addition to this comment made it misleading: > > /* On glibc systems, when the gnulib module 'error' is not used, the error() > function comes from libc and uses the variable program_invocation_name, > not program_name. So set this variable as well. */ > > I suggest removing the "when the gnulib module..." clause: > > /* On glibc systems, the error() function comes from libc and > uses the variable program_invocation_name, not program_name. > So set this variable as well. */
You're right. I'm fixing the comment. 2009-10-04 Bruno Haible <[email protected]> * lib/progname.c (set_program_name): Fix comment. Reported by Jim Meyering. --- lib/progname.c.orig 2009-10-04 12:03:56.000000000 +0200 +++ lib/progname.c 2009-10-04 12:03:38.000000000 +0200 @@ -62,9 +62,9 @@ program_name = argv0; - /* On glibc systems, when the gnulib module 'error' is not used, the error() - function comes from libc and uses the variable program_invocation_name, - not program_name. So set this variable as well. */ + /* On glibc systems, the error() function comes from libc and uses the + variable program_invocation_name, not program_name. So set this variable + as well. */ #if HAVE_DECL_PROGRAM_INVOCATION_NAME program_invocation_name = (char *) argv0; #endif Sergey Poznyakoff wrote: > In my opinion, that's not correct. Libc (and gnulib's argp, FWIW) uses > two variables: program_invocation_name, which points to the full program > name as obtained from argv[0], and program_invocation_short_name, which > points to the program name with all leading directories removed. So, > set_program_name should set program_invocation_name to arg0, and > program_invocation_short_name to part of arg0 after the last directory > separator. The purpose of the assignments in progname.c is to make the libtool artefacts disappear. Jim's patch does the right thing for program_invocation_name, which is the variable that error() uses. But you are right mentioning program_invocation_short_name. It too needs to be modified, to remove libtool artefacts. I'm applying this: 2009-10-04 Bruno Haible <[email protected]> * lib/progname.c (set_program_name): Also remove the "lt-" prefix from program_invocation_short_name. * modules/progname (configure.ac): Test for presence of program_invocation_short_name. Reported by Sergey Poznyakoff <[email protected]>. --- lib/progname.c.orig 2009-10-04 12:12:28.000000000 +0200 +++ lib/progname.c 2009-10-04 12:11:09.000000000 +0200 @@ -48,7 +48,14 @@ { argv0 = base; if (strncmp (base, "lt-", 3) == 0) - argv0 = base + 3; + { + argv0 = base + 3; + /* On glibc systems, remove the "lt-" prefix from the variable + program_invocation_short_name. */ +#if HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME + program_invocation_short_name = (char *) argv0; +#endif + } } /* But don't strip off a leading <dirname>/ in general, because when the user --- modules/progname.orig 2009-10-04 12:12:28.000000000 +0200 +++ modules/progname 2009-10-04 12:11:33.000000000 +0200 @@ -9,6 +9,7 @@ configure.ac: AC_CHECK_DECLS([program_invocation_name], [], [], [#include <errno.h>]) +AC_CHECK_DECLS([program_invocation_short_name], [], [], [#include <errno.h>]) Makefile.am: lib_SOURCES += progname.h progname.c Jim Meyering wrote: > in order to make diagnostics appear like > > program_name: .... > > rather than > > /abs/dir.../.libs/lt-program_name: .... > > the set_program_name function must update program_invocation_name. Yes. > Unfortunately, when using libtool, and looking solely at argv, we cannot > derive the true command invocation name, so we cannot determine whether > the tool was invoked via ../../usr/bin/program, /usr/bin/program, or > simply "program". When installed in /usr/bin, the program does not have a libtool wrapper script. The typical situation is in build trees: The test suite invokes program or ./program or ../src/program, and the program's argv[0] becomes /abs/dir.../.libs/lt-program. Bruno
