On 8/26/2010 2:26 AM, Peter Rosin wrote: > This is my current queue of libtool patches. They need more work. > In particular, I don't know if 0008-Slashify-instead-of-backslashify > is even remotely acceptable. The subject has been up before and I > think Chuck had some issue with it, but don't remember what. I Can do > some searching in my mailbox if that's important...
It was actually Roumen Petrov: http://lists.gnu.org/archive/html/bug-libtool/2008-04/msg00167.html Our discussion was here: http://lists.gnu.org/archive/html/libtool-patches/2009-02/msg00008.html and referenced Roumen's post. However, that was 2.5 years ago, so we may need to just try Roumen's test case again, on modern linux + modern WINE, and see if the problem still occurs. It would be nice to avoid '\'. And I just noticed that I never DID fix that "-m" vs "-d" issue when invoking cygpath, so cygwin->mingw gets you "C:/foo", but unix->mingw does "C:\\foo". > Further, my patches regresses library searching, I think due to paths > being converted from posix form to win32 form too early and then > something fails to find dependent libraries. Possibly other problems > too? > > Perhaps most interesting are the patches > 0002-Add-path-conversion-from-build-to-toolchain > 0005-Convert-file-names-to-toolchain-format-in-NM-and-AR > which *should* fix stresstest.at on MSYS (not confirmed, due to the above > problems). If we can verify that Roumen's reported issue no longer occurs, then I'd fast-track 0008, 0002, 0003, and 0005 (presuming they can be applied independently of the others, and no regressions). Of course, you'd have to practically rewrite 0002 given the new nomenclature: lt_cv_to_tool_path_cmd -> lt_cv_to_tool_file_cmd to_tool_path_cmd -> to_tool_file_cmd don't use eval in func_to_tool_path() -- which should be named func_to_tool_file{_name?}() etc etc etc If Roumen's report is still an issue, then we might have to work a little harder. Maybe accept the fork penalty? I'll try to look into that tomorrow. -- Chuck
