John Klos | 1 Mar 2005 05:37

2.0 isn't self-building

Hi,

Trying to self-build with a new netbsd-2 source branch doesn't work:

GROFF_COMMAND_PREFIX='';  export GROFF_COMMAND_PREFIX; 
GROFF_BIN_PATH=`echo /home/obj/tools/groff/build/src/roff/groff 
/home/obj/tools/groff/build/src/roff/troff 
/home/obj/tools/groff/build/src/preproc/pic 
/home/obj/tools/groff/build/src/preproc/eqn 
/home/obj/tools/groff/build/src/preproc/tbl 
/home/obj/tools/groff/build/src/preproc/grn 
/home/obj/tools/groff/build/src/preproc/refer 
/home/obj/tools/groff/build/src/preproc/soelim 
/home/obj/tools/groff/build/src/preproc/html 
/home/obj/tools/groff/build/src/devices/grops 
/home/obj/tools/groff/build/src/devices/grohtml | sed -e 's|  *|:|g'`; 
export GROFF_BIN_PATH;  sed -e "s; <at> VERSION <at> ;1.19;" 
/usr/src/gnu/dist/groff/doc/pic.ms  | 
/home/obj/tools/groff/build/src/roff/groff/groff 
-M/home/obj/tools/groff/build/tmac -M/usr/src/gnu/dist/groff/tmac 
-F/home/obj/tools/groff/build/font -F/usr/src/gnu/dist/groff/font -Upet 
-ww -Tps -ms -mwww >pic.ps
/home/obj/tools/groff/build/src/roff/groff/groff: pic: Segmentation fault 
(core dumped)

Any ideas?

John

(Continue reading)

Tom Ivar Helbekkmo | 1 Mar 2005 08:40
Picon

Re: 2.0 isn't self-building

John Klos <john <at> ziaspace.com> writes:

> Any ideas?

I've just installed 2.0 on a 4000-500, and got lots of weird errors
("illegal instruction" from temacs when building Emacs, "internal
error" from gawk when building something else, "system error" from
something I don't recall, gunzip claimed checksum failures in known
good archives...), so I've now installed a cross-compiled -current.

The problems were repeatable, so probably (hopefully!) not hardware.

I'll post more as I experiment with -current.

-tih
--

-- 
Don't ascribe to stupidity what can be adequately explained by ignorance.

Kirk Russell | 1 Mar 2005 14:33

Re: 2.0 isn't self-building

On Mon, 28 Feb 2005, John Klos wrote:

> Hi,
>
> Trying to self-build with a new netbsd-2 source branch doesn't work:
>
> GROFF_COMMAND_PREFIX='';  export GROFF_COMMAND_PREFIX;
> GROFF_BIN_PATH=`echo /home/obj/tools/groff/build/src/roff/groff
> /home/obj/tools/groff/build/src/roff/troff
> /home/obj/tools/groff/build/src/preproc/pic
> /home/obj/tools/groff/build/src/preproc/eqn
> /home/obj/tools/groff/build/src/preproc/tbl
> /home/obj/tools/groff/build/src/preproc/grn
> /home/obj/tools/groff/build/src/preproc/refer
> /home/obj/tools/groff/build/src/preproc/soelim
> /home/obj/tools/groff/build/src/preproc/html
> /home/obj/tools/groff/build/src/devices/grops
> /home/obj/tools/groff/build/src/devices/grohtml | sed -e 's|  *|:|g'`;
> export GROFF_BIN_PATH;  sed -e "s; <at> VERSION <at> ;1.19;"
> /usr/src/gnu/dist/groff/doc/pic.ms  |
> /home/obj/tools/groff/build/src/roff/groff/groff
> -M/home/obj/tools/groff/build/tmac -M/usr/src/gnu/dist/groff/tmac
> -F/home/obj/tools/groff/build/font -F/usr/src/gnu/dist/groff/font -Upet
> -ww -Tps -ms -mwww >pic.ps
> /home/obj/tools/groff/build/src/roff/groff/groff: pic: Segmentation fault
> (core dumped)

To continue building, I copied over the released pic and continued.  The
next issue is grn:
/ovax/obj/tools/groff/build/src/roff/groff/groff: grn: Segmentation fault (core dumped)
(Continue reading)

Tom Ivar Helbekkmo | 1 Mar 2005 15:30
Picon

Re: 2.0 isn't self-building

I wrote:

> I've just installed 2.0 on a 4000-500, and got lots of weird errors
> ("illegal instruction" from temacs when building Emacs, [...]

Running a fresh -current, this still happens:

| LC_ALL=C ./temacs -batch -l loadup dump
| Loading loadup (source)...
| Using load-path (/usr/pkgsrcæditorsæmacs/workæmacs-21.4/lisp)
| Loading byte-run...
| Loading subr...
| [...]
| Loading buff-menu...
| Loading float-sup...
| [1]   Illegal instruction (core dumped) LC_ALL=C ./temac...
| *** Error code 132

GDB says:

| (gdb) where
| #0  0x7f5b3ee7 in atan2 (16512, 0, 16512, 0) from /usr/lib/libm.so.0
| #1  0x7f7e26be in _rtld_bind_start (16512, 0, 16512, 0)
|    from /usr/libexec/ld.elf_so
| #2  0x7f5b3bd8 in atan (16512, 0) from /usr/lib/libm.so.0
| #3  0x000f0f5e in Fatan (1)
| #4  0x000efb76 in Ffuncall (2, 2147476292)
| #5  0x00113d4b in Fbyte_code (809746436, 1078203264, 2)
| #6  0x000ef304 in Feval (1345781908)
| [...]
(Continue reading)

Tom Ivar Helbekkmo | 1 Mar 2005 15:32
Picon

Re: 2.0 isn't self-building

Sorry -- didn't mean to send that just yet...  I see there's some
unfinished code involved.  I'll dig a bit further.

-tih
--

-- 
Don't ascribe to stupidity what can be adequately explained by ignorance.

Tom Ivar Helbekkmo | 1 Mar 2005 21:54
Picon

Re: 2.0 isn't self-building

I wrote:

> I've just installed 2.0 on a 4000-500, and got lots of weird errors
> ("illegal instruction" from temacs when building Emacs, [...]

Running a fresh -current, this still happens:

| LC_ALL=C ./temacs -batch -l loadup dump
| Loading loadup (source)...
| Using load-path (/usr/pkgsrc/editors/emacs/work/emacs-21.4/lisp)
| Loading byte-run...
| Loading subr...
| [...]
| Loading buff-menu...
| Loading float-sup...
| [1]   Illegal instruction (core dumped) LC_ALL=C ./temac...
| *** Error code 132

GDB says:

| (gdb) where
| #0  0x7f5b3ee7 in atan2 (16512, 0, 16512, 0) from /usr/lib/libm.so.0
| #1  0x7f7e26be in _rtld_bind_start (16512, 0, 16512, 0)
|    from /usr/libexec/ld.elf_so
| #2  0x7f5b3bd8 in atan (16512, 0) from /usr/lib/libm.so.0
| #3  0x000f0f5e in Fatan (1)
| #4  0x000efb76 in Ffuncall (2, 2147476292)
| #5  0x00113d4b in Fbyte_code (809746436, 1078203264, 2)
| #6  0x000ef304 in Feval (1345781908)
| [...]
(Continue reading)

Tom Ivar Helbekkmo | 2 Mar 2005 07:22
Picon

Re: 2.0 isn't self-building

I wrote:

> But hey, Emacs is working.  I can edit comfortably!  :-)

OK, *that* is an overstatement.  I can use Emacs, and I do, but it's
incredibly easy to crash it: anything that explicitly changes input
focus to the minibuffer will, for instance, cause it to go down in
flames immediately.  ("M-x", for instance, or "C-f".)

PostgreSQL 8.0.1 building now.  :-)

-tih
--

-- 
Don't ascribe to stupidity what can be adequately explained by ignorance.

KAMINSKI | 2 Mar 2005 20:46
Picon

Re: 2.0 isn't self-building

Hi,

i have similar problems on my VS4000/60.
While i'm not expierienced with Make

filesyntax, in src/lib/libm/Makefile there is one thing that seems odd to me:

.elif (${MACHINE_ARCH} == "vax")
#.PATH: ${.CURDIR}/arch/vax
#NOIEEE_ARCH= n_infnan.S n_argred.S n_sqrt.S
#ARCH_SRCS = n_atan2.S n_cabs.S n_cbrt.S n_support.S n_sincos.S n_tan.S
# XXX - ripped out due to lack of the insn polyd in the Mariah chip,
# and emulation code isn't written yet.
WARNS?=2
.endif

Above the n_atan2.S is ripped out, but...

.if (${MACHINE_ARCH} == "vax") # XXX until POLYD is written.
.PATH:  ${.CURDIR}/arch/vax
SRCS:=${SRCS} n_sqrt.S n_argred.S n_infnan.S n_atan2.S n_cabs.S n_cbrt.S \
        n_support.S

Here it is included. Maybe this is the source of the problems.

Tom Ivar Helbekkmo | 3 Mar 2005 09:07
Picon

Re: 2.0 isn't self-building

I wrote:

> I can use Emacs, and I do, but it's incredibly easy to crash it:
> anything that explicitly changes input focus to the minibuffer will,
> for instance, cause it to go down in flames immediately.  ("M-x",
> for instance, or "C-f".)

That should be "C-xC-f", of course.

> PostgreSQL 8.0.1 building now.  :-)

...and it works fine.

All in all, it looks to me as if -current on VAX works perfectly, with
the single exception that libm uses the "polyd" instruction, which
isn't supported on my VAX, a KA680 (in a 4000-500).  I suspect this
means that applications that use that instruction will fail on quite
a few different models of VAXen, right?

-tih
--

-- 
Don't ascribe to stupidity what can be adequately explained by ignorance.

Tom Ivar Helbekkmo | 3 Mar 2005 09:10
Picon

Re: 2.0 isn't self-building

KAMINSKI <at> ikp.tu-darmstadt.de writes:

> While i'm not expierienced with Make filesyntax, in
> src/lib/libm/Makefile there is one thing that seems odd to me:
>
> .elif (${MACHINE_ARCH} == "vax")
> #.PATH: ${.CURDIR}/arch/vax
> #NOIEEE_ARCH= n_infnan.S n_argred.S n_sqrt.S
> #ARCH_SRCS = n_atan2.S n_cabs.S n_cbrt.S n_support.S n_sincos.S n_tan.S
> # XXX - ripped out due to lack of the insn polyd in the Mariah chip,
> # and emulation code isn't written yet.
> WARNS?=2
> .endif
>
> Above the n_atan2.S is ripped out, but...
>
> .if (${MACHINE_ARCH} == "vax") # XXX until POLYD is written.
> .PATH:  ${.CURDIR}/arch/vax
> SRCS:=${SRCS} n_sqrt.S n_argred.S n_infnan.S n_atan2.S n_cabs.S n_cbrt.S \
>         n_support.S
>
> Here it is included. Maybe this is the source of the problems.

The Makefile also includes some magic that causes it to use the .S
source even if you explicitly specify that you want the .c from the
noieee directory -- and the .c doesn't compile properly anyway,
because of multiple warnings generated by the compiler.  I haven't
gotten around to working this out yet, but I'll give it a try.

-tih
(Continue reading)


Gmane