Hi Alexei and others who may wish to comment, --- Sheplyakov Alexei <varg@theor.jinr.ru> wrote:

If you insist on using Cygwin+MinGW, you need at least to

1) give the configure script proper --build and --host arguments, e.g.,

--build=i586-mingw32msvc --host=i586-mingw32msvc

I guess I really need to ask a question explicitly, rather than simply leaving the question implicit from my two messages ( http://www.cebix.net/pipermail/cln-list/2006-August/000228.html and http://www.cebix.net/pipermail/cln-list/2006-August/000229.html ). It _seems_ to me, based on my (admittedly limited) knowledge and on "grep"ing directories and exploring files as described in my first of the two messages, that

--build=i586-mingw32msvc --host=i586-mingw32msvc

is incorrect because: (1) my processor is a Celeron processor, which seems to mean that the first part of the system type should be "i686" and not "i586" (as explained in my first of the two messages), and (2) because there is no meaningful occurrence of the string "msvc" in "C:/gnu/cln-1.1.13" or in "C:/gnu/cln-1.1.13/autoconf", which fact _seems_ to suggest that the second part of the system type should definitely not be the "mingw32msvc" that was suggested above. Moreover, $ uname --help [...] -s, --kernel-name print the kernel name [...] seems to suggest that "uname -s = CYGWIN_NT-5.1" in the config.log gives the best available idea of what should be considered the "kernel". So it _seems_ (to me, based on my admittedly limited knowledge) that the result from the configure output checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin is the best possible information. I don't really know what the build process does with this information. But it seems to me that the fact that gcc and its associated tools (as, ld, ... ) are MinGW tools (which, as I understand it, means that they and their output, where applicable, link directly to the Windows system DLLs rather than to cygwin1.dll) should be of no real concern to the build process. So this suggests that there should be no need for information such as "mingw32" in the build process (specifically the scripts). Moreover, by comparing script names and other executable names in the two directories "C:/cygwin/bin" (the bin for cygwin executables) and "C:/Dev-Cpp/bin" (the bin for MinGW tools), the only potential conflict I found was the existence of two different versions of "rm.exe". So it seems that putting "C:/cygwin/bin" first in PATH was an appropriate arrangement in order for configure to use the cygwin version (of rm.exe), which deletes symlinks properly. (The alternative arrangement would have led to using RM=... explicitly on the configure command line or simply removing or renaming the rm.exe in "C:/Dev-Cpp/bin".) So my questions are these: Are my best guesses as described here mistaken? And if so, where are they mistaken? If using

--build=i586-mingw32msvc --host=i586-mingw32msvc

on the configure command line really is a better practice, why? Also, does the description "weird mixture of Cygwin and MinGW" merely reflect that the author is simply unfamiliar with this use of Cygwin and MinGW? Or is there some other matter in this regard that I should consider? BTW, I think I have seen the use of Cygwin and MinGW tools in this way described, perhaps even by MinGW FAQ files, as something that seemed to be considered a "normal" option for development and porting. The alternative to cygwin bash (and its associated unix-style utilities), namely MinGW's msys system (including msys bash), originally seems to have been provided, not because of any real technical need or usefulness, but rather for the sake of completeness and project independence from cygwin. For those interested, note that I have described my reasons for using cygwin rather than msys in my message http://www.cebix.net/pipermail/cln-list/2006-August/000221.html . Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com