Re: [pooma-dev] SMARTS compile problems (again)

[Richard Guenther]

On 12 Dec 2002, Tarjei Knapstad wrote:

> On Wed, 2002-12-11 at 13:03, Richard Guenther wrote:
> > On 11 Dec 2002, Tarjei Knapstad wrote:
> >
> > > Hi.
> > >
> > > I wanted to try POOMA today, and compile it together with SMARTS to be
> > > able to run in parallel using threads on a Mosix cluster. However,
> > > SMARTS 1.2 fails miserably to compile on my distribution (RH 8.0 using
> > > gcc3.2), and after about half an hour of trying to patch things up I
> > > finally gave in. I found a suggestion for a fix over at the pooma-dev
> > > mailing list at CodeSourcery but this did nothing to remedy the problem
> > > (au contraire).
> >
> > You may need to investigate which symbol you need to define to prevent
> > your libc/gcc pthread headers being included. The exact symbol name
> > (was _BITS_PTHREADTYPES_H for gcc-3.0.3 and glibc-2.2.2) may vary.
> >
> Well, this is in fact the include guard in my bits/pthreadtypes.h, but
> defining the include guard and omitting this file results in more
> trouble like:
>
> /usr/include/wchar.h:164: non-local function `int wcscasecmp_l(const
> wchar_t*,
>    const wchar_t*, __gthread_mutex_unlock(void**)::__locale_struct*)'
> uses
>    local type `__gthread_mutex_unlock(void**)::__locale_struct'
>
> So I tried omitting the ghtread stuff as well using
> -D_GLIBCPP_GCC_GTHR_POSIX_H which gets rid of the above type of errors,
> but results in:
>
> /usr/include/c++/3.2/bits/stl_threads.h:86: `__gthread_mutex_lock'
> undeclared

Well - ok, my simple workaround seems to not work with recent gcc/libc,
so fixing SMARTS remains. Basically all the pthread_* stuff in SMARTS
needs to be renamed to not pollute the pthread namespace. Or someone
needs to evaluate wether SMARTS can use the pthread stuff from existing
libc - but thats probably a bigger task.

Richard.

--
Richard Guenther <address@hidden>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/