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