freeze whle upgrading dbus 1.4.0 to 1.4.1

K

KernelPanic

This is on my FreeBSD 8.1-RELEASE i386 box:

Code: 
...
/usr/bin/ld: Warning: gc-sections option ignored
  CC     dbus_daemon-activation.o
  CC     dbus_daemon-bus.o
  CC     dbus_daemon-config-parser.o
  CC     dbus_daemon-config-parser-common.o
  CC     dbus_daemon-connection.o
  CC     dbus_daemon-desktop-file.o
  CC     dbus_daemon-dir-watch-kqueue.o
  CC     dbus_daemon-dispatch.o
  CC     dbus_daemon-driver.o
  CC     dbus_daemon-expirelist.o
  CC     dbus_daemon-policy.o
  CC     dbus_daemon-selinux.o
  CC     dbus_daemon-services.o
  CC     dbus_daemon-signals.o
  CC     dbus_daemon-test.o
  CC     dbus_daemon-utils.o
  CC     dbus_daemon-config-loader-expat.o
  CC     dbus_daemon-main.o
  CCLD   dbus-daemon
/usr/bin/ld: Warning: gc-sections option ignored
gmake[2]: Leaving directory `/usr/ports/devel/dbus/work/dbus-1.4.1/bus'
Making all in doc
gmake[2]: Entering directory `/usr/ports/devel/dbus/work/dbus-1.4.1/doc'
  GEN    dbus-cleanup-sockets.1.html

At this point it just hangs. The gmake processes are not consuming any CPU. Only a Ctrl-C will interrupt things.
 
Works here. If [cmd=]pkg_info -Ix libtool[/cmd] doesn't show libtool-2.2.10, see the 20101208 entry in /usr/ports/UPDATING.
 
That appears to be proper:
Code: 
pkg_info -Ix libtool
libtool-2.2.10      Generic shared library support script

I'm wondering if this might be machine related since I have a FreeBSD 7.3 i386 system that upgraded to dbus 1.4.1 without incident.
 
It freezes at the same place on my machine too.

Tried the test Warren suggested. Got libtool-2.2.10

This is on FreeBSD 8.2-PRERELEASE #0: Wed Dec 15 19:43:46 PST 2010 i386

I think that what's running (or trying to run) at this point in the build is man2html. My first attempt to upgrade dbus failed because man2html could not be found. So I installed textproc/man2html. (Why isn't this listed by the dbus port as a build dependency?) But then the build of the dbus port started to hang.

I tried cd'ing down into the work directory and manually running man2html. It spits out a bit of html but then hangs (doesn't return to shell prompt). man ./dbus-cleanup-sockets.1 has no trouble displaying the manpage, so it's presumably well-formed. But none of the info it contains is present in the partial output from man2html.

Perhaps textproc/man2html is not the tool expected to be used here?

I don't see anything on the freebsd-gnome mailing list and there doesn't seem to be a PR yet. If there's no quick resolution presented here, I'll go ahead and submit one. But I'm concerned that it apparently doesn't repro on all machines.
 
Confirm freeze when building dbus-1.4.1

Confirm same here on 8.1-RELEASE with GENERIC i386.
Did the same as ckester, but it did not help.
 
More info:

I get the same hanging result when I run textproc/man2html on some manpage files unrelated to the dbus port. So I'm focusing my attention on it rather than dbus.

Or, even more likely, that I need to fix something in my Perl kit.
 
fwiw, man2html hangs somewhere in what its sourcecode calls the "doitcode". I commented out line 253, where doitcode is eval'ed, and although it doesn't emit any of the manpage contents (as expected), man2html does exit back to the shell prompt.

I'll continue narrowing it down to see if I can isolate the problematic line(s). But meanwhile, can those of you who are seeing the same dbus build freeze try running man2html on a different manpage, just in case I'm chasing a red herring?
 
No man2html installed here, which may be why there were no problems. Excerpt from building dbus:
Code: 
...
checking whether to build XML documentation... no
checking for man2html... no
gnome-config: not found
...

If man2html isn't required for something else, try deinstalling it.
 
wblock said:
No man2html installed here, which may be why there were no problems. Excerpt from building dbus:
Code: 
...
checking whether to build XML documentation... no
checking for man2html... no
gnome-config: not found
...

If man2html isn't required for something else, try deinstalling it.
Click to expand...

Yep. Deinstalled man2html and now dbus update succeeds.

Which is exceedingly strange, because I know I didn't hallucinate the previous failure due to the missing man2html.

Deinstalling man2html works for me. Obviously I don't need it for anything else, since I only installed it because dbus seemed to want it.
 
If you do need html'ized versions of the dbus manpages, you can convert them after the update, using www/man2web.

man2web takes a slightly different argument than man2html. It expects the name of the program, while man2html expects the name of the manfile. So you can't just link man2html to man2web and have the dbus build work. Nor can you set MAN2HTML=/usr/local/bin/man2web, although dbus's configure script will use that environment variable.

(Yeah, I tried both approaches. :P)

There are probably some other converters out there that take the same args as man2html. If you find one and install it, then setting the environment variable should work with dbus.

Added Later:

One possibility is

# make MAN2HTML="/usr/local/bin/mandoc -Thtml" build

mandoc is from textproc/mdocml and takes the name of the manpage file as an argument. So it should work with the dbus build. But I haven't tested it.

Still later, on third thought :)
Looking at the Makefile and pkg-plist for the dbus port, I don't think it expects the html'ized manpages to ever be installed. So using the MAN2HTML environment variable to build them will probably result in pkg_delete errors later on. It's best to just not do it as part of the port build.

Use man2web, groff or mandoc after the install if you really want the webpages.

(And now I think I'm finally done commenting on this thread. :P)
 
Well, now I'm embarrassed.

Reading the manpage for man2html itself (something I should have done to begin with),
I noticed that it won't take a filename as input. It only works with stdin.

So this works:

$ man2html < foo.1 > foo.1.html

While this will appear to hang, because man2html is waiting for input:

$ man2html foo.1 > foo.1.html

Here are the lines in the Makefile dbus is using when it tries to build the html'ized pages:
Code: 
%.1.html: %.1
        $(AM_V_GEN)( $(MAN2HTML) $< > $@.tmp && mv $@.tmp $@ )
/usr/ports/devel/dbus/work/dbus-1.4.1/doc/Makefile:lines 611-612

This is a GNU makefile. $< is an automatic variable representing the first prerequisite. $@ represents the target. So you can see that if man2html is used for $(MAN2HTML) it will be given the prerequisite's filename rather than having the contents of that file passed to it on stdin. Therefore it will appear to hang.

It makes me wonder if there's some other version of man2html out there, one that does open and read a file specified on its commandline. If the dbus authors exercised this portion of the Makefile using the same man2html we have in ports, they would have seen the same failure we are.

Sorry for all the thinking-out-loud posts! But I'm a stubborn cuss, and can't rest until I get to the bottom of things.

Bottom line: textproc/man2html is not broken, despite my earlier suspicions. To upgrade dbus, however, you'll still need to deinstall it or at least hide it from dbus's configure script by temporarily renaming it to something else.

I'll submit a PR to have the dbus Makefile patched.
 
You must log in or register to reply here.
Back
Top