[parisc-linux] problems with gcc 2.96

[parisc-linux] problems with gcc 2.96

[willy]

most people will need to run contrib/gcc_update in order to sort out
dependencies.  i did.  but then i get into:

$ rm -rf *
$ ../gcc/configure --target=hppa1.1-linux --prefix=/home/willy/parisc --host=i386-linux --disable-nls
[...]
/home/willy/parisc/gcc-build/gcc/xgcc -B/home/willy/parisc/gcc-build/gcc/ -B/home/willy/parisc/hppa1.1-linux/bin/ -c -g -O2 -I. -I../../../gcc/libio -D_IO_MTSAFE_IO ../../../gcc/libio/iogetline.c
In file included from ../../../gcc/libio/libio.h:166,
                 from ../../../gcc/libio/iolibio.h:1,
                 from ../../../gcc/libio/libioP.h:47,
                 from ../../../gcc/libio/iogetline.c:26:
/home/willy/parisc/hppa1.1-linux/include/bits/stdio-lock.h:29:2: #error libio needs recursive mutexes for _IO_MTSAFE_IO
make[1]: *** [iogetline.o] Error 1

dhd, you must have solved this already?

-- 
The Sex Pistols were revolutionaries.  The Bay City Rollers weren't.

Re: [parisc-linux] problems with gcc 2.96

[David Huggins-Daines]

willy@thepuffingroup.com writes:

> On Mon, Jul 10, 2000 at 10:06:06AM +1000, Alan Modra wrote:
> > On Sun, 9 Jul 2000 willy@thepuffingroup.com wrote:
> > 
> > > /home/willy/parisc/hppa1.1-linux/include/bits/stdio-lock.h:29:2: #error libio needs recursive mutexes for _IO_MTSAFE_IO
> > > make[1]: *** [iogetline.o] Error 1
> > > 
> > > dhd, you must have solved this already?
> > 
> > Errm, unless your glibc versions differ.  I did a merge on June 10.  Ducks
> > for cover.
> 
> I spoke to dhd last night and apparently the solution is to
> --disable-multilib for gcc.  i'm just trying it now and it appears to
> get a lot further.  time to update the recipe, i guess.

I've already told willy this, but this is due to the C++ support.
Configure with --enable-languages=c for the time being until it's sorted.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] problems with gcc 2.96

[David Huggins-Daines]

David Huggins-Daines <dhd@linuxcare.com> writes:

> I've already told willy this, but this is due to the C++ support.
> Configure with --enable-languages=c for the time being until it's sorted.

Ah, sorry, it happens if you configure glibc without linuxthreads
support (because, then, you have no spinlocks, obviously).  It seems
that we've already got the appropriate locking primitives
there... trying it now.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.

Re: [parisc-linux] problems with gcc 2.96

[Alan Modra]

On 10 Jul 2000, David Huggins-Daines wrote:

> David Huggins-Daines <dhd@linuxcare.com> writes:
> 
> > I've already told willy this, but this is due to the C++ support.
> > Configure with --enable-languages=c for the time being until it's sorted.
> 
> Ah, sorry, it happens if you configure glibc without linuxthreads
> support (because, then, you have no spinlocks, obviously).  It seems
> that we've already got the appropriate locking primitives
> there... trying it now.

Yeah, I got enthusiastic about implementing linuxthreads, and put in
support for parisc style spinlocks using ldcw (Load and Clear Word).
We need to grab a lock by clearing it so the locks need to be initialised
to non-zero, which is exactly opposite to other glibc spinlocks.  My
enthusiasm waned when I hit a missing syscall - forget what it was now.

-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] problems with gcc 2.96

[David Huggins-Daines]

Alan Modra <alan@linuxcare.com.au> writes:

> Yeah, I got enthusiastic about implementing linuxthreads, and put in
> support for parisc style spinlocks using ldcw (Load and Clear Word).
> We need to grab a lock by clearing it so the locks need to be initialised
> to non-zero, which is exactly opposite to other glibc spinlocks.  My
> enthusiasm waned when I hit a missing syscall - forget what it was now.

glibc doesn't really want to compile with linuxthreads for me -
something breaks in the way errno is handled and I get "undefined
reference to errno" when linking.

Jes says we don't really want to mess with that stuff until we have
shared libs working, and I'm inclined to trust him on that :-)

I guess for now we can just ignore libstdc++ and friends...

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.