I'm trying to build some stuff from pkgsrc-current on my 5.1 stable
Cobalt machine, and this error seems to be stopping me for a lot of
stuff:
gcc -DHAVE_CONFIG_H -I. -D_FILE_OFFSET_BITS=64 -DHAVE_REAL_10=0
-fPIC -g -O2 -MT mutex.o -MD -MP -MF .deps/mutex.Tpo -c -o mutex.o
`test -f 'runtime/mutex.c' || echo './'`runtime/mutex.c
/var/tmp//cchepj54.s: Assembler messages:
/var/tmp//cchepj54.s:30: Error: opcode not supported on this
processor: mips1 (mips1) `ll $5,0($4)'
/var/tmp//cchepj54.s:32: Error: opcode not supported on this
processor: mips1 (mips1) `sc $6,0($4)'
gmake[1]: *** [mutex.o] Error 1
gmake[1]: Leaving directory `/usr/pkgsrc/lang/g95/work/g95-0.92/libf95.a-0.92'
gmake: *** [all] Error 2
*** Error code 2
I opened a pr for this, pkg/44547
Just wondering if anyone else has run into this.
Andy
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
> Hello,
>
> I'm trying to build some stuff from pkgsrc-current on my 5.1 stable
> Cobalt machine, and this error seems to be stopping me for a lot of
> stuff:
>
> gcc -DHAVE_CONFIG_H -I. -D_FILE_OFFSET_BITS=64 -DHAVE_REAL_10=0
> -fPIC -g -O2 -MT mutex.o -MD -MP -MF .deps/mutex.Tpo -c -o mutex.o
> `test -f 'runtime/mutex.c' || echo './'`runtime/mutex.c
> /var/tmp//cchepj54.s: Assembler messages:
> /var/tmp//cchepj54.s:30: Error: opcode not supported on this
> processor: mips1 (mips1) `ll $5,0($4)'
> /var/tmp//cchepj54.s:32: Error: opcode not supported on this
> processor: mips1 (mips1) `sc $6,0($4)'
> gmake[1]: *** [mutex.o] Error 1
> gmake[1]: Leaving directory `/usr/pkgsrc/lang/g95/work/g95-0.92/libf95.a-0.92'
> gmake: *** [all] Error 2
> *** Error code 2
>
> I opened a pr for this, pkg/44547
>
> Just wondering if anyone else has run into this.
mips1 doesn't support the ll/sc instructions.
I would switch it to use the libc mutex stubs.
I'm not what you would call a developer...
Can you give me a hint about how to do this?
The larger question is: Did this break reacently? I never had this
build error with pkgsrc before. If this condition can be detected, it
might be nice to fix in pkgsrc as well.
Thanks.
Andy
This still isn't resolved and this information isn't enough for me to
research it on my own. Can you give me something I can use to try to
figure this out?
I've been going through the work directory for g95 trying to figure
out what you're talking about but I can't find anything.
Thanks.
Andy
- modern threading applications require locking primitives
(mutex, rwlock etc)
- most applications implements their own locking primitives
- locking primitive requires CPU specific "atomic" instructions
especially for SMP
- on MIPS, ll/sc instruction is required for SMP locking primitives
- only MIPS3 CPUs have ll/sc and MIPS1 CPUs don't have it
because MIPS1 CPUs are not SMP capable
- most applications don't care almost obsolete MIPS1 machines
- NetBSD still supports MIPS1 and -march=mips1 is default on gcc,
so it complains ll/sc instruction is not supported by MIPS1
workaround:
- use -march=mips3 -mabi=32 in CFLAGS (or CPUFLAGS etc)
so gcc/gas accepts ll/sc
(but generated binaries won't run on MIPS1 machines)
real fix:
- NetBSD has common APIs atomic_ops(3) for the primitives in libc
and all third party applications _should_ use them so that
they won't have to have own CPU specific implementations
pulseaudio (pkgsrc/audio/pulseaudio) supports NetBSD's atomic_ops(3)
so its implementation (pulseaudio-0.x.y/src/pulsecore/atomic.h) might help.
---
Izumi Tsutsui
Well, just to try to see if it works, I set this in /etc/mk.conf:
# cat /etc/mk.conf
CFLAGS+= -march=mips3 -mabi=32
I could see these options being used early in the build of g95, but it
seems like they didn't get used later during the build of this
libf95.a-0.92 component. The failure was the same:
gcc -DHAVE_CONFIG_H -I. -D_FILE_OFFSET_BITS=64 -DHAVE_REAL_10=0
-fPIC -g -O2 -MT mutex.o -MD -MP -MF .deps/mutex.Tpo -c -o mutex.o
`test -f 'runtime/mutex.c' || echo './'`runtime/mutex.c
/var/tmp//cckQQmpt.s: Assembler messages:
/var/tmp//cckQQmpt.s:30: Error: opcode not supported on this
processor: mips1 (mips1) `ll $5,0($4)'
/var/tmp//cckQQmpt.s:32: Error: opcode not supported on this
processor: mips1 (mips1) `sc $6,0($4)'
gmake[1]: *** [mutex.o] Error 1
gmake[1]: Leaving directory `/usr/pkgsrc/lang/g95/work/g95-0.92/libf95.a-0.92'
gmake: *** [all] Error 2
*** Error code 2
Stop.
make: stopped in /usr/pkgsrc/lang/g95
*** Error code 1
Stop.
make: stopped in /usr/pkgsrc/lang/g95
I'll see if I can figure out how to solve that. I want to make sure
that g95 will build before I pursue some fix for this.
Thanks Izumi.
Andy
I'm not sure if pkgsrc system handles CFLAGS in mk.conf for packages build,
but we can edit Makefile after "make configure" in the package dir..
---
Izumi Tsutsui
Hmm, configure looks called during "make", not make configure.
Anyway, work.i386/g95-0.92/libf95.a-0.92/runtime/mutex.c
seems simple enough. How about the attached change?
---
Izumi Tsutsui
--- work/g95-0.92/libf95.a-0.92/runtime/mutex.c.orig 2008-09-17 03:45:13.000000000 +0000
+++ work/g95-0.92/libf95.a-0.92/runtime/mutex.c
@@ -8,6 +8,11 @@
#include <stdlib.h>
+#ifdef __NetBSD__ /* XXX: available only 5.0 and later */
+#include <sys/atomic.h>
+#define cas(ptr, old, new) atomic_cas_uint(ptr, old, new)
+
+#else
/* x86/x86_64 */
@@ -158,6 +163,7 @@
#endif
+#endif /* __NetBSD__ */
/* aquire_lock()-- Aquire a lock. Returns when we have the lock. */
It looks you might have some leftover CFLAGS settings:
>> checking whether the C compiler (gcc -O2 -march=mips3 -mabi=32 \
>> -DIN_GCC -Wall -Wmissing-prototypes ) works... yes
Clean all files and environments?
You were correct.
I removed the mips CFLAGS options from /etc/mk.conf, and also logged
out and back in to clear my environment variables. Then I did this:
root@taz:/usr/pkgsrc/lang/g95 # make extract && patch < patch && make package
This finished with success:
===> Building binary package for g95-0.92
=> Creating binary package /usr/pkgsrc/packages/All/g95-0.92.tgz
Thanks again Izumi.
Maybe we should submit this patch as a fix to the PR? I could try to
tell the person that maintains the libf95 package as well.
Thanks,
Andy
As noted in the diff, "#ifdef __NetBSD__" check won't work on NetBSD 4.x.
Probably atomic_ops(3) check should be in configure like pulseaudio?
---
Izumi Tsutsui