Den 2010-09-05 23:29 skrev Ralf Wildenhues: > * Peter Rosin wrote on Sun, Sep 05, 2010 at 10:02:11PM CEST: >> Subject: [PATCH 6/7] Convert file name to toolchain format when invoking $NM. >> >> * libltdl/config/ltmain.m4sh (func_generate_dlsyms) >> (func_win32_libid, func_cygming_gnu_implib_p) >> (func_cygming_ms_implib_p): When using the name lister to find >> symbols in files, convert the file names to a format appropriate >> for the tool. > > You're gonna hate me for this, I already know, but: does this patch fix > testsuite failures, are all code paths covered? If not, we need to > improve the test suite. If yes, please mention them in the log, thanks.
Those in func_cygming_gnu_implib_p and func_cygming_ms_implib_p appear to be dead code. Both functions are only called from func_cygming_dll_for_implib_fallback which only use is that it is assigned to the cache variable lt_cv_sharedlib_from_linklib_cmd whose value is in turn only assigned to the LT_DECL variable sharedlib_from_linklib_cmd, which is not used anywhere according to my searching. Pending patches from Chuck perhaps? I'm probably missing something obvious. Anyway, as I don't even know how to trigger the code paths, I have no idea how to write a test... The one in func_win32_libid is triggered on MinGW $hosts that have both binutils nm (i.e. not dumpbin -symbols) and file(1). It is also a requirement that to_tool_file_cmd is needed, so it should be visible using the native MinGW tools in a cygwin->mingw cross. Will try to see if anything shows up in the testsuite. Of the four instances in func_generate_dlsyms, the last one is nasty to trigger. We would need a setup that needs func_to_tool_file, where $host isn't Windowsy. Good luck with that... The first is used when extracting preloading symbols from the program itdelf, the second when extracting preloading symbols from implibs and the third when extracting preloading symbols from static libs. *time passes* *time passes* I have now tried for quite a bit to trigger this in the testsuite and results are bleak. This stuff is masked behind other failures, which makes it no fun at all to even try to build or extend test cases. However, we must start somewhere and anybody trying to fix the other failures will probably have face similar problems that I'm now facing. It's very hard to go forward with something when too much is borked. What I have found is that (at least) test 73 (lt_dladvise.at) depends on the third instance in func_generate_dlsyms. So, I could add on to that test and "install" libpreload.la and then link using an absolute path. I think. Or perhaps create a new test zeroing in on this specific feature. *doing other things* *time passes* To me, it is obvious that all these $NM calls needs fixing. Does anyone have any off-the-top-of-your-head input on in what circumstances the code in question is running? Cheers, Peter
