On Mon, 05 Apr 2010 17:56:48 +0400, Samium Gromoff <_deepfire@...> wrote:
> On Mon, 05 Apr 2010 02:21:06 +0400, Samium Gromoff <_deepfire@...> wrote:
> > On Sun, 4 Apr 2010 03:19:27 +0200, Juan Jose Garcia-Ripoll <juanjose.garciaripoll@...> wrote:
> > > If there was threads in *features* I see two potential sources of the
> > > problem
> > >
> > > 1) The flag ECL_THREADS was not properly recorded in ecl/config.h
> > > 2) Something in the application that embeds ECL prevents that flag from
> > > being defined.
> > >
> > > From this side of the line it is difficult to tell.
> > I'll see and follow up, as soon as I get to the machine exhibiting the
> > issue..
> ecl/config.h contains:
> #define ECL_THREADS 1
> ...but ECL checks for the 'mingw32' preprocessor option, whereas
> '__MINGW32__' is what it appears we are to check for, instead.
> I'm currently testing a patch which does s/mingw32/__MINGW32__/.
The patch is in git://git.feelingofgreen.ru/ecl 's master.
I realise by now that ECL used to define 'mingw32', and that it,
for some reason, failed to work on my setup.
The question is, whether it still makes sense to provide that define
when MinGW already provides one. I can imagine, though, that history
proved the MinGW-provided definition to be volatile.
"Actually I made up the term 'object-oriented', and I can tell you I
did not have C++ in mind." - Alan Kay (OOPSLA 1997 Keynote)