* Peter Rosin wrote on Thu, Sep 02, 2010 at 09:00:13AM CEST: > Den 2010-09-01 23:30 skrev Ralf Wildenhues: > >> * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin,mingw,pw32] > >> [cegcc]: Drop fix_srcfile_path. > > > > Please ask google codesearch whether fix_srcfile_path is used by third > > party packages which expect it to be set inside the configure script. > > In case of doubt, we should keep the setting of it for compat reasons. > > I used these search criteria: > fix_srcfile_path > -fix_srcfile_path= > -TAGVAR\(fix_srcfile_path,\ \$1\) > -TAGVAR\(\[fix_srcfile_path\],.*\) > -file:ltmain\.(m4sh|sh|in) > -file:ChangeLog > -file:\.texi > -file:libtool\.info > > And got it down to a screenfull, with one prospect for a hit - a fuse port > for osx (at least that's what I'm guessing it is). But it turns out that > it is just a patch that includes a diff for ltmain.sh. I guess it should > be mentioned in NEWS if it's removed.
Yes please. I'm fine with removal in that case. > However, I'm not desperate about this > patch as I'm saved by the compile script anyway. At least I think so? Maybe > we should just try to drop it and move all the new functions after > func_mode_compile as Chuck had them from the start? Strictly add-on optimization that should remain separate; but if you can show that it's sufficient, I'm fine with going that way. > Regardless, we could > move all the path functions down and only keep the file name functions > where they are if that proves to be beneficial for performance as only the > file name functions are needed above func_mode_compile (and by this patch > only). Again, I'm fine with this if it works and if moving the functions is done in a separate commit that does nothing else. > > The changes to archive_cmds that introduce func_to_tool_file will make > > it impossible (right?) for users to use that command inside a configure > > I suppose so. > > > test. I'm not sure whether that is a problem in practice -- we > > recommend using LT_OUTPUT and then using ./libtool, but a quick > > codesearch check shouldn't hurt. > > I got it down to a few dozen hits with these search terms: > archive_cmds > -archive_cmds(=|_need_lc) > -file:ltconfig > -file:ltmain.(m4sh|sh|in) > -file:libtool.info > -file:ChangeLog > -file:/libtool$ > -file:\.(html|texi|xml)$ > > And could not locate anything real there. Cool. Thanks for tracking all that down. > > 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. > It works just fine in the low max_cmd_len test though, which is kind > of funny behavior :-). Now why's that? > 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. Thanks, Ralf