[CLN-list] CLN vs weird mixture of Cygwin and MinGW [Was: Results of building cln-1.1.13 ...]

[Richard Haney]

Hi Alexei and others who may wish to comment,

--- Sheplyakov Alexei <varg at 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