[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 |
URL:
<http://savannah.gnu.org/support/?108558>
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
_______________________________________________________
Details:
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
*/dev/null*)
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
;;
esac
;;
esac
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:
<http://savannah.gnu.org/support/?108558>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [sr #108558] libtool nm test does not really work for W32 versions of nm,
LRN <=
- [sr #108558] libtool nm test does not really work for W32 versions of nm, Peter Rosin, 2014/05/02
- [sr #108558] libtool nm test does not really work for W32 versions of nm, LRN, 2014/05/02
- [sr #108558] libtool nm test does not really work for W32 versions of nm, Peter Rosin, 2014/05/02
- [sr #108558] libtool nm test does not really work for W32 versions of nm, LRN, 2014/05/02
- [sr #108558] libtool nm test does not really work for W32 versions of nm, Peter Rosin, 2014/05/02
- [sr #108558] libtool nm test does not really work for W32 versions of nm, LRN, 2014/05/02
- [sr #108558] libtool nm test does not really work for W32 versions of nm, Peter Rosin, 2014/05/02
- [sr #108558] libtool nm test does not really work for W32 versions of nm, Peter Rosin, 2014/05/06
- [sr #108558] libtool nm test does not really work for W32 versions of nm, LRN, 2014/05/06
- [sr #108558] libtool nm test does not really work for W32 versions of nm, Peter Rosin, 2014/05/09