>>> "Chuck" == Charles Wilson <[EMAIL PROTECTED]> writes:
Chuck> There has been a long-standing problem with libtool on windows-ish Chuck> platforms (cygwin, mingw, others?), in which libtool relinks exe's Chuck> over and over and over, when the exe depends on a shared lib that is Chuck> also built as part of the same package. Chuck> This behavior is due to the necessity that we must use a wrapper Chuck> script to set the PATH properly, so that the newly compiled exe can Chuck> "find" its shared lib, when run "in place" -- e.g. as part of a Chuck> test-suite. Thus, we have Chuck> <build-dir>/foo (wrapper script) Chuck> <build-dir>/.libs/foo.exe (real exe) Chuck> However, the Makefile target is "foo$(EXEEXT)" -- which Chuck> isn't satisfied by the "foo" wrapper script, so 'make' Chuck> keeps trying to create it. Maybe I'm wrong, but my understanding is that wrapper scripts are generated only when linking programs with uninstalled shared libraries. For instance wrapper scripts aren't created when the user uses --disable-shared, or simply if some program in the package doesn't link with shared libraries. In these cases reseting EXEEXT globally doesn't look like a solution (I guess it would just create the converse issue: the `foo:' target not satisfied by `foo.exe'). In the current situation I don't think there is any way to find out whether a Makefile target needs `.exe' appended. Chuck> However, the wrapper script can NOT be named "foo.exe", Chuck> for a number of good reasons. I assume these reasons are related to the word `script'? Have binaries been considered? [...] -- Alexandre Duret-Lutz -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
