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
[snip]
all:
$(SHELL) configure
$(MAKE) all
| looks like there's something wrong with your local build
| environment.
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
| gnu/usr.bin/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
build.
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`
gnu/usr.bin/groff/src/include/defs.h' paths.
I install worlds and now have a perfectly functioning `groff' and
`man'.
| > 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
| src.
| HTH,
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 -- [EMAIL PROTECTED] --
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
