[SCM] GNU Libtool branch, master, updated. v2.4.2.444-29-g5911665

2014-05-02 Thread Peter Rosin
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 5911665520a53415bafd8bb6da9989b5fe25df80 (commit) from

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

2014-05-02 Thread Peter Rosin
Follow-up Comment #1, sr #108558 (project libtool): Thanks for the report. Just a quick note, Cygwin is not affected. This happens on MSYS/MinGW only. On Cygwin, the Windows (or should I say DOS?) NUL device is never involved. cygwin$ /bin/nm -B /dev/null /bin/nm: Warning: '/dev/null' is not an

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

2014-05-02 Thread LRN
Follow-up Comment #2, sr #108558 (project libtool): I was not aware of the extent to which Cygwin is mangling commandlines of pure-W32 programs it runs (since i don't really use Cygwin; i do know it does some kind of conversion; apparently, only in one direction). Evidently, it does not replace

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

2014-05-02 Thread Peter Rosin
Follow-up Comment #3, sr #108558 (project libtool): Well, in MSYS2 you can simply do: nm -B /dev/thisfilebetternotexistotherwiseyoullbeintrouble and get satisfactory results (file name and 'No such file' in the output). Can't say anything about MSYS1, haven't used it for some time. That

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

2014-05-02 Thread Peter Rosin
Follow-up Comment #1, sr #108559 (project libtool): Isn't this a more direct approach, not affected by new and even more aggressive optimizations? -volatile const char * MAGIC_EXE = $magic_exe; +#if __GNUC__ 4 || (__GNUC__ == 4 __GNUC_MINOR__ 5) +# define externally_visible volatile +#else +#

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

2014-05-02 Thread LRN
Follow-up Comment #4, sr #108558 (project libtool): Well, in MSYS2 you can simply do: nm -B /dev/thisfilebetternotexistotherwiseyoullbeintrouble and get satisfactory results (file name and 'No such file' in the output). Can't say anything about MSYS1, haven't used it for some time. That

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

2014-05-02 Thread LRN
Follow-up Comment #2, sr #108559 (project libtool): Yeah, that worked ___ Reply to this item at: http://savannah.gnu.org/support/?108559 ___ Message sent via/by Savannah

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

2014-05-02 Thread Peter Rosin
Update of sr #108559 (project libtool): Status:None = Done ___ Follow-up Comment #3: I have now pushed this change, thanks for testing! Cheers, Peter

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

2014-05-02 Thread Peter Rosin
Follow-up Comment #5, sr #108558 (project libtool): Hmm, on second thought, that depends on MSYS (and MSYS2) still thinking that an argument starting with more than two slashes is a UNC path (or a switch). That might change if someone points out that ///foo and /foo should be equivalent and that

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

2014-05-02 Thread LRN
Follow-up Comment #6, sr #108558 (project libtool): Crap. How about just opening a file that is known to not to exist? Alternatively, give nm a real file that is at least 1 byte long (binutils nm checks for filesize being 1 and fails quietly; having 1 byte makes it say filename (which is

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

2014-05-02 Thread Peter Rosin
Follow-up Comment #7, sr #108558 (project libtool): Ok, something like this seems safer: mkdir conftest.dir case `$tmp_nm -B conftest.dir/nofile` in *conftest.dir/nofile*) blablabla esac rm -rf conftest.dir But I don't know how non-GNU nm behaves, so the safe-safe-safe version only does the

[sr #107959] Libtool generates invalid .def files

2014-05-02 Thread Peter Rosin
Update of sr #107959 (project libtool): Status:None = Done ___ Follow-up Comment #1: Fixed a while ago by commit a5a4944fbb2bbd20adb12b. Cheers, Peter