We have received a bug report suggesting that the message "not a dynamic executable" should be printed to standard error instead of standard output, that is, change this: nonelf "$file" || { echo $" not a dynamic executable" result=1 } to: nonelf "$file" || { echo 2>&1 $" not a dynamic executable" result=1 } This is a breaking change because people use grep without redirecting standard error to search for this message.
(In reply to Florian Weimer from comment #0) > We have received a bug report suggesting that the message "not a dynamic > executable" should be printed to standard error instead of standard output, > that is, change this: > > nonelf "$file" || { > echo $" not a dynamic executable" > result=1 > } > > to: > > nonelf "$file" || { > echo 2>&1 $" not a dynamic executable" > result=1 > } > > This is a breaking change because people use grep without redirecting > standard error to search for this message. The question is one of perspective. Today the only true error messages today are those caused by improper use of ldd and the command line arguments. The message "not a dynamic executable" is not an error message, it is the output of the tool, and as such we output it to stdout. It is an inaccurate message, because there is no API between the loader and userspace to return more detailed errors like "I ran out of memory" ENOMEM during loading. The tool also has an exit code which is orthogonal to the messages printed and the exit code indicates if the tooling was able to accomplish the requested action. It returns 0 if it succeeded in the operation, or 1 if it did not succeed. There is no requirement that we print anything to stderr on failure. All you know is that ldd did not process the file for an unknown reason. Should a failure, exit status is non-zero, always print something to stderr? I think so. In which case I think under the auspices of returning better error messages to users we should: (a) Aim to make the message slightly more accurate with more return codes from the loader. (b) Always print something to stderr if we return non-zero exit status.
The master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=e7c8ffe4ec059da1523c093d6a240cd87d154df2 commit e7c8ffe4ec059da1523c093d6a240cd87d154df2 Author: Florian Weimer <fweimer@redhat.com> Date: Tue Oct 15 16:41:51 2019 +0200 ldd: Print "not a dynamic executable" on standard error [BZ #24150] Tested with the testsuite on x86_64-linux-gnu, and manually. Reviewed-By: Richard W.M. Jones <rjones@redhat.com>
Fixed in glibc 2.31.
I don't think this is a valid request. The line intentionally lines up with the normal output (note the leading tab) which goes to stdout, so the intent is to view this as a normal output, not as an error message.
But the current behavior isn't quite consistent. $ ldd /sbin/ldconfig ; echo $? statically linked 0 $ ldd /usr/bin/zgrep ; echo $? not a dynamic executable 1 The first message and exit status comes from the dynamic linker itself.
Of course, since the dynamic linker can only handle ELF files.
I don't think the exit status difference is obvious. If it's indeed an error, the message out to go to standard error. If it's not, then it matches the statically linked case.
All error messages are prefixed by "ldd: ". This message is not, thus it is obviously not an error message.
But if it is not an error, why is the exit status 1? The glibc 2.30 behavior is inconsistent.
Why is that a problem? It is obviously intented to give the callers a hint.
If a program fails it should print an error on stderr. (This is particularly important for libguestfs because we turn the stderr message into an API error, but applies in general). In this case (before Florian's change) ldd fails but doesn't print anything useful on stderr. Before you say it, it doesn't work to look at stdout, since there are plenty of programs which print tons of output on stdout before failing, and we want to identify just the error message to report back through the API.
But this is not an error message.
Invoking the tool to "print shared object dependencies" on the wrong file type, which then prints a message, and then exits with an error code is pretty much the definition of an error message, whether or not someone years ago forgot to prefix the error message with "ldd: ".
The message is formatted with a leading tab, which makes it unambigously clear that this is not an error message, but rather normal output.
(In reply to Andreas Schwab from comment #14) > The message is formatted with a leading tab, which makes it unambigously > clear that this is not an error message, but rather normal output. Andreas, What would you like to see changed? You reopened this bug, and we need to understand what you would like to see changed. If you want the patch reverted
(In reply to Carlos O'Donell from comment #15) > (In reply to Andreas Schwab from comment #14) > > The message is formatted with a leading tab, which makes it unambigously > > clear that this is not an error message, but rather normal output. > > Andreas, > > What would you like to see changed? You reopened this bug, and we need to > understand what you would like to see changed. If you want the patch reverted ... please ask for that.