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

[LRN]

URL:
  

 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:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool

[sr #108559] libtool binary wrappers fall prey to aggressive optimizations

[LRN]

URL:
  

 Summary: libtool binary wrappers fall prey to aggressive
optimizations
 Project: GNU Libtool
Submitted by: lrn
Submitted on: Fri 02 May 2014 05:16:44 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: None

___

Details:

When building binary wrappers (say, for W32), libtool puts a MAGIC constant
string into them. Later on libtool greps the program for this string to see
whether this is a wrapper or a real program.

However, MAGIC string is not used in the program in any way, and gcc may
remove it. This does happen when building with -flto.

My proposal would be to make use of the string somehow to fool gcc into
leaving it alone. For example, this call:

   lt_fatal (__FILE__, __LINE__,
"unrecognized %s option: '%s'",
ltwrapper_option_prefix, argv[i]);

can be changed like this:

   lt_fatal (__FILE__, __LINE__,
"unrecognized %s option: '%s'\0%s",
ltwrapper_option_prefix, argv[i], MAGIC_EXE);





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
https://lists.gnu.org/mailman/listinfo/libtool