[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 /d

[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. Tha

[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 +#el

[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

[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: ___ Message sent via/by Savannah http://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 P

[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 wh

[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 ab

[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 ___