[comp.os.minix] 1.6 woes

asg@sage.cc.purdue.edu (The Grand Master) (06/25/91)

I am having problems installing Minix 1.6 .
I have the usual PH distribution of 1.5, running on an IBM PS/2.
It is a model 50Z (286)
Unfortunately I have the following problems:
when I compile fs or mm, I get the following:
unresolved references:
   __receive
   __send
   __sendrec

Now, I have checked out libc.a, and it does include these calls, but for
some reason, fs and mm are not recognizing them??!! 

My other problem is that my kernel/*.x files cannot be translated correctly.
I am trying to use the xenix_to_asld script provided by Andy on star.cs.vu.nl,
but I end up with empty .s files when I do. Anyone else run into a similar
problem?

Any help is greatly appreciated.

			Thanx
			  Bruce

SRONCH%HLERUL2.BITNET@vm.biu.ac.il (Fred Wiersma) (06/25/91)

Bruce ('The Grand Master') writes:
> I am having problems installing Minix 1.6 .
> I have the usual PH distribution of 1.5, running on an IBM PS/2.
> It is a model 50Z (286)
> Unfortunately I have the following problems:
> when I compile fs or mm, I get the following:
> unresolved references:
>    __receive
>    __send
>    __sendrec
>
> Now, I have checked out libc.a, and it does include these calls, but for
> some reason, fs and mm are not recognizing them??!!
>

In mm/mm.h send, receive and sendrec are redefined to _send, _receive
 and _sendrec, but the library sources have not (yet) been updated.
 You will have to update src/lib/ibm/<sendrec, catchsig, setjmp> :
 add an underscore to send, receive, sendrec, setjmp, begsig, and maybe
 others, regenerate libc.a (save the old one!) and make mm, fs and
 kernel.

> My other problem is that my kernel/*.x files cannot be translated correctly.
> I am trying to use the xenix_to_asld script provided by Andy on star.cs.vu.nl,
> but I end up with empty .s files when I do. Anyone else run into a similar
> problem?

The script worked fine for me.

>
> Any help is greatly appreciated.
>
> 			Thanx
> 			  Bruce

You're welcome.
I have one question myself: mknod4 is an unsolved reference when making
some commands (e.g. format, mknod, tar). When browsing some header files
(I think unistd.h) I saw a definition for either mknod or mknod4,
depending on whether _MINIX was defined. So I copied mknod.c to
mknod4.c, changed its mknod identifier to mknod4, recompiled and
regenerated libc.a. Then I could make the above mentioned commands. Was
what I did OK?

Fred
SRONCH@HLERUL2.BITNET
or
wiersma@compass.LeidenUniv.nl

sfreed@ariel.unm.edu (Steven Freed CIRT) (06/25/91)

In article <13930@mentor.cc.purdue.edu>, asg@sage.cc.purdue.edu (The Grand Master) writes:
> when I compile fs or mm, I get the following:  unresolved references:
     __receive
     __send
     __sendrec
  
> Now, I have checked out libc.a, and it does include these calls, but for
> some reason, fs and mm are not recognizing them??!! 

In your libc.a are they __receive __send __sendrec  or _receive _send 
_sendrec?

I really don't know the why for the "_" vs. "__" vs. "___"  But i figure
if I just follow the conventions being set, everything *should* fall into
place.

> My other problem is that my kernel/*.x files cannot be translated correctly.
> I am trying to use the xenix_to_asld script provided by Andy on star.cs.vu.nl,
> but I end up with empty .s files when I do. Anyone else run into a similar
> problem?

The xe-asld  stuff you pulled off star is very interesting. I would suppose
you unpacked it with unshar. If you look at the end of xenix_to_asld you 
will (should??) notice that the end is cut off, sort of stops dead in the
middle of the sed stuff. Now go back and get the original sources again
and use sh < file.from.star And I bet your results will be much better.
Seems to be an interesting bug with unshar... haven't investigated it 
yet, however.

You also will probably need to change the path(s) in the shell scripts,
but if you hadn't done that, it would have given you an obvious error
when run.
-- 

Steve.                    sfreed@ariel.unm.edu

asg@sage.cc.purdue.edu (The Grand Master) (06/26/91)

In article <57109@nigel.ee.udel.edu> SRONCH%HLERUL2.BITNET@vm.biu.ac.il (Fred Wiersma) writes:
}
}Bruce ('The Grand Master') writes:
}> I am having problems installing Minix 1.6 .
}> I have the usual PH distribution of 1.5, running on an IBM PS/2.
}> It is a model 50Z (286)
}> Unfortunately I have the following problems:
}> when I compile fs or mm, I get the following:
}> unresolved references:
}>    __receive
}>    __send
}>    __sendrec
}>
}> Now, I have checked out libc.a, and it does include these calls, but for
}> some reason, fs and mm are not recognizing them??!!
}>
}
}In mm/mm.h send, receive and sendrec are redefined to _send, _receive
} and _sendrec, but the library sources have not (yet) been updated.
} You will have to update src/lib/ibm/<sendrec, catchsig, setjmp> :
} add an underscore to send, receive, sendrec, setjmp, begsig, and maybe
} others, regenerate libc.a (save the old one!) and make mm, fs and
} kernel.
}
Ok - this worked, and fs compiled.
BUT
mm is still complaining about the following not being defined:
_sigemptyset
_sigdelset
_sigaddset
_sigismember

I tracked these down to signal.h, but for some reason, they are not 
being recognized at all.
They are defined like
_PROTOTYPE ( sigaddset, (some stuff here) );
Would someone who has gotten 1.6.16 to compile look through their source
and see if they can find a (better) definition for those procedures?


kernel is also complaining about these missing. 
And another very weird thing!
kernel complains about an unresolved reference to _putc
but I did a "grep putc *" and got NOTHING!!!!
How can there be an unresolved reference to it if I cannot find the reference?
In any event, would some kind sole o9ut there with th putc.c for kerrnel for
1.6.16 please email me a copy??
Thanx
			Bruce

---------
                                   ###             ##
Courtesy of Bruce Varney           ###               #
aka -> The Grand Master                               #
asg@sage.cc.purdue.edu             ###    #####       #
PUCC                               ###                #
;-)                                 #                #
;'>                                #               ##

HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (06/26/91)

putc is called via printk (a.k.a. printf) within the kernel.
C.v.W.

evans@syd.dit.CSIRO.AU (Bruce.Evans) (06/30/91)

In article <57109@nigel.ee.udel.edu> SRONCH%HLERUL2.BITNET@vm.biu.ac.il (Fred Wiersma) writes:
>
>I have one question myself: mknod4 is an unsolved reference when making
>some commands (e.g. format, mknod, tar). When browsing some header files
>(I think unistd.h) I saw a definition for either mknod or mknod4,
>depending on whether _MINIX was defined. So I copied mknod.c to
>mknod4.c, changed its mknod identifier to mknod4, recompiled and
>regenerated libc.a. Then I could make the above mentioned commands. Was
>what I did OK?

The change is correct, but the reasoning is not, and you also need to
re-create mknod:

	1.6 mknod4 = 1.5 mknod
	mknod(name, mode, addr) = mknod4(name, mode, address, 0)

Neither is declared (in unistd.h) unless _MINIX is defined, because POSIX
does not specify mknod.

The change was made to correct the misfeature of Minix-1.5's mknod being
different from everybody elses mknod. Calling mknod4 with a random size
causes interesting bugs (see e.g. test/test8.c).
-- 
Bruce Evans		evans@syd.dit.csiro.au