CLN vs weird mixture of Cygwin and MinGW [Was: Results of building cln-1.1.13 ...]
--- Sheplyakov Alexei <varg@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
Hello, On Tue, Aug 15, 2006 at 06:39:44PM -0700, Richard Haney wrote:
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. In fact, some tools from that directories *are* used, (e.g. /usr/bin/install)
I chose to re-order those directories in PATH because of the conflict with versions of rm.exe , Aha, I see! Otherwise you can't remove files created by Cygwin's bash [and other utilites] (at least because of different pathname conventions used by Cygwin and win32).
So, I'm wondering about what bugs/limitations may be lurking in msys, which I have not tried much. Unlike Cygwin, Msys does not try to provide complete *NIX-like environment. Instead it creates a *minimal* environment for running configure scripts. Some people prefer Cygwin for this reason, but IMHO if you need a *NIX-like environment running some kind of *NIX natively is much better option :).
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)? This is just what
gcc -dumpmachine prints on my system. On your system it might be different, but it should contain "mingw32" string somewhere.
3. The "--disable-shared" option for configure seems desirable in a cygwin/mingw environment, and in fact it seems a good idea for a distributed version of CLN to make "--disable-shared" an automatic default in such an environment. If you give appropriate --host and --build arguments (or just use Msys) --disable-shared option will be automagically added. This option is already specified for MinGW, and people already asked why shared libraries are disabled (see mail by Ralf Wildenhues).
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? AFAIK "msvc" is due to name of m$'ish C runtime libraries (msvcrt.dll and friends) which are used by executables produced by MinGW version of GNU compilers.
Are there only a limited list of possible values for --build=... and --host=... ? Auto* tools use system names of form CPU-VENDOR-OS (so called "canonical name"). But in reality, such a naming scheme appears to be [to put it mildly] somewhat sloppy.
Where are they defined (and/or described in human-readable form)? These name are defined in the config.guess script (which is called by the configure), but the logic is [unnecessary] complicated. Basically, the canonical name is determined from the output of uname(1) and compiler's idea about target processor/OS name (as in gcc -dumpmachine).
Best regards, Alexei. -- All science is either physics or stamp collecting.
--- Sheplyakov Alexei <varg@theor.jinr.ru> wrote: [...]
On Tue, Aug 15, 2006 at 06:39:44PM -0700, Richard Haney wrote: [...]
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. In fact, some tools from that directories *are* used, (e.g. /usr/bin/install)
You're right. In fact, /usr/bin and /bin map to the same directory, namely, "C:/cygwin/bin". I was confusing /usr/bin with "C:/cygwin/usr/bin", which is not used. But now I'm puzzled as to why both /usr/bin and /bin map to the same directory and why they are both listed in my PATH variable. I evidently retained these from the original installation default for cygwin. The file "C:/cygwin/etc/profile.default" for the bash shell says: PATH="/usr/local/bin:/usr/bin:/bin:$PATH" Also, "mount -m" output is mount -f -u -t "C:/cygwin/bin" "/usr/bin" mount -f -u -t "C:/cygwin/lib" "/usr/lib" mount -f -u -t "C:/cygwin" "/" mount -t --change-cygdrive-prefix "/cygdrive" (I am pretty sure the mount points are the original ones provided by installation default, except perhaps I may have unset some of them and found that I couldn't reset them as "type system" and so reset them as "type user". At least this scenario (the possible resetting as "type user") seems to be suggested by the description of the "mount" command in Cygwin's online "Cygwin User's Guide", where these same mount points are shown as "type system" rather than "type user". But I just tried setting 'mount -f -s -t "C:/cygwin/usr/local/etc" "/usr/wacky"' and seemed to encounter no problem.) I suppose the two different mount points "/usr/bin" and "/" as well as the resulting redundancy in the PATH directories may be a holdover from some old standard unix conventions. So I haven't bothered to change these or to do any "clean up" for concern that I might ignorantly break something that depends on old unix conventions. Does anyone know what these conventions are all about and what might get broken by changing them? I didn't find anything in the various cygwin documents on this, but the cygwin installation's "bash.html" does say that a common value for PATH is /usr/gnu/bin:/usr/local/bin:/usr/ucb:/bin:/usr/bin:.. (I surmise that the last "." might be a . ending the sentence and should not be a part of the PATH value.) Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Hello Richard, * Richard Haney wrote on Wed, Aug 30, 2006 at 03:16:38AM CEST:
I suppose the two different mount points "/usr/bin" and "/" as well as the resulting redundancy in the PATH directories may be a holdover from some old standard unix conventions.
Does anyone know what these conventions are all about and what might get broken by changing them?
For example, scripts starting with #! /bin/sh or #! /usr/bin/env perl or just about any other instance where absolute paths are used, I presume. Cheers, Ralf
participants (3)
-
Ralf Wildenhues
-
Richard Haney
-
varg＠theor.jinr.ru