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

[Richard Haney]

--- Sheplyakov Alexei <varg at theor.jinr.ru> wrote:

[...]
> On Sun, Aug 13, 2006 at 07:42:59PM -0700, Richard Haney wrote:
> > [...]
[...]
> On my Duron 800 with 512Mb RAM (running Debian GNU/Linux sid) running
> GiNaC configure script takes about 1 minute. On ReactOS it is indeed 
> somewhat slower, but it is not *that* slow.

Thanks, that's good to know.

> > uname -s = CYGWIN_NT-5.1
> 
> You are trying to make win32 libraries with a mix of Cygwin and MinGW
> tools. While it is certainly possible build win32 libraries/binaries
> with such a setup, it is a little bit tricky, [...]

Among the executables (".exe"s as well as scripts) in /bin and in
/cygdrive/c/Dev-Cpp/bin , the only ones that could clash are the two
versions of rm.exe that I mentioned.  The /usr/bin and /usr/local/bin
directories are not used.  It seems that for a build only the MinGW
tools (in /cygdrive/c/Dev-Cpp/bin ) are concerned with interpreting the
contents of files (apart from whatever goes on in the interpretation of
link files).  I chose to re-order those directories in PATH because of
the conflict with versions of rm.exe , but I could have done instead an
override of, say, RM="C:/cygwin/bin/rm.exe" on the configure command
line.

> [...] so I suggest you to use
> MSYS.
> BTW, running shell scripts with MSYS is *much* faster.

Thanks, that's good to know.  I've been using cygwin because

1) (originally) msys seemed to have a bug in regard to setting the size
defaults for the script window.

2) (later) I became used to using cygwin and was concerned that my
experience (implicit knowledge) about cygwin would not carry over very
easily or entirely to msys -- especially in regard pathnames
conventions.

3) (most recently in regard to grep) I have subsequently learned that
cygwin seems to have distinctly better tools -- at least in regard to
grep -- and a larger variety of tools, whereas msys _seems_ to be a bit
limited.

So, I'm wondering about what bugs/limitations may be lurking in msys,
which I have not tried much.

> 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

So why not i686 in place of i586 , since configure seems to think my
computer is a i686 (whatever that is, precisely)?  Also, the "msvc"
seems to stand for "Microsoft Visual C/C++", or does that refer to a
Microsoft DLL with the same string "msvc" in its name?

Are there only a limited list of possible values for --build=... and
--host=... ?  Where are they defined (and/or described in
human-readable form)?

> 
> 2) make sure that directories with MinGW tools listed first in your
> $PATH,
>    which is not the case with your setup:

See comment above in regard to possible "clashes" between the
directories, including "rm.exe".

> > Hopefully, the config.log file will also help in determining why
> > the default value for the Makefile INSTALL variable

> There is no such a default. The value of this variable is determined
> by the configure script, which is basically searches for required
> program in your $PATH.

By "default value" I meant the value that is set in the Makefiles in
the absence of an override set on the configure command line.

> > causes a crash in the doc directory for "make install".
> I think it is either Cygwin bug or just your setup is horribly
> broken.

Yes, this is very much a puzzle still.  It seems to me that a few years
ago I tried copying a failing command line from make output and
inserting that line directly in the cygwin bash shell and then the
command worked as intended, and it seems to me that this "experiment"
was concerned with the process of installing from the doc directory,
but all of that was some time ago when I did that and I don't recall
the details.  Quite possibly it could have been the very same command
that failed in this most recent case.

Best regards,

Richard


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com