Another attempt [Re: Groff is not working in the latest code]
alex-goncharov at comcast.net
Wed Aug 27 15:12:00 UTC 2008
The bottom line: the problem is solved -- thank you!
The details below...
,--- You/Yuri (Wed, 27 Aug 2008 08:13:14 +0400) ----*
| Alex Goncharov wrote:
| > `groff' is still not working for me, and with it `man' doesn't:
| > So, I looked at how things are being built and think that the
| > following is supposed to happen with respect to `groff' -- a GNU
| > program:
| > 1. The build is driven by `gnu/usr.bin/groff/Makefile' (all paths in
| > the following are relative to `/usr/src'.
| > 2. During the build, the original "contrib" code is used, to be found
| > in `contrib/groff'.
| > That code is configured by the pristine `contrib/groff/configure'
| > and results in setting the "prefix" to the GNU-usual `/usr/local'
| > and generating the FreeBSD-unaware `defs.h' and `config.h'.
| contrib/groff/configure shouldn't be called at all,
Let me ask you here: what should be called then?
Note this for the make file there:
$ cat contrib/groff/Makefile
| looks like there's something wrong with your local build
This is what I was trying to find: the same environment hadn't given
me trouble for more than a year, till about August 15 -- and leads to
a good build this morning.
Why would my environment matter for a standard build, however? Which
part of it?
| > 3. Then some magic "is supposed to happen / was happening two weeks
| > ago for me", when the newly generated `defs.h' and `config.h' are
| > replaced with the FreeBSD hard versions that had been delivered
| > from CVS -- and the paths get corrected to eliminate the `local'
| > component from them and do other path adjustments to bring it all
| > to the FreeBSD standards:
| > --------------------
| > $ diff contrib/groff/src/include/defs.h gnu/usr.bin/groff/src/include/defs.h | head -n 12
| yuri:/usr/src> diff -u contrib/groff/src/include/defs.h
| diff: contrib/groff/src/include/defs.h: No such file or directory
When I saw this, and combining this with your statement that
`contrib/groff/configure' was not supposed to be called, I realized
that, in fact, yesterday I ran it by hand, trying to figure out what
was going on -- and I thought it had to be called by the standard
So, seeing your output, I removed both `contrib/groff' and
`gnu/usr.bin/groff', did `cvsup' again and rebuild.
And guess what? The newly built groff doesn't look for files under
`/usr/local' -- so it's definitely using the hard-coded`
I install worlds and now have a perfectly functioning `groff' and
| > But how about others: everything works for you? What could have
| > triggered the change in the process for me a week or so ago?
| `man man` works for me on 7.0-RELEASE with groff built from RELENG_7
It did help enormously -- just a simple knowledge that `groff' works
for you and comparing the small notes.
(But it's still a mystery for me why I was having bad builds for two
weeks -- what led me in, and what led me out of the trouble.
And the build process for `groff' remains a puzzle for me... Will try
to understand it better...)
Thank you very much!
-- Alex -- alex-goncharov at comcast.net --
More information about the freebsd-stable