[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sr #108558] libtool nm test does not really work for W32 versions of nm

From: LRN
Subject: [sr #108558] libtool nm test does not really work for W32 versions of nm
Date: Fri, 02 May 2014 05:10:06 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0


                 Summary: libtool nm test does not really work for W32
versions of nm
                 Project: GNU Libtool
            Submitted by: lrn
            Submitted on: Fri 02 May 2014 05:10:04 AM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: Microsoft Windows



libtool.m4 contains the following code:

        # Check to see if the nm accepts a BSD-compat flag.
        # Adding the 'sed 1q' prevents false positives on HP-UX, which says:
        #   nm: unknown option "B" ignored
        # Tru64's nm complains that /dev/null is an invalid object file
        case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
        */dev/null* | *'Invalid file or object type'*)
          lt_cv_path_NM="$tmp_nm -B"
          break 2
          case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
            lt_cv_path_NM="$tmp_nm -p"
            break 2
            lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
            continue # so that we can try to find one that supports BSD flags

This does not work if `nm' in question is built for W32, because `/dev/null'
gets mangled into `nul', and `nul' does not behave the same way (it can be
stat()'ed successfully and looks like a zero-size file to stat()).
Even if binutils are patched to do a more thorough check (for example, stricmp
(file_name, "nul") or && isatty(open (file_name, ...))), the file name
reported in the error message is `nul', not `/dev/null', so the case statement
here won't match.

AFAIU, this bug is as old as this code (which, i guess, makes it quite old),
but it was masked by the fact that /usr/bin/nm (MSYS/Cygwin nm) does pass this
test, and it's sufficiently compatible (for the purpose of parsing object
files) for this not to matter.

Things start to blow up when MinGW nm and MSYS/Cygwin nm are not completely
compatible (for example, when MinGW binutils and gcc are built with LTO
support, and MSYS/Cygwin binutils&gcc are not).


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]