Re: Bootstrapping issues with groff(1)
Hi!
Attached is the patch for RELENG_4. It works but I don't like
how it pollutes the Makefile.inc1. Anyone with a better idea?
On Tue, Dec 12, 2000 at 09:43:55AM -0800, Marcel Moolenaar wrote:
Ruslan Ermilov wrote:
Let me rephrase the question: Did you modify the manpages to get it to
work with the new groff(1) or is the new groff(1) backward compatible
with the old groff(1)?
The new groff(1) is not always backwards compatible.
Ok, thanks. That's all I wanted to hear.
OK, I will augment the USRDIRS then, add the groff to bootstrap-tools,
and leave the better (if one exists) implementation to someone else.
Works for me.
thanks,
--
Marcel Moolenaar
mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
tel: (408) 447-4222
On Wed, Jan 24, 2001 at 06:27:29PM +0100, [EMAIL PROTECTED] wrote:
Hi. did you get any chance to fix the problem discussed earlier yet?
I'm currently trying to buildworld on sources gootten with CVSup, using
this supfile:
# Defaults that apply to all the collections
*default host=cvsup.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_4
*default delete use-rel-suffix
*default compress
## The international secure collections.
src-all
buildworld fails as follows;
=== share/doc/usd/12.vi/summary
touch _stamp.extraobjs
(cd
/usr/src/share/doc/usd/12.vi/summary/../../../../../contrib/nvi/docs/USD.doc/vitut;
groff -mtty-char -Tascii -t -ms -o1-
/usr/src/share/doc/usd/12.vi/summary/../../../../../contrib/nvi/docs/USD.doc/vitut/vi.summary)
| gzip -cn summary.ascii.gz
=== share/doc/usd/13.viref
(cd
/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref;
sed -e\ 's:\(\.so[\ \ ][\ \
]*\)\(vi.ref\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:'
-e\ 's:\(\.so[\ \][\ \
]*\)\(ex.cmd.roff\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:'
-e\ 's:\(\.so[\ \][\ \
]*\)\(ref.so\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:'
-e\ 's:\(\.so[\ \][\ \
]*\)\(set.opt.roff\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:'
-e\ 's:\(\.so[\ \ ][\ \
]*\)\(vi.cmd.roff\)$:\1/usr/src/share/doc/usd/13.viref/../../../../contrib/nvi/docs/USD.doc/vi.ref/\2:'
-e 's:^\.so index.so$::' vi.ref) | groff -mtty-char -Tascii -t -s -me -U
-o1- /dev/null
groff: illegal option -- U
usage: groff [-abehilpstvzCENRSVXZ] [-Fdir] [-mname] [-Tdev] [-ffam]
[-wname]
[-Wname] [ -Mdir] [-dcs] [-rcn] [-nnum] [-olist] [-Parg] [-Larg]
[files...]
groff -h gives more help
*** Error code 1
Stop.
Can you please help me out here?
On Sat, Dec 16, 2000 at 05:15:26PM +0200, Ruslan Ermilov wrote:
On Sat, Dec 16, 2000 at 01:28:16PM +0100, [EMAIL PROTECTED] wrote:
Hi.
I'm having a hell of a time upgrading my 3.4-STABLE box to 4.2-STABLE.
My latest blues concern groff, for which I saw you posting a patch on
the freeBSD questions mailing list on the 9th of December.
I hope this patch solved the problem, I did not see any messages on that.
Unfortunately, you do not post instructions to apply the patch. I'm hoping
to get them out of you via this email ;-)
I am planning to commit the fix to 5.0-CURRENT and 4.2-STABLE shortly.
I will send you a notice after I do this.
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.141.2.19
diff -u -p -r1.141.2.19 Makefile.inc1
--- Makefile.inc1 2001/01/22 23:26:15 1.141.2.19
+++ Makefile.inc1 2001/01/25 12:16:07
@@ -168,6 +168,8 @@ CROSSENV= MAKEOBJDIRPREFIX=${OBJTREE} \
COMPILER_PATH=${WORLDTMP}/usr/libexec:${WORLDTMP}/usr/bin \
LIBRARY_PATH=${WORLDTMP}${SHLIBDIR}:${WORLDTMP}/usr/lib \
OBJFORMAT_PATH=${WORLDTMP}/usr/libexec \
+ GROFF_FONT_PATH=${WORLDTMP}/usr/share/groff_font \
+ GROFF_TMAC_PATH=${WORLDTMP}/usr/share/tmac \
PERL5LIB=${WORLDTMP}/usr/libdata/perl/5.00503
# bootstrap-tool stage
@@ -199,7 +201,24 @@ IMAKEENV= ${CROSSENV} \
IMAKE= ${IMAKEENV} ${MAKE} -f Makefile.inc1
USRDIRS= usr/bin usr/lib/compat/aout
Re: Bootstrapping issues with groff(1)
[I don't know why -current is CC'd this is clearly about -stable] Ruslan Ermilov wrote: Attached is the patch for RELENG_4. It works but I don't like how it pollutes the Makefile.inc1. Anyone with a better idea? Allow me to sidetrack for a moment: I just ugraded a machine from 4.1 to 4.2-stable without any problems. I'm a bit confused. Rene picks up RELENG_4 and sees his build fail. Why did it work for me? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Mon, Dec 11, 2000 at 09:07:53AM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: On Sat, Dec 09, 2000 at 12:29:54PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). Sorry, I missed this statement before. What exactly are the bootstrapping problems you're seeing? New groff(1) provides new versions of macro packages and device files. When building, we should use THEM rather than installed (obsolete) ones. Is the old groff(1) incompatible with the new groff(1) in the sense that manpages created with the old groff(1) are visibly different from the manpages created with the new groff(1)? Once again. groff(1) supplies macro packages and device description files. New groff is likely to provide modified files. This, I don't care about. We're never going to use an old groff(1) with the new files or vice versa. From a usage point of view, I don't care about the implementation, just the interface. Let me rephrase the question: Did you modify the manpages to get it to work with the new groff(1) or is the new groff(1) backward compatible with the old groff(1)? The new groff(1) is not always backwards compatible. For example, new groff(1) implements .psbb request internally in troff(1), thus -U flag is no longer required for part of share/doc, and was removed. The new groff(1) also supplies an updated version of doc(7) macro package (the package we use for manpages), and if you build world with MANBUILDCAT, you will definitely need the new version of tmac.doc and friends. OK, I will augment the USRDIRS then, add the groff to bootstrap-tools, and leave the better (if one exists) implementation to someone else. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Mon, Dec 11, 2000 at 09:12:17AM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: It appers that running mtree(1) with -U under non-root account works OK, i.e. it creates all missing directories, and exits with status of zero. I believe it also emits warnings, right? What if we create the mtree(1)-compatible BSD.world.dist? The below was generated by ``mtree -cdin -k type,mode'' under 4.2-STABLE. You mean a special mtree file for use by the build? Maybe I'm missing something, but doesn't that also duplicate information, or can you generate this subset on the fly? Forget it, it was a bad idea. I though it won't require ``uname'', but it does. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Ruslan Ermilov wrote: Let me rephrase the question: Did you modify the manpages to get it to work with the new groff(1) or is the new groff(1) backward compatible with the old groff(1)? The new groff(1) is not always backwards compatible. Ok, thanks. That's all I wanted to hear. OK, I will augment the USRDIRS then, add the groff to bootstrap-tools, and leave the better (if one exists) implementation to someone else. Works for me. thanks, -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Tue, Dec 12, 2000 at 10:23:44AM +0200, Ruslan Ermilov wrote: OK, I will augment the USRDIRS then, add the groff to bootstrap-tools, and leave the better (if one exists) implementation to someone else. Why does groff need to be a bootstrap-tool? Its not like we need to build manpages that early in the build. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
David O'Brien wrote: On Tue, Dec 12, 2000 at 10:23:44AM +0200, Ruslan Ermilov wrote: OK, I will augment the USRDIRS then, add the groff to bootstrap-tools, and leave the better (if one exists) implementation to someone else. Why does groff need to be a bootstrap-tool? Its not like we need to build manpages that early in the build. There's no other place. Only bootstrap tools, cross tools and build tools are build in such a way that they can run on the build machine. You can't build it later than cross-tools. It's not a cross tool itself and definitely not a build tool. It must be a bootstrap tool then. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Marcel Moolenaar wrote: Why does groff need to be a bootstrap-tool? Its not like we need to build manpages that early in the build. There's no other place. Only bootstrap tools, cross tools and build tools are build in such a way that they can run on the build machine. You can't build it later than cross-tools. It's not a cross tool itself and definitely not a build tool. It must be a bootstrap tool then. It is used to build the man pages, isn't it? Why, then, it is not a build tool? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
"Daniel C. Sobral" wrote: There's no other place. Only bootstrap tools, cross tools and build tools are build in such a way that they can run on the build machine. You can't build it later than cross-tools. It's not a cross tool itself and definitely not a build tool. It must be a bootstrap tool then. It is used to build the man pages, isn't it? Why, then, it is not a build tool? Build tools are utilities created only for the purpose of building "the software". Build tools are never installed on the system. Put differently; build tools don't have makefiles of their own. groff(1) definitely isn't a build tool, because it has it's own makefiles and is installed on the system. There's an implementation difference as well. Bootstrap tools are built in seperate object directories to avoid problems with the actual built of the tool (as part of stage 4 of make world). Build tools are always built in the "normal" or actual object directory. Also, bootstrap tools are installed under the object tree. Build tools are not installed; they run from the object directory. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Sat, Dec 09, 2000 at 12:29:54PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). Sorry, I missed this statement before. What exactly are the bootstrapping problems you're seeing? New groff(1) provides new versions of macro packages and device files. When building, we should use THEM rather than installed (obsolete) ones. Is the old groff(1) incompatible with the new groff(1) in the sense that manpages created with the old groff(1) are visibly different from the manpages created with the new groff(1)? Once again. groff(1) supplies macro packages and device description files. New groff is likely to provide modified files. The typical build system uses groff(1) to build documentation (unless you have NO_SHAREDOCS defined). If, additionally, one has MANBUILDCAT set to some value, ``make world'' will build and install preformatted manual pages. So the answer to your question is: yes for BSD docs, and "probably" for manual pages. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On 10 Dec 2000, Dag-Erling Smorgrav wrote: Marcel Moolenaar [EMAIL PROTECTED] writes: According to the manpage, if you remove -U it doesn't create new directories or symlinks. At least that's how I interpret it. You interpret it wrong. -U just tells mtree to fix permissions. The canonical way to use the mtree files in /etc/mtree is 'mtree -deU -f file -p path', e.g. 'mtree -deU -f /etc/mtree/BSD.root.dist -p /'. No. (1) -U (and -u) tell mtree to update the hierarchy. It doesn't change anything unless one of these flags is specified. (2) -U is the special FreeBSD exit-no-evil (*) way which is mainly for handling the problem under discussion: mtree -U ignores certain errors (*) so that makeworld can use mtree without having to worry about permissions. The canonical way is `mtree -deu ...'. The manpage gives too much emphasis to -U over -u. (*) verify() doesn't return any errors other than the one canceled by -U. Consequently, -U doesn't actually do anything useful. Using it is equivalent to ignoring the exit status of mtree except for usage errors. Serious errors such as missing files have apparently never been reflected in mtree's exit status. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Sat, Dec 09, 2000 at 12:43:24PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: On Fri, Dec 08, 2000 at 06:17:52PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). I have lightly tested this on my -stable box, and would appreciate a feedback on them. Do not remove the USRDIRS and INCDIRS and replace it with mtree (ie make hierarchy). There's no need to duplicate the complete hierarchy inthe object tree. Also, mtree fiddles with ownership and mods, which is not appropriate when building. The -U flag to mtree(8) could be eliminated for this case... According to the manpage, if you remove -U it doesn't create new directories or symlinks. At least that's how I interpret it. The whole purpose of running mtree is the creation of directories, so it's a minor discomfort when it doesn't do that :-) It appers that running mtree(1) with -U under non-root account works OK, i.e. it creates all missing directories, and exits with status of zero. Which additional directories do you need? Everyting below /usr/share/tmac and /usr/share/groff_font: [snip] The new groff(1) release is likely to provide new groff_font subdirectories, so we would need to update USRDIRS every time we upgrade groff(1). Does it look reasonable? If we intend to upgrade groff(1) once a week, no. If we do it once a year, yes. It's is a long list of directories and I prefer we do not need to sum them up in src/Makefile.inc1. On the other hand, I also don't want to use mtree. This is what I'm thinking about: 1. Determine if there's a real bootstrapping problem 2. If there's no bootstrapping issue, goto pub :-) 3. Add list of directories to src/Makefile.inc1 4. Write script to parse mtree files for use in build 5. If not possible, reconsider using mtree 6. else, replace lists by running the script. Thoughts? What if we create the mtree(1)-compatible BSD.world.dist? The below was generated by ``mtree -cdin -k type,mode'' under 4.2-STABLE. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age # $FreeBSD$ /set type=dir mode=0755 . usr bin .. games .. include arpa .. g++ std .. .. objc .. openssl .. protocols .. readline .. rpc .. rpcsvc .. security .. ss .. .. lib compat aout .. .. .. libdata ldscripts .. .. libexec elf .. .. sbin .. share groff_font devX100 .. devX100-12 .. devX75 .. devX75-12 .. devascii .. devcp1047 .. devdvi .. devhtml .. devkoi8-r .. devlatin1 .. devlbp .. devlj4 .. devps .. devutf8 .. .. misc .. tmac locale .. mdoc locale .. .. mm .. .. .. src usr.bin yacc .. .. .. .. ..
Re: Bootstrapping issues with groff(1)
On Sat, Dec 09, 2000 at 10:11:28PM -0800, Thomas D. Dean wrote: I have no environment settings that relate to groff and only MANPATH that relates to man. There are no local modifications. etc/make.conf only has CFLAGS= -O -pipe HAVE_MOTIF= yes MOTIF_STATIC= yes USA_RESIDENT= YES WRKDIRPREFIX= /usr/obj/ports NO_MODULES= NO I have always done cvsup followed by 'make world'. # cd /usr/src/gnu/usr.bin # make clean # cd /usr/src # make -DNOCLEAN world fixed the problem. Before, I used 'make -j36 -DNOCLEAN world'. Could it be a problem with the Makefile in man? Yes, because only Makefile in gnu/usr.bin/man has changed, and not its sources. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Ruslan Ermilov wrote: On Sat, Dec 09, 2000 at 12:29:54PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). Sorry, I missed this statement before. What exactly are the bootstrapping problems you're seeing? New groff(1) provides new versions of macro packages and device files. When building, we should use THEM rather than installed (obsolete) ones. Is the old groff(1) incompatible with the new groff(1) in the sense that manpages created with the old groff(1) are visibly different from the manpages created with the new groff(1)? Once again. groff(1) supplies macro packages and device description files. New groff is likely to provide modified files. This, I don't care about. We're never going to use an old groff(1) with the new files or vice versa. From a usage point of view, I don't care about the implementation, just the interface. Let me rephrase the question: Did you modify the manpages to get it to work with the new groff(1) or is the new groff(1) backward compatible with the old groff(1)? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Ruslan Ermilov wrote: It appers that running mtree(1) with -U under non-root account works OK, i.e. it creates all missing directories, and exits with status of zero. I believe it also emits warnings, right? What if we create the mtree(1)-compatible BSD.world.dist? The below was generated by ``mtree -cdin -k type,mode'' under 4.2-STABLE. You mean a special mtree file for use by the build? Maybe I'm missing something, but doesn't that also duplicate information, or can you generate this subset on the fly? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: using mtree in our builds [was: Re: Bootstrapping issues with groff(1)]
David O'Brien wrote: On Sat, Dec 09, 2000 at 07:59:46PM -0800, Marcel Moolenaar wrote: The only thing you don't like about mtree is it changing ownership + modes, right? Not only that. Using mtree(1) creates busloads of unnecessary directories. But they're harmless. While I agree it is clutter, having to duplicate its work in the Makefile's with lists of dirs to create just seems like a duplication and waste of effort; If the list is short (as it is now), there's no real problem, but if there's a real bootstrapping issue with groff(1) and we need to add 10+ directories, then it will become a more serious issue and I think that a better solution is called for in that case. and even an little NIH as mtree is rather ingrained in BSD. NIH has nothing to do with it. To me it seems that mtree(1) is designed for a different purpose. Yes, it so happens that mtree can create directories, but that's not the root purpose of the tool. And yet, that's the only reason we'll use mtree(1) in the build (at all?). Adding features to mtree to have it better function in our builds only adds to the bootstrapping overhead, and all we really want to reuse is the directory structure information in our BSD.*.dist files. If the effort to write a small script is of the same order as patching mtree, then I prefer the small script... -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Marcel Moolenaar [EMAIL PROTECTED] writes: According to the manpage, if you remove -U it doesn't create new directories or symlinks. At least that's how I interpret it. You interpret it wrong. -U just tells mtree to fix permissions. The canonical way to use the mtree files in /etc/mtree is 'mtree -deU -f file -p path', e.g. 'mtree -deU -f /etc/mtree/BSD.root.dist -p /'. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Fri, Dec 08, 2000 at 06:17:52PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). I have lightly tested this on my -stable box, and would appreciate a feedback on them. Do not remove the USRDIRS and INCDIRS and replace it with mtree (ie make hierarchy). There's no need to duplicate the complete hierarchy inthe object tree. Also, mtree fiddles with ownership and mods, which is not appropriate when building. The -U flag to mtree(8) could be eliminated for this case... Which additional directories do you need? Everyting below /usr/share/tmac and /usr/share/groff_font: /usr/share/tmac /usr/share/tmac/locale /usr/share/tmac/mdoc /usr/share/tmac/mdoc/locale /usr/share/tmac/mm /usr/share/groff_font /usr/share/groff_font/devX100 /usr/share/groff_font/devX100-12 /usr/share/groff_font/devX75 /usr/share/groff_font/devX75-12 /usr/share/groff_font/devascii /usr/share/groff_font/devcp1047 /usr/share/groff_font/devdvi /usr/share/groff_font/devhtml /usr/share/groff_font/devkoi8-r /usr/share/groff_font/devlatin1 /usr/share/groff_font/devlbp /usr/share/groff_font/devlj4 /usr/share/groff_font/devps /usr/share/groff_font/devutf8 The new groff(1) release is likely to provide new groff_font subdirectories, so we would need to update USRDIRS every time we upgrade groff(1). Does it look reasonable? -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). Sorry, I missed this statement before. What exactly are the bootstrapping problems you're seeing? New groff(1) provides new versions of macro packages and device files. When building, we should use THEM rather than installed (obsolete) ones. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Ruslan Ermilov wrote: On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). Sorry, I missed this statement before. What exactly are the bootstrapping problems you're seeing? New groff(1) provides new versions of macro packages and device files. When building, we should use THEM rather than installed (obsolete) ones. Is the old groff(1) incompatible with the new groff(1) in the sense that manpages created with the old groff(1) are visibly different from the manpages created with the new groff(1)? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Is this the problem I see with mal-formatted man pages? The pages appear as 1 block with no headers, tities, etc. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
"Thomas D. Dean" wrote: Is this the problem I see with mal-formatted man pages? Possibly. I don't know if we changed files to get our sources working with the new groff(1). If we did, we definitely have a bootstrapping problem, because that would mean that we can't reliably create manpages with the old groff(1). If this is the case for you, then remaking the manpages with the new groff(1) should solve your problem. If that doesn't help, then you have to give us more information to work on. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
# ls /usr/share/man/man*/zzz* /usr/share/man/man8/zzz.8.gz # ls /usr/share/man/cat*/zzz* ls: No match. Ok, so, man zzz should reformat the man page. I have attached the output of 'man -d zzz' and 'man zzz' After 'man zzz', I see # ls /usr/share/man/cat*/zzz* /usr/share/man/cat8/zzz.8.gz So, the man page was reformatted with the new groff. tomdean === # man -d zzz ctype locale env: Invalid argument using more as pager found mandatory man directory /usr/share/man found mandatory man directory /usr/share/perl/man found optional man directory /usr/local/lib/perl5/5.00503/man found manpath map /bin -- /usr/share/man found manpath map /usr/bin -- /usr/share/man found manpath map /usr/local/bin -- /usr/local/man found manpath map /usr/X11R6/bin -- /usr/X11R6/man search path for pages determined by manpath is /usr/home/tomdean/man:/usr/local/man:/usr/share/man:/usr/X11R6/man:/usr/local/LessTif/doc/man:/usr/local/pgsql/man adding /usr/home/tomdean/man to manpathlist adding /usr/local/man to manpathlist adding /usr/share/man to manpathlist adding /usr/X11R6/man to manpathlist Warning: couldn't stat file /usr/local/LessTif/doc/man! adding /usr/local/pgsql/man to manpathlist searching in /usr/home/tomdean/man trying section 1 with globbing globbing /usr/home/tomdean/man/man1/zzz.1* globbing /usr/home/tomdean/man/man1/zzz.0* globbing /usr/home/tomdean/man/cat1/zzz.1* globbing /usr/home/tomdean/man/cat1/zzz.0* searching in /usr/local/man trying section 1 with globbing globbing /usr/local/man/man1/zzz.1* globbing /usr/local/man/man1/zzz.0* globbing /usr/local/man/cat1/zzz.1* globbing /usr/local/man/cat1/zzz.0* searching in /usr/share/man trying section 1 with globbing globbing /usr/share/man/man1/zzz.1* globbing /usr/share/man/man1/zzz.0* globbing /usr/share/man/cat1/zzz.1* globbing /usr/share/man/cat1/zzz.0* searching in /usr/X11R6/man trying section 1 with globbing globbing /usr/X11R6/man/man1/zzz.1* globbing /usr/X11R6/man/man1/zzz.0* globbing /usr/X11R6/man/cat1/zzz.1* globbing /usr/X11R6/man/cat1/zzz.0* searching in /usr/local/pgsql/man trying section 1 with globbing globbing /usr/local/pgsql/man/man1/zzz.1* globbing /usr/local/pgsql/man/man1/zzz.0* globbing /usr/local/pgsql/man/cat1/zzz.1* globbing /usr/local/pgsql/man/cat1/zzz.0* searching in /usr/home/tomdean/man trying section 1aout with globbing globbing /usr/home/tomdean/man/man1aout/zzz.1aout* globbing /usr/home/tomdean/man/man1aout/zzz.0* globbing /usr/home/tomdean/man/cat1aout/zzz.1aout* globbing /usr/home/tomdean/man/cat1aout/zzz.0* searching in /usr/local/man trying section 1aout with globbing globbing /usr/local/man/man1aout/zzz.1aout* globbing /usr/local/man/man1aout/zzz.0* globbing /usr/local/man/cat1aout/zzz.1aout* globbing /usr/local/man/cat1aout/zzz.0* searching in /usr/share/man trying section 1aout with globbing globbing /usr/share/man/man1aout/zzz.1aout* globbing /usr/share/man/man1aout/zzz.0* globbing /usr/share/man/cat1aout/zzz.1aout* globbing /usr/share/man/cat1aout/zzz.0* searching in /usr/X11R6/man trying section 1aout with globbing globbing /usr/X11R6/man/man1aout/zzz.1aout* globbing /usr/X11R6/man/man1aout/zzz.0* globbing /usr/X11R6/man/cat1aout/zzz.1aout* globbing /usr/X11R6/man/cat1aout/zzz.0* searching in /usr/local/pgsql/man trying section 1aout with globbing globbing /usr/local/pgsql/man/man1aout/zzz.1aout* globbing /usr/local/pgsql/man/man1aout/zzz.0* globbing /usr/local/pgsql/man/cat1aout/zzz.1aout* globbing /usr/local/pgsql/man/cat1aout/zzz.0* searching in /usr/home/tomdean/man trying section 8 with globbing globbing /usr/home/tomdean/man/man8/zzz.8* globbing /usr/home/tomdean/man/man8/zzz.0* globbing /usr/home/tomdean/man/cat8/zzz.8* globbing /usr/home/tomdean/man/cat8/zzz.0* searching in /usr/local/man trying section 8 with globbing globbing /usr/local/man/man8/zzz.8* globbing /usr/local/man/man8/zzz.0* globbing /usr/local/man/cat8/zzz.8* globbing /usr/local/man/cat8/zzz.0* searching in /usr/share/man trying section 8 with globbing globbing /usr/share/man/man8/zzz.8* to_name in convert_name () is: /usr/share/man/cat8/zzz.8.gz will try to write /usr/share/man/cat8/zzz.8.gz if needed status from is_newer() = -2 using default preprocessor sequence mode of /usr/share/man/cat8/zzz.8.gz.tmpwUNTCA is now 644 Formatting page, please wait... trying command: (cd /usr/share/man ; /usr/bin/zcat /usr/share/man/man8/zzz.8.gz | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | /usr/bin/col | /usr/bin/gzip -c) No output, debug mode. using default preprocessor sequence Couldn't open /usr/share/man/cat8/zzz.8.gz.tmpB0cdyZ for writing. using default preprocessor sequence trying command: (cd /usr/share/man ; /usr/bin/zcat /usr/share/man/man8/zzz.8.gz | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | /usr/bin/col | more) = # man zzz Formatting page, please wait...Done. controls the Intel / Microsoft APM (Advanced Power
Re: Bootstrapping issues with groff(1)
"Thomas D. Dean" wrote: trying command: (cd /usr/share/man ; /usr/bin/zcat /usr/share/man/man8/zzz.8.gz | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | ... should be -mandoc trying command: (cd /usr/share/man ; /usr/bin/zcat /usr/share/man/man8/zzz.8.gz | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | ... should be -mandoc -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
/usr/bin/groff -S -Wall -mtty-char -man -Tascii | ... should be -mandoc This was generated by 'man', not me. There appears to be a problem in man. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Sat, Dec 09, 2000 at 12:43:24PM -0800, Marcel Moolenaar wrote: On the other hand, I also don't want to use mtree. The only thing you don't like about mtree is it changing ownership + modes, right? If so, what about a new flag to mtree to make it only create directories and nothing else? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
David O'Brien wrote: On Sat, Dec 09, 2000 at 12:43:24PM -0800, Marcel Moolenaar wrote: On the other hand, I also don't want to use mtree. The only thing you don't like about mtree is it changing ownership + modes, right? Not only that. Using mtree(1) creates busloads of unnecessary directories. It's too brute-force in my book. If there's a clean way to create selective subtrees and do that without setting ownership and file mods, then I'm happy. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
"Thomas D. Dean" wrote: /usr/bin/groff -S -Wall -mtty-char -man -Tascii | ... should be -mandoc This was generated by 'man', not me. I understand that. There appears to be a problem in man. Not that I'm aware of. Did you verify your settings? ie build options env.vars and local modifications? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
I have no environment settings that relate to groff and only MANPATH that relates to man. There are no local modifications. etc/make.conf only has CFLAGS= -O -pipe HAVE_MOTIF= yes MOTIF_STATIC= yes USA_RESIDENT= YES WRKDIRPREFIX= /usr/obj/ports NO_MODULES= NO I have always done cvsup followed by 'make world'. # cd /usr/src/gnu/usr.bin # make clean # cd /usr/src # make -DNOCLEAN world fixed the problem. Before, I used 'make -j36 -DNOCLEAN world'. Could it be a problem with the Makefile in man? Next week, I will do a cvsup, etc. I will use -j36 and see if it changes anything. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
"Thomas D. Dean" wrote: # cd /usr/src/gnu/usr.bin # make clean # cd /usr/src # make -DNOCLEAN world fixed the problem. Before, I used 'make -j36 -DNOCLEAN world'. Could it be a problem with the Makefile in man? -DNOCLEAN is not guaranteed to work. Especially when makefiles change. Use with care! -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). I have lightly tested this on my -stable box, and would appreciate a feedback on them. Do not remove the USRDIRS and INCDIRS and replace it with mtree (ie make hierarchy). There's no need to duplicate the complete hierarchy inthe object tree. Also, mtree fiddles with ownership and mods, which is not appropriate when building. Which additional directories do you need? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). Sorry, I missed this statement before. What exactly are the bootstrapping problems you're seeing? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
:Ruslan Ermilov wrote: : : The attached patches (p4 and p5) try to solve this bootstrapping : problem with groff(1). : :Sorry, I missed this statement before. What exactly are the :bootstrapping problems you're seeing? : :-- :Marcel Moolenaar : mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] : tel: (408) 447-4222 I just ran into this problem trying to build the world: -Matt /usr/src/gnu/usr.bin/groff# make === libgroff === libdriver === libbib === addftinfo === afmtodit === doc === eqn c++ -O -pipe -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 -DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/include -I/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn -I. -fno-for-scope -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:22: eqn_tab.h: No such file or directory /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:57: `OVER' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:58: `SMALLOVER' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:59: `SQRT' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:60: `SUB' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:61: `SUP' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:62: `LPILE' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:63: `RPILE' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:64: `CPILE' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:65: `PILE' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:66: `LEFT' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:67: `RIGHT' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:68: `TO' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:69: `FROM' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:70: `SIZE' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:71: `FONT' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:72: `ROMAN' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:73: `BOLD' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:74: `ITALIC' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:75: `FAT' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:76: `BAR' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:77: `UNDER' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:78: `ACCENT' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:79: `UACCENT' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:80: `ABOVE' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:81: `FWD' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:82: `BACK' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:83: `DOWN' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:84: `UP' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:85: `MATRIX' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:86: `COL' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:87: `LCOL' was not declared in this scope /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:88: `RCOL' was not declared in this scope
Re: Bootstrapping issues with groff(1)
Matt Dillon wrote: /usr/src/gnu/usr.bin/groff# make === libgroff === libdriver === libbib === addftinfo === afmtodit === doc === eqn c++ -O -pipe -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 -DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/include -I/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn -I. -fno-for-scope -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:22: eqn_tab.h: No such file or directory /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:57: `OVER' was not declared in this scope Hmmm... I don't see this. This is more a build problem than a bootstrapping problem. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Matt Dillon [EMAIL PROTECTED] writes: c++ -O -pipe -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 -DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/include -I/usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn -I. -fno-for-scope -fno-rtti -fno-exceptions -c /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc /usr/src/gnu/usr.bin/groff/eqn/../../../../contrib/groff/eqn/lex.cc:22: eqn_tab.h: No such file or directory I got rid of that with 'rm *' in /usr/obj/usr/src/gnu/usr.bin/groff/eqn. /assar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
