Hi David,
I tried to build Poly/ML on Windows using the MSYS/MinGW toolchains, but was unsuccessful The build failed with:
g++ -DHAVE_CONFIG_H -I. -I.. -I../../../polyml.svn/polyml/libpolyml -DWINDOWS_P C -Wall -O3 -mthreads -MT mpoly.lo -MD -MP -MF .deps/mpoly.Tpo -c ../../../polym l.svn/polyml/libpolyml/mpoly.cpp -DDLL_EXPORT -DPIC -o .libs/mpoly.o ../../../polyml.svn/polyml/libpolyml/mpoly.cpp:24:23: error: winconfig.h: No suc h file or directory In file included from ../../../polyml.svn/polyml/libpolyml/mpoly.h:26, from ../../../polyml.svn/polyml/libpolyml/mpoly.cpp:60: ../../../polyml.svn/polyml/libpolyml/../polyexports.h:78: warning: 'PolyWinMain' initialized and declared 'extern' ../../../polyml.svn/polyml/libpolyml/../polyexports.h:78: error: 'HINSTANCE' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/../polyexports.h:78: error: 'HINSTANCE' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/../polyexports.h:79: error: 'LPTSTR' was no t declared in this scope ../../../polyml.svn/polyml/libpolyml/../polyexports.h:79: error: expected primar y-expression before 'int' ../../../polyml.svn/polyml/libpolyml/../polyexports.h:79: error: expected primar y-expression before '*' token ../../../polyml.svn/polyml/libpolyml/../polyexports.h:79: error: 'exports' was n ot declared in this scope ../../../polyml.svn/polyml/libpolyml/../polyexports.h:79: error: initializer exp ression list treated as compound expression In file included from ../../../polyml.svn/polyml/libpolyml/pexport.h:27, from ../../../polyml.svn/polyml/libpolyml/mpoly.cpp:65: ../../../polyml.svn/polyml/libpolyml/exporter.h:58: error: ISO C++ forbids decla ration of 'FILE' with no type ../../../polyml.svn/polyml/libpolyml/exporter.h:58: error: expected ';' before ' *' token ../../../polyml.svn/polyml/libpolyml/mpoly.cpp: In function 'int polymain(int, c har**, exportDescription*)': ../../../polyml.svn/polyml/libpolyml/mpoly.cpp:143: error: 'printf' was not decl ared in this scope ../../../polyml.svn/polyml/libpolyml/mpoly.cpp: In function 'void Usage(const ch ar*)': ../../../polyml.svn/polyml/libpolyml/mpoly.cpp:233: error: 'printf' was not decl ared in this scope ../../../polyml.svn/polyml/libpolyml/mpoly.cpp:236: error: 'printf' was not decl ared in this scope ../../../polyml.svn/polyml/libpolyml/mpoly.cpp:238: error: 'stdout' was not decl ared in this scope ../../../polyml.svn/polyml/libpolyml/mpoly.cpp:238: error: 'fflush' was not decl ared in this scope ../../../polyml.svn/polyml/libpolyml/mpoly.cpp:243: error: '_T' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/mpoly.cpp: In function 'char* RTSArgHelp()' : ../../../polyml.svn/polyml/libpolyml/mpoly.cpp:258: error: 'sprintf' was not dec lared in this scope ../../../polyml.svn/polyml/libpolyml/mpoly.cpp:261: warning: statement has no ef fect make[2]: *** [mpoly.lo] Error 1 make[2]: Leaving directory `/home/gdr/Desktop/sandbox/build/polyml/libpolyml'
This is an out-of-source build, meaning that I keep the build directory separate from the vanilla Poly/ML source tree. I had a quick look for winconfig.h and was under the impression that it was supposed to replace config.h (which is generated anyway at configure time). For some reason, it is not being seen by the preprocessor. Why keep winconfig.h when config.h (that truly reflects the host/build machine characteristics) is generated at configure time?
I also noticed that pthread is being check for even on Windows. I believe that is not good. On Windows, one should just check for Windows thread support. The reason is that configure may report that pthread.h exists without the full semantics support needed by Poly/ML (which is the case on my machine, Windows XP SP3). A second point is that in such circumstances, checking for HAVE_PTHREAD_H, then for WIN32 is not good. The test should be reversed. One should first check for WIN32, then HAVE_PTHREAD_H.
Another observation: __darwin_mcontext32 should be checked only on darwin platforms.
Best,
-- Gaby
Hi Gabriel,
Gabriel Dos Reis wrote:
I tried to build Poly/ML on Windows using the MSYS/MinGW toolchains, but was unsuccessful The build failed with:
This is an out-of-source build, meaning that I keep the build directory separate from the vanilla Poly/ML source tree. I had a quick look for winconfig.h and was under the impression that it was supposed to replace config.h (which is generated anyway at configure time). For some reason, it is not being seen by the preprocessor. Why keep winconfig.h when config.h (that truly reflects the host/build machine characteristics) is generated at configure time?
Doing an out-of-source build won't currently work. You may be able to build the library but compiling the basis library into Poly/ML assumes that it is running within the directory that contains the sources.
The reason for winconfig.h is that config.h is only built if you run configure. When building using Visual C++ there's no configure step so there needs to be a header file that defines the default set-up on Windows. In a few cases the code currently checks first for HAVE_CONFIG_H and uses configure.h if that is set and and falls back to winconfig.h if it isn't. I think that should be done everywhere.
I also noticed that pthread is being check for even on Windows. I believe that is not good. On Windows, one should just check for Windows thread support. The reason is that configure may report that pthread.h exists without the full semantics support needed by Poly/ML (which is the case on my machine, Windows XP SP3). A second point is that in such circumstances, checking for HAVE_PTHREAD_H, then for WIN32 is not good. The test should be reversed. One should first check for WIN32, then HAVE_PTHREAD_H.
That's a good point.
Another observation: __darwin_mcontext32 should be checked only on darwin platforms.
There are various header files that are operating-system specific. It's easier and probably more reliable to search for the files in all cases rather than only check on certain platforms. Unless it breaks something I'd prefer to leave it as it is.
Regards, David
On Fri, Sep 4, 2009 at 3:49 AM, David MatthewsDavid.Matthews@prolingua.co.uk wrote:
Hi Gabriel,
Gabriel Dos Reis wrote:
?I tried to build Poly/ML on Windows using the MSYS/MinGW toolchains, but was unsuccessful ?The build failed with:
This is an out-of-source build, meaning that I keep the build directory separate from the vanilla Poly/ML source tree. ?I had a quick look for winconfig.h and was under the impression that it was supposed to replace config.h (which is generated anyway at configure time). ?For some reason, it is not being seen by the preprocessor. ?Why keep winconfig.h when config.h (that truly reflects the host/build machine characteristics) is generated at configure time?
Doing an out-of-source build won't currently work. ?You may be able to build the library but compiling the basis library into Poly/ML assumes that it is running within the directory that contains the sources.
OK,thanks! Is it reasonable to expect that restriction to be lifted in a recent future?
The reason for winconfig.h is that config.h is only built if you run configure. ?When building using Visual C++ there's no configure step so there needs to be a header file that defines the default set-up on Windows. ?In a few cases the code currently checks first for HAVE_CONFIG_H and uses configure.h if that is set and and falls back to winconfig.h if it isn't. ?I think that should be done everywhere.
OK; after an update, the build progressed a little further. Thanks! However, I have a new failure:
g++ -DHAVE_CONFIG_H -I. -I../../../polyml.svn/polyml/libpolyml -I.. -DWINDOWS_P C -Wall -O3 -mthreads -MT sighandler.lo -MD -MP -MF .deps/sighandler.Tpo -c ../. ./../polyml.svn/polyml/libpolyml/sighandler.cpp -DDLL_EXPORT -DPIC -o .libs/sig handler.o ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:142: error: 'pthread_t' does not name a type ../../../polyml.svn/polyml/libpolyml/sighandler.cpp: In function 'void markSigna lInuse(int)': ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:168: error: 'sigemptyset' wa s not declared in this scope ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:169: error: 'sigaddset' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:170: error: 'SIG_UNBLOCK' wa s not declared in this scope ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:170: error: 'pthread_sigmask ' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/sighandler.cpp: At global scope: ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:205: error: variable or fiel d 'handle_signal' declared void ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:205: error: 's' was not decl ared in this scope ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:205: error: 'c' was not decl ared in this scope ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:205: error: 'SIG_HANDLER_ARG S' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:143: warning: 'waitSema' def ined but not used ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:144: warning: 'lastSignals' defined but not used
Looking at sighandler.cpp:142, I'm under the impression that the line
#if (!defined(WINDOWS_H) && defined(HAVE_LIBPTHREAD) && defined(HAVE_PTHREAD_H) && defined(HAVE_SEMAPHORE_H))
should just be
#ifdef USE_PTHREAD_SIGNALS
because that macro is already defined at line 86. Is that correct?
After I locally made that change, the build progressed a bit further. This time, the failure is:
g++ -DHAVE_CONFIG_H -I. -I../../../polyml.svn/polyml/libpolyml -I.. -DWINDOWS_P C -Wall -O3 -mthreads -MT sighandler.lo -MD -MP -MF .deps/sighandler.Tpo -c ../. ./../polyml.svn/polyml/libpolyml/sighandler.cpp -DDLL_EXPORT -DPIC -o .libs/sig handler.o ../../../polyml.svn/polyml/libpolyml/sighandler.cpp: In function 'sem_t_** init_ semaphore(sem_t_**, int)': ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:527: error: invalid conversi on from 'int' to 'sem_t_**' ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:528: error: 'SEM_FAILED' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/sighandler.cpp: At global scope: ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:510: warning: 'waitSemaphore ' defined but not used ../../../polyml.svn/polyml/libpolyml/sighandler.cpp:515: warning: 'sem_t_** init _semaphore(sem_t_**, int)' defined but not used make[2]: *** [sighandler.lo] Error 1
I could not see anything wrong at line 527. I had a look at the header <semaphore.h> under /mingw/mingw32/include and found that indeed sema_open is declared there to return an int. The macro SEM_FAILED is not defined. so my current recommendation is to avoid <semaphore.h> on MinGW. (test for the C preprocessor __MINGW__)
I also noticed that pthread is being check for even on Windows. ?I believe that is not good. ?On Windows, one should just check for Windows thread support. ?The reason is that configure may report that pthread.h exists without the full semantics support needed by Poly/ML (which is the case on my machine, Windows XP SP3). A second point is that in such circumstances, checking for HAVE_PTHREAD_H, then for WIN32 is not good. ?The test should be reversed. One should first check for WIN32, then HAVE_PTHREAD_H.
That's a good point.
Another observation: __darwin_mcontext32 should be checked only on darwin platforms.
There are various header files that are operating-system specific. ?It's easier and probably more reliable to search for the files in all cases rather than only check on certain platforms. ?Unless it breaks something I'd prefer to leave it as it is.
Well, my worry is that an unconditional test that looks for an OS-specific header may report an unreliable result. For example, I would suggest NOT testing for <semaphore.h> when on MinGW:
case $build in *mingw*) # MinGW's <semaphore.h> is unreliable. # Ditto for MinGW's <pthread.h> ;; *) AC_CHECK_HEADERS([pthread.h semaphore.h]) esac
Similarly, I would suggest the test for __darwin_mcontext32 be conditional.
Thanks!
-- Gaby
Gabriel Dos Reis wrote:
On Fri, Sep 4, 2009 at 3:49 AM, David MatthewsDavid.Matthews@prolingua.co.uk wrote:
Doing an out-of-source build won't currently work. You may be able to build the library but compiling the basis library into Poly/ML assumes that it is running within the directory that contains the sources.
OK,thanks! Is it reasonable to expect that restriction to be lifted in a recent future?
It should work in the next release. I've added support for an option to indicate where the source files are to be found but at the moment the pre-built compilers in the imports directory don't understand this.
Looking at sighandler.cpp:142, I'm under the impression that the line
#if (!defined(WINDOWS_H) && defined(HAVE_LIBPTHREAD) && defined(HAVE_PTHREAD_H) && defined(HAVE_SEMAPHORE_H))
should just be
#ifdef USE_PTHREAD_SIGNALS
because that macro is already defined at line 86. Is that correct?
Yes, I've tidied this up.
After I locally made that change, the build progressed a bit further.
I could not see anything wrong at line 527. I had a look at the header <semaphore.h> under /mingw/mingw32/include and found that indeed sema_open is declared there to return an int. The macro SEM_FAILED is not defined. so my current recommendation is to avoid <semaphore.h> on MinGW. (test for the C preprocessor __MINGW__)
Actually, this shouldn't be used if the pthread library isn't used. I've changed the ifdefs so that it doesn't include this. Generally, I try to avoid having ifdefs that check for specific operating systems. It's better to check for the presence of specific features.
Another observation: __darwin_mcontext32 should be checked only on darwin platforms.
There are various header files that are operating-system specific. It's easier and probably more reliable to search for the files in all cases rather than only check on certain platforms. Unless it breaks something I'd prefer to leave it as it is.
Well, my worry is that an unconditional test that looks for an OS-specific header may report an unreliable result. For example, I would suggest NOT testing for <semaphore.h> when on MinGW:
I guess this a matter of taste. I prefer to have configure report what is present or absent and then to make the choices about what to use in the code itself. There's sometimes a series of options depending on exactly what is available. In this case semaphore.h is present so configure should report that. It may be that it can't be used in this particular place but it could be used elsewhere.
Incidentally, I've just installed MinGW/MSys and semaphore.h isn't there. I have fixed a few other things and built poly successfully so if you update from SVN it should work.
Regards, David
On Sat, Sep 5, 2009 at 11:58 AM, David MatthewsDavid.Matthews@prolingua.co.uk wrote:
Gabriel Dos Reis wrote:
On Fri, Sep 4, 2009 at 3:49 AM, David MatthewsDavid.Matthews@prolingua.co.uk wrote:
Doing an out-of-source build won't currently work. ?You may be able to build the library but compiling the basis library into Poly/ML assumes that it is running within the directory that contains the sources.
OK,thanks! ?Is it reasonable to expect that restriction to be lifted in a recent future?
It should work in the next release. ?I've added support for an option to indicate where the source files are to be found but at the moment the pre-built compilers in the imports directory don't understand this.
OK.
Looking at sighandler.cpp:142, I'm under the impression that the line
#if (!defined(WINDOWS_H) && defined(HAVE_LIBPTHREAD) && defined(HAVE_PTHREAD_H) && defined(HAVE_SEMAPHORE_H))
should just be
#ifdef USE_PTHREAD_SIGNALS
because that macro is already defined at line 86. ?Is that correct?
Yes, I've tidied this up.
OK.
After I locally made that change, the build progressed a bit further.
I could not see anything wrong at line 527. ?I had a look at the header <semaphore.h> under /mingw/mingw32/include and found that indeed sema_open is declared there to return an int. ?The macro SEM_FAILED is not defined. ?so my current recommendation is to avoid <semaphore.h> on MinGW. ?(test for the C preprocessor __MINGW__)
Actually, this shouldn't be used if the pthread library isn't used. I've changed the ifdefs so that it doesn't include this. ?Generally, I try to avoid having ifdefs that check for specific operating systems. It's better to check for the presence of specific features.
I fully agree and that is my policy as well. In this specific case, the test for the feaure (pthread.h) appears positive, but the feature is broken on that specific platform. You're right in your fixes.
Another observation: __darwin_mcontext32 should be checked only on darwin platforms.
There are various header files that are operating-system specific. ?It's easier and probably more reliable to search for the files in all cases rather than only check on certain platforms. ?Unless it breaks something I'd prefer to leave it as it is.
Well, my worry is that an unconditional test that looks for an OS-specific header may report an unreliable result. ?For example, I would suggest NOT testing for <semaphore.h> when on MinGW:
I guess this a matter of taste. ?I prefer to have configure report what is present or absent and then to make the choices about what to use in the code itself. ?There's sometimes a series of options depending on exactly what is available. ?In this case semaphore.h is present so configure should report that. ?It may be that it can't be used in this particular place but it could be used elsewhere.
Incidentally, I've just installed MinGW/MSys and semaphore.h isn't there. ?I have fixed a few other things and built poly successfully so if you update from SVN it should work.
I'm using the latest MinGW/MSYS releases, with full developer toolsets. On my machine (Windows XP, 32-bit), the header is located under /ming/mingw32/include.
The in-source build indeed is now OK. Thanks!
The out-of-source build still fails for libpolyml. Now, it is
g++ -DHAVE_CONFIG_H -I. -I../../../polyml.svn/polyml/libpolyml -I.. -DWINDOWS_P C -Wall -O3 -mthreads -MT Console.lo -MD -MP -MF .deps/Console.Tpo -c ../../../p olyml.svn/polyml/libpolyml/Console.cpp -DDLL_EXPORT -DPIC -o .libs/Console.o ../../../polyml.svn/polyml/libpolyml/Console.cpp:61:22: error: resource.h: No su ch file or directory ../../../polyml.svn/polyml/libpolyml/Console.cpp: In function 'void CheckForBuff erSpace(int)': ../../../polyml.svn/polyml/libpolyml/Console.cpp:269: warning: suggest parenthes es around '&&' within '||' ../../../polyml.svn/polyml/libpolyml/Console.cpp: In function 'LRESULT EditSubcl assProc(HWND__*, UINT, WPARAM, LPARAM)': ../../../polyml.svn/polyml/libpolyml/Console.cpp:396: error: 'ID_EDIT_PASTE' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/Console.cpp: In function 'LRESULT WndProc(H WND__*, UINT, WPARAM, LPARAM)': ../../../polyml.svn/polyml/libpolyml/Console.cpp:575: error: 'ID_EDIT_COPY' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/Console.cpp:579: error: 'ID_EDIT_PASTE' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/Console.cpp:623: error: 'ID_HELP_ABOUT' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/Console.cpp:624: error: 'IDD_ABOUT_POLYML' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/Console.cpp:628: error: 'ID_FILE_QUIT' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/Console.cpp:634: error: 'ID_RUN_INTERRUPT' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/Console.cpp: In function 'int PolyWinMain(H INSTANCE__*, HINSTANCE__*, TCHAR*, int, exportDescription*)': ../../../polyml.svn/polyml/libpolyml/Console.cpp:787: error: 'IDI_ICON' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/Console.cpp:791: error: 'IDR_MENU' was not declared in this scope ../../../polyml.svn/polyml/libpolyml/Console.cpp: In function 'int initDDEContro l(char*)': ../../../polyml.svn/polyml/libpolyml/Console.cpp:991: warning: deprecated conver sion from string constant to 'char*' make[2]: *** [Console.lo] Error 1
-- Gaby
Gabriel Dos Reis wrote:
I'm using the latest MinGW/MSYS releases, with full developer toolsets. On my machine (Windows XP, 32-bit), the header is located under /ming/mingw32/include.
The in-source build indeed is now OK. Thanks!
The out-of-source build still fails for libpolyml. Now, it is
I've fixed a couple of things so that the out-of-tree build works as far as trying to build the basis library using the compiled polyimport. That fails as expected.
Regards, David
On Sun, Sep 6, 2009 at 3:17 AM, David MatthewsDavid.Matthews@prolingua.co.uk wrote:
Gabriel Dos Reis wrote:
I'm using the latest MinGW/MSYS releases, with full developer toolsets. ?On my machine (Windows XP, 32-bit), the header is located under /ming/mingw32/include.
The in-source build indeed is now OK. ?Thanks!
The out-of-source build still fails for libpolyml. ?Now, it is
I've fixed a couple of things so that the out-of-tree build works as far as trying to build the basis library using the compiled polyimport.
Thanks!
-- Gaby
-
David.Matthews＠prolingua.co.uk -
gdr＠integrable-solutions.net