Gilles Detillieux (firstname.lastname@example.org)
Fri, 14 May 1999 12:54:54 -0500 (CDT)
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 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.
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
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. The fix here
would be to use fully qualified path names in cases where interpretation
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 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.
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
> 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 defaults.cc
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).
> > 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).
-- Gilles R. Detillieux E-mail: <email@example.com> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil 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 firstname.lastname@example.org containing the single word "unsubscribe" in the SUBJECT of the message.
This archive was generated by hypermail 2.0b3 on Fri May 14 1999 - 11:10:44 PDT