Re: [htdig] Bad Pathname in htsearch output

Douglas Kline (
Fri, 14 May 1999 14:55:23 -0400

> >> 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.
> >
> >alias on the http server and is in fact used on the htdig Web site. Mightn'
> >the compilation be using such a default such that it would complete without
> >definition of IMAGE_URL_PREFIX coming in from the CONFIG file?
> No. Gilles is correct--there is no default and the compiler will complain
> that the symbol 'IMAGE_URL_PREFIX' is undefined. It is *only* set in the
> CONFIG file. Future versions will probably have 'make install' substitute
> this into the default htdig.conf file.
> >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
> You only need to clean out htcommon and run make on that.

I found that "make distclean" goes too far by getting rid of the make file but
"make clean" followed by make in the htcommon source directory worked. The
recompilation was carried out under SunOS 5.6 while the original and active
compilation was under 5.5.1. So it's not surprising that the resulting
default.o and libcommon.a files were not the same. The pertinent string
definitions in default.o were the same. I hope the different OS rev. doesn't
throw that observation off.

> >I would like to find it too because I think that setting the URL's in the
> >conf/htdig.conf file is disadvantageous.
> OK. I personally find it *more* advantageous since I need not worry about
> setting it using the CONFIG file. There is, however, no "right way" and
> personal preferences are fine.

The reason for my preference is that this is the sort of thing which one might
forget on new installations and one might not notice the malfunction right
away either. Not really a big deal.

> -Geoff Hutchison
> Williams Students Online

> Hi again. Geoff already covered some of your points, but I have a few
> thing to add...
> According to Douglas Kline:
> > > 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 set
> > > 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 woul
> > make make unpredictable and the various versions of make inconsistent with
> > 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.
> Well, just a couple days after I suggested this possibility, Ken Brown
> reported that the make bombed on his Digital Unix 4.0b system, with this
> error:
> Make: Cannot open ../../CONFIG. Stop.
> He solved it by switching to GNU make. So, different versions of make
> do indeed interpret relative paths in includes differently.

I am surprised and forewarned.

> The fix here
> would be to use fully qualified path names in cases where interpretation
> is ambiguous.

How could you use a fully qualified pathname in a makefile in a software
distribuion? By defining a starting point as a variable and defining all
pathnames from there?

> However, as you don't have an extra CONFIG file above the top level, and
> you didn't get that error, that does rule out this possibility for the
> problem you had.
> > > > Unfortunately I don't have a log of the make and don't want to re-run i
> > > > because it takes so long. Perhaps on a later make I can keep a log file
> > > > 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 ru
n it
> > in htcommon alone? I would much rather the latter.
> Given that we ruled out the make include path ambiguity problem above,
> it probably doesn't matter which way you rerun make.
> > I have checked the
> > existing defaults.o with the strings command and found the lines
> >
> >
> > image_url_prefix
> >
> >
> > star_blank
> > ${image_url_prefix}/star_blank.gif
> > star_image
> > ${image_url_prefix}/star.gif
> >
> >
> > which I think are consistent with its getting the correct URL.
> Yes, that is odd, isn't it? Why was htsearch using "/htdig" as the
> image_url_prefix, when it seems to be correct in the existing object file?
> It would seem that somehow, this default.o didn't make it into your
> htsearch. Two possibilities I can think of: 1) you compiled
> after changing CONFIG, but htsearch never got re-linked, or more likely 2)
> the freshly linked htsearch, with the desired image url prefix didn't get
> installed where you wanted it, so you're still running an older htsearch.
> Check the modification times of (top_dir)/CONFIG, (top_dir)/htsearch/htsearch
> and the htsearch in your cgi-bin (the one your search form runs).

I did and found that indeed htsearch was not installed correctly. I think I
ran "make install" but perhaps that malfunctioned for some reason and it didn't
output an error message or I didn't see it. I checked the active htsearch with
the strings command and found it didn't have the correct pathname in it. I
guess we should have checked the executable when we checked the defaults.o

I tried running another "make install". I did this on a SunOS 5.6 computer
thinking it would only install the files. It started doing compilations and
since I don't want to compile under 5.6 because our Web-server is running 5.5.1
and can't run the htsearch compiled under 5.6 I aborted the make. Checking the
makefile, I found that "make install" has "all" as one of its targets which I
didn't expect. I will try to run "make install" on a 5.5.1 computer (not so
readily done since we don't have many and I can't use th Web-server for this)
and report back the results.

> > 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.
> As Geoff said, this is a matter of preference, but two big advantages of
> putting it in htdig.conf are that it decreases the likelyhood of the
> path getting out of sync with those in the common/*.html files, and that
> it's a lot easier to change down the road (you don't need to recompile).

Thanks for your answers.

Doug Kline

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 Fri May 14 1999 - 12:11:23 PDT