I just thought I'd share this in case it helps someone else.
To compile Gambit 4.6.3 in the MinGW/MSys shell, I had to add the following flags to the gcc commands for compiling C files to object files:
-fpermissive -fno-keep-inline-dllexport
Recent versions of MinGW use gcc version 4.6.1, which I suspect has stricter default requirements on the C code than prior versions of gcc, and I believe that's why I had to add -fpermissive.
The -fno-keep-inline-dllexport flag was added because I was getting an out of memory error compiling at least one C file.
I also added -Wno-write-strings because I was tired of warning messages.
It's a bit of a hack (and I'm sure there is a more correct place to put this), but I modified the configure script to do this by adding it in the FLAGS_OBJ line here:
case "$target_os" in
mingw*) # add Windows libraries needed by MinGW LIBS="$LIBS -lws2_32" FLAGS_OBJ="$FLAGS_OBJ -D_WINDOWS -Wno-write-strings -fpermissive -fno-keep-inline-dllexport"
If Marc (or others) want more detail, I'd be happy to oblige. I can extract the 4.6.3 tar file somewhere else and try to build it, and not the exact error messages, etc.
Afficher les réponses par date
On Tue, Jan 31, 2012 at 2:43 AM, REPLeffect repleffect@gmail.com wrote:
I just thought I'd share this in case it helps someone else.
To compile Gambit 4.6.3 in the MinGW/MSys shell, I had to add the following flags to the gcc commands for compiling C files to object files:
-fpermissive -fno-keep-inline-dllexport
Recent versions of MinGW use gcc version 4.6.1, which I suspect has stricter default requirements on the C code than prior versions of gcc, and I believe that's why I had to add -fpermissive.
The -fno-keep-inline-dllexport flag was added because I was getting an out of memory error compiling at least one C file.
I also added -Wno-write-strings because I was tired of warning messages.
It's a bit of a hack (and I'm sure there is a more correct place to put this), but I modified the configure script to do this by adding it in the FLAGS_OBJ line here:
case "$target_os" in
mingw*) # add Windows libraries needed by MinGW LIBS="$LIBS -lws2_32" FLAGS_OBJ="$FLAGS_OBJ -D_WINDOWS -Wno-write-strings -fpermissive -fno-keep-inline-dllexport"
If Marc (or others) want more detail, I'd be happy to oblige. I can extract the 4.6.3 tar file somewhere else and try to build it, and not the exact error messages, etc.
Grr, thats "and *note* the exact error messages, etc.".
Must be time to go to bed. :-D
On 2012-01-31, at 3:43 AM, REPLeffect wrote:
I just thought I'd share this in case it helps someone else.
To compile Gambit 4.6.3 in the MinGW/MSys shell, I had to add the following flags to the gcc commands for compiling C files to object files:
-fpermissive -fno-keep-inline-dllexport
Recent versions of MinGW use gcc version 4.6.1, which I suspect has stricter default requirements on the C code than prior versions of gcc, and I believe that's why I had to add -fpermissive.
The -fno-keep-inline-dllexport flag was added because I was getting an out of memory error compiling at least one C file.
I also added -Wno-write-strings because I was tired of warning messages.
It's a bit of a hack (and I'm sure there is a more correct place to put this), but I modified the configure script to do this by adding it in the FLAGS_OBJ line here:
case "$target_os" in
mingw*) # add Windows libraries needed by MinGW LIBS="$LIBS -lws2_32" FLAGS_OBJ="$FLAGS_OBJ -D_WINDOWS -Wno-write-strings-fpermissive -fno-keep-inline-dllexport"
If Marc (or others) want more detail, I'd be happy to oblige. I can extract the 4.6.3 tar file somewhere else and try to build it, and not the exact error messages, etc.
Note that -fpermissive is specific to C++. Were you using --enable-cplusplus? Moreover, the documentation says:
-fpermissive Downgrade some diagnostics about nonconformant code from errors to warnings. Thus, using -fpermissive will allow some nonconforming code to compile.
Now, why did you have to use this option? Can you send me the error message that were generated? I don't want to add this option to the default compilation options because it implies that the Gambit sources have some nonconformance issue, and that shouldn't be the case.
Marc
On 1/31/12, Marc Feeley feeley@iro.umontreal.ca wrote:
On 2012-01-31, at 3:43 AM, REPLeffect wrote:
I just thought I'd share this in case it helps someone else.
To compile Gambit 4.6.3 in the MinGW/MSys shell, I had to add the following flags to the gcc commands for compiling C files to object files:
-fpermissive -fno-keep-inline-dllexport
Recent versions of MinGW use gcc version 4.6.1, which I suspect has stricter default requirements on the C code than prior versions of gcc, and I believe that's why I had to add -fpermissive.
The -fno-keep-inline-dllexport flag was added because I was getting an out of memory error compiling at least one C file.
I also added -Wno-write-strings because I was tired of warning messages.
It's a bit of a hack (and I'm sure there is a more correct place to put this), but I modified the configure script to do this by adding it in the FLAGS_OBJ line here:
case "$target_os" in
mingw*) # add Windows libraries needed by MinGW LIBS="$LIBS -lws2_32" FLAGS_OBJ="$FLAGS_OBJ -D_WINDOWS -Wno-write-strings-fpermissive -fno-keep-inline-dllexport"
If Marc (or others) want more detail, I'd be happy to oblige. I can extract the 4.6.3 tar file somewhere else and try to build it, and not the exact error messages, etc.
Note that -fpermissive is specific to C++. Were you using --enable-cplusplus? Moreover, the documentation says:
-fpermissive Downgrade some diagnostics about nonconformant code from errorsto warnings. Thus, using -fpermissive will allow some nonconforming code to compile.
Now, why did you have to use this option? Can you send me the error message that were generated? I don't want to add this option to the default compilation options because it implies that the Gambit sources have some nonconformance issue, and that shouldn't be the case.
Marc
Yes, I am compiling the code using the C++ compiler. I am configuring with:
./configure --enable-single-host --enable-cplusplus
I just untarred the v4.6.3 tarball and reconfigured it with those options. After starting the build, the first set of errors showed up in os_tty.c:
os_tty.c:3399:52: error: invalid conversion from 'unsigned char*' to 'LPCSTR {aka const char*}' [-fpermissive] c:\mingw\bin../lib/gcc/mingw32/4.6.1/../../../../include/winuser.h:4084:24: error: initializing argument 2 of 'BOOL SetWindowTextA(HWND, LPCSTR)' [-fpermissive] os_tty.c: In function 'int lineeditor_copy_to_clipboard(___device_tty*, unsigned int*, int)': os_tty.c:4499:60: error: invalid conversion from 'LPVOID {aka void*}' to 'short unsigned int*' [-fpermissive] os_tty.c: In function 'int lineeditor_paste_from_clipboard(___device_tty*)': os_tty.c:4584:60: error: invalid conversion from 'LPVOID {aka void*}' to 'short unsigned int*' [-fpermissive] make[1]: *** [os_tty.o] Error 1 make[1]: Leaving directory `/f/tst/gambc-v4_6_3-devel/lib' make: *** [all-recursive] Error 1
A few simple casts got me past those errors (without the -fpermissive switch being turned on):
diff --git a/lib/os_tty.c b/lib/os_tty.c index e833328..a0abb96 100644 --- a/lib/os_tty.c +++ b/lib/os_tty.c @@ -3396,7 +3396,7 @@ ___U8 *text_arg;) { if (text_arg != NULL) { - SetWindowTextA (cons_wind, text_arg); /* ignore error */ + SetWindowTextA (cons_wind, (LPCSTR)text_arg); /* ignore error */ } else { @@ -4496,7 +4496,7 @@ int len;)
if (global_copy != NULL) { - ___U16 *locked_copy = GlobalLock (global_copy); + ___U16 *locked_copy = (___U16*)GlobalLock (global_copy);
if (locked_copy == NULL) GlobalFree (global_copy); @@ -4581,7 +4581,7 @@ ___device_tty *self;)
if (global_copy != NULL) { - ___U16 *locked_copy = GlobalLock (global_copy); + ___U16 *locked_copy = (___U16*)GlobalLock (global_copy);
if (locked_copy != NULL) {
C++ purists will say I should have used static_cast<___U16*>( ... ), etc. OK, well I didn't :-D
Interestingly enough, this time I was able to get v4.6.3 to successfully compile without using -fno-keep-inline-dllexport.
The machine I'm compiling on only has 1 GB of RAM, and the last time I compiled I probably had other programs running on the machine that were consuming a lot of memory. Basically nothing else was running while doing this test compile. However, I do know that in recent past attempts I *have* received an out-of-memory error when compling Gambit without the -fno-keep-inline-dllexport option. I have also used that option to get past out-of-memory errors when compiling my own programs written in Gambit Scheme (some of which use a fair bit of memory and are sometimes compiled on machines that are memory-constrained)
As a final test, I started over with a fresh copy ov v4.6.3, applied the above patch, and ran a make bootstrap, make update, and make install -- all of which worked wonderfully, without the -fpermissive switch being used.
BTW Marc, the MinGW "make check" and shell-command(bug 152) fixes you recently applied work great on my MingW-compiled copy of Gambit also.
Thanks, and let me know if there's any more information you need on this.
On 2012-02-01, at 12:06 AM, REPLeffect wrote:
As a final test, I started over with a fresh copy ov v4.6.3, applied the above patch, and ran a make bootstrap, make update, and make install -- all of which worked wonderfully, without the -fpermissive switch being used.
I have committed your patch. Thanks! Can you double-check that it works for you?
BTW Marc, the MinGW "make check" and shell-command(bug 152) fixes you recently applied work great on my MingW-compiled copy of Gambit also.
Great. As a side note, I should thank the GHC folks (Glasgow Haskell) because the Windows command line escaping algorithm comes from them (see below for the relevant part of their source code, which gives pointers to related documentation).
The escaping algorithm seems to work well when creating a process from an executable (.exe) file. Unfortunately, when starting a process from a batch file (.bat) it appears that the double quotes used to escape the command line arguments are preserved, and are visible to the batch file. In other words, executing:
foo.bat hello and foo.bat "hello"
bind %1 to different strings in the batch file. I'm not sure this glitch can be fixed, and that it is worth fixing.
Marc
-- ------------------------------------------------------------------------ -- Escaping commands for shells
{- On Windows we also use this for running commands. We use CreateProcess, passing a single command-line string (lpCommandLine) as its argument. (CreateProcess is well documented on http://msdn.microsoft.com.)
- It parses the beginning of the string to find the command. If the file name has embedded spaces, it must be quoted, using double quotes thus "foo\this that\cmd" arg1 arg2
- The invoked command can in turn access the entire lpCommandLine string, and the C runtime does indeed do so, parsing it to generate the traditional argument vector argv[0], argv[1], etc. It does this using a complex and arcane set of rules which are described here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm...
(if this URL stops working, you might be able to find it by searching for "Parsing C Command-Line Arguments" on MSDN. Also, the code in the Microsoft C runtime that does this translation is shipped with VC++).
Our goal in runProcess is to take a command filename and list of arguments, and construct a string which inverts the translatsions described above, such that the program at the other end sees exactly the same arguments in its argv[] that we passed to rawSystem.
This inverse translation is implemented by 'translate' below.
Here are some pages that give informations on Windows-related limitations and deviations from Unix conventions:
http://support.microsoft.com/default.aspx?scid=kb;en-us;830473 Command lines and environment variables effectively limited to 8191 characters on Win XP, 2047 on NT/2000 (probably even less on Win 9x):
http://www.microsoft.com/windowsxp/home/using/productdoc/en/default.asp?url=... Command-line substitution under Windows XP. IIRC these facilities (or at least a large subset of them) are available on Win NT and 2000. Some might be available on Win 9x.
http://www.microsoft.com/windowsxp/home/using/productdoc/en/default.asp?url=... How CMD.EXE processes command lines.
Note: CreateProcess does have a separate argument (lpApplicationName) with which you can specify the command, but we have to slap the command into lpCommandLine anyway, so that argv[0] is what a C program expects (namely the application name). So it seems simpler to just use lpCommandLine alone, which CreateProcess supports. -}
translate :: String -> String #if mingw32_HOST_OS translate str = '"' : snd (foldr escape (True,""") str) where escape '"' (b, str) = (True, '\' : '"' : str) escape '\' (True, str) = (True, '\' : '\' : str) escape '\' (False, str) = (False, '\' : str) escape c (b, str) = (False, c : str) -- See long comment above for what this function is trying to do. -- -- The Bool passed back along the string is True iff the -- rest of the string is a sequence of backslashes followed by -- a double quote. #else translate str = ''' : foldr escape "'" str where escape ''' = showString "'\''" escape c = showChar c #endif
On 2/1/12, Marc Feeley feeley@iro.umontreal.ca wrote:
On 2012-02-01, at 12:06 AM, REPLeffect wrote:
As a final test, I started over with a fresh copy ov v4.6.3, applied the above patch, and ran a make bootstrap, make update, and make install -- all of which worked wonderfully, without the -fpermissive switch being used.
I have committed your patch. Thanks! Can you double-check that it works for you?
So far so good. I updated to the latest git commit, rebuilt and ran "make check". Everything looks good.
The only question I have is about this test result:
------------ TEST 4 (interpreter running an application) rm -f mix.o ../gsi/gsi -:~~bin=../bin,~~lib=../lib,~~include=../include -f mix.scm
test4.out
4.015625 secs elapsed cpu time heartbeat frequency = 64.49805447470817 Hz *** possible problem: expected heartbeat frequency = 1000. Hz diff test4.ok test4.out && rm -f test4.out
It isn't related to the changes in question, of course. But I have seen this before and wondered if it was a problem.
[snip]
On 2012-02-01, at 2:24 PM, REPLeffect wrote:
So far so good. I updated to the latest git commit, rebuilt and ran "make check". Everything looks good.
The only question I have is about this test result:
------------ TEST 4 (interpreter running an application) rm -f mix.o ../gsi/gsi -:~~bin=../bin,~~lib=../lib,~~include=../include -f mix.scm
test4.out
4.015625 secs elapsed cpu time heartbeat frequency = 64.49805447470817 Hz *** possible problem: expected heartbeat frequency = 1000. Hz diff test4.ok test4.out && rm -f test4.out
It isn't related to the changes in question, of course. But I have seen this before and wondered if it was a problem.
I have seen this also. On Windows, the heartbeat interrupt is implemented with an OS thread which is programmed to wake up every millisecond, so the heartbeat frequency should be 1000 Hz. However, the Windows thread scheduler is probably using a lower frequency timer interrupt (probably 60 Hz) to multiplex the OS threads, so it only manages to wake up the heartbeat thread 60 times per second.
If you know how to get this information (granularity of timer interrupts) on Windows, please let me know and I will change the expected heartbeat frequency.
Otherwise, this warning is pretty innocuous, as long as the heartbeat frequency is non zero (a heartbeat frequency of 0 would indicate that there is no preemptive multiplexing of the Scheme threads).
Marc
-
Marc Feeley -
REPLeffect