Re: [htdig] Bad Pathname in htsearch output

Douglas Kline (
Thu, 13 May 1999 19:55:30 -0400

[Retaining your text rather than deleting it to save space so that the context
and history is clear]

> According to Douglas Kline:
> > However I don't understand why this failed to work before. I have the line
s in
> > htcommon/ which you cite. I ran the make after setting the CONF
> > file and the Makefile and .o files in htcommon are dated after the CONFIG f
> > star_image and star_blank were not defined in the htdig.conf file at all.
> > it got the URL right for the star in the line, "More *'s indicate a better
> > match." Does it get the URL for the star in that line from a different rou
> > than for the output lines even though it should be the same URL?
> Yes, it gets the IMAGE_URL_PREFIX value from the CONFIG file using a very
> different route for that message. In both cases, Makefile.config includes
> CONFIG, which gives make the definition for IMAGE_URL_PREFIX. However, for
> the "More *'s indicate a better match" message, the top level Makefile
> (which includes Makefile.config) passes IMAGE_URL_PREFIX to a "sed"
> command during a "make install". This sed command changes all occurrences
> of @IMAGEDIR@ to the value of IMAGE_URL_PREFIX in all installdir/*.html
> files that it copies into the "common" directory. There's no C or C++
> code involved here, and no compilation. When htsearch ouputs the search
> results, it outputs the contents of the installed header.html, which has
> the correct path in it.
> For the compiled in defaults, in htcommon/, htcommon/Makefile
> (which also includes Makefile.config) passes IMAGE_URL_PREFIX to the
> compiler as -DIMAGE_URL_PREFIX=\"$(IMAGE_URL_PREFIX)\", and that's how
> the default attribute image_url_prefix gets set in

OK. That explains the divergence between how it gets the URL for the stars
for the two kinds of places they show up.

> > Your last conjecture, "A third possibility may be that your make program di
> > properly include the CONFIG definitions, or didn't pass them on to the comp
> > for whatever reason," may be the only answer although even that doesn't exp
> > how it got one star line right and the other wrong. However we know that t
> > make picked up the IMAGE_URL_PREFIX from the CONFIG file because it was app
> > in at least some places. Maybe it was not passed on to the compiler.
> After looking into it further, this possibility seems less likely.
> The two big differences I can see in how make picks up the value of
> IMAGE_URL_PREFIX are that for header.html, it's done by the top level
> Makefile during a "make install", while for, it's done by
> htcommon/Makefile during a "make" in the compilation stage.
> If make didn't properly pick up the value of IMAGE_URL_PREFIX, or didn't
> pass it on correctly to the compiler, there would be no other default
> value to take its place, so the compilation would abort.

Is that necessarily true? The value it had was a pathname starting with
"/htdig" which seems to be a default and will work if that is defined as an
alias on the http server and is in fact used on the htdig Web site. Mightn't
the compilation be using such a default such that it would complete without a
definition of IMAGE_URL_PREFIX coming in from the CONFIG file?

> The only way
> I can see the compiler getting the wrong value for IMAGE_URL_PREFIX would
> be if, somehow, it got the value from a DIFFERENT copy of CONFIG, that
> has the old value.
> The only way I could imagine this happening is if your make program
> interprets include paths relative to the file in which they occur, rather
> than to its current directory, AND you had another CONFIG file in the
> directory above the top level source directory which contained the old
> value for IMAGE_URL_PREFIX. In this scenario, when htcommon/Makefile sets
> top_builddir= .. and then does "include $(top_builddir)/Makefile.config",
> make then finds the "include $(top_builddir)/CONFIG" command in
> Makefile.config and looks for CONFIG in the directory above where
> Makefile.config is, rather than in the directory above htcommon.
> GNU make doesn't seem to do this, but maybe other versions of make do.
> It's a stretch, but I can't see another way of explaining how things got
> out of sync, given that you're certain that the CONFIG file didn't change
> between the make and the make install.

I think it's unlikely that make would exhibit this behavior because it would
make make unpredictable and the various versions of make inconsistent with each
other. In any case, there is no CONFIG file in the directory above the
top-level source directory. So that conjecture can be ruled out.

> > Unfortunately I don't have a log of the make and don't want to re-run it
> > because it takes so long. Perhaps on a later make I can keep a log file and
> > find the explanation. Thanks for your help.
> If you still have the source tree around, with all the object files in
> place, you'd just need to rename htcommon/defaults.o to something else,
> and run make again to rebuild it. You could then run "strings" on both
> object files and look for differences, or maybe even run "cmp" on them
> to see if their identical (though even if not identical, it doesn't
> necessarily mean the paths are different). Just a suggestion, if you
> want to get to the bottom of this.

Would I have to run make on the whole source tree or would it suffice to run it
in htcommon alone? I would much rather the latter. I have checked the
existing defaults.o with the strings command and found the lines



which I think are consistent with its getting the correct URL.

> Let us know if you do find out the cause, especially if it points to a
> problem in the Makefiles.

I would like to find it too because I think that setting the URL's in the
conf/htdig.conf file is disadvantageous.


Douglas Kline

To unsubscribe from the htdig mailing list, send a message to containing the single word "unsubscribe" in
the SUBJECT of the message.

This archive was generated by hypermail 2.0b3 on Thu May 13 1999 - 17:11:23 PDT