On Fri, Sep 4, 2009 at 3:49 AM, David
Matthews<[email protected]> 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
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
