Re: [htdig] Bad Pathname in htsearch output

Gilles Detillieux (
Tue, 4 May 1999 16:56:37 -0500 (CDT)

According to Douglas Kline:
> However I don't understand why this failed to work before. I have the lines in
> htcommon/ which you cite. I ran the make after setting the CONFIG
> file and the Makefile and .o files in htcommon are dated after the CONFIG file.
> star_image and star_blank were not defined in the htdig.conf file at all. And
> 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 route
> 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

> Your last conjecture, "A third possibility may be that your make program didn't
> properly include the CONFIG definitions, or didn't pass them on to the compiler
> for whatever reason," may be the only answer although even that doesn't explain
> how it got one star line right and the other wrong. However we know that the
> make picked up the IMAGE_URL_PREFIX from the CONFIG file because it was applied
> 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. 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.

> 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.

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

Gilles R. Detillieux              E-mail: <>
Spinal Cord Research Centre       WWW:
Dept. Physiology, U. of Manitoba  Phone:  (204)789-3766
Winnipeg, MB  R3E 3J7  (Canada)   Fax:    (204)789-3930
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 Tue May 04 1999 - 15:07:59 PDT