Den 2010-09-02 20:39 skrev Ralf Wildenhues: > * Peter Rosin wrote on Thu, Sep 02, 2010 at 09:00:13AM CEST: >> Den 2010-09-01 23:30 skrev Ralf Wildenhues: >>> I haven't looked at the patch series in detail yet, but 1-6 look fairly >>> reasonable otherwise. 7 looks risky because of the logic around there; >>> also, the nm @file test isn't a real feature test. Also, I just noticed >>> that nm_file_list_spec isn't always initialized properly. >> >> Without 7/7, you get into trouble when using MSVC from Cygwin with >> absolute file names, since $NM (i.e. "dumpbin -symbols") will not find >> any symbols due to not being able to locate the requested file >> (i.e. /some/cygwin/file-name.obj instead of C:/cygwin/some/cygwin/...) > > Oh, I didn't mean to shoot down 7/7, I meant that 7/7 is the patch that > I would like to look at in more detail before deciding. The patch will > change the ltmain execution path on several systems.
I'm just saying that my priorities are: 1. GNU 2. MSVC on MSYS 3. MSVC on Cygwin Others may swap 2 and 3, but it is hard to make a case for demoting GNU from the top spot. Anyway, in the beginning of this patch series there are fixes for GNU, in the middle there are fixes for MSVC, but 7/7 is only needed for (my) priority 3. All I'm saying is that while 7/7 is nice, it isn't top priority. I'm fine with waiting a bit with it if you need more time to digest it. >> It works just fine in the low max_cmd_len test though, which is kind >> of funny behavior :-). > > Now why's that? Because with low max_cmd_len you always take the (working) @file branch when extracting symbols. >> When using MSVC on MSYS you don't need 7/7, since you're saved by the >> MSYS file name conversion on the command line. > > Ah, ok. Cheers, Peter