> Yep, I do have the 'config.log'...thanks
>
> I took one look at it and saw the #define stuff and decided that was
> not a log file but I thought it may have been a temp file for some "c"
> code.
As Vic said, 'configure' will frequently invoke the compiler.
I read a cutsie signature line one time:
"This is Unix. You just gotta know!". Sad, but true.
The behaviour of 'configure' is another of those things
that become common knowledge, but not ubiquitous common knowledge.
I mentioned a "standard recipe".
It's not exclusive of Unix, but is most common on Unix:
# download
# unarchive (uncompress and untar)
./configure
make
make install
You can do this on Windows too. Heck, you could do it
on CMS as well! Harder to do on TSO because of time stamps.
In this sequence, 'configure' will often produce a log file.
I have recently found a number of packages that failed to config
where I got a message, "see config.log" to figure out what went wrong.
I'd complain a lot less about that than about your bacula experience.
(Or did bacula config tell you to read the log?)
Mark Post will tell you, rightly, to use RPM or some other
package mangler for to get a proper audit trail. Works even for
source packages in many cases. The value is more significant for
big shops where someone else will have to pick up the pieces after
you've left. My beef with RPM is two-fold: 1) it fails on a number
of points of robustness (so does SES/E or SMP/E or SAM, InstallShield
behaves better than these! I might contend that SMIT is better still),
and 2) it is less ubiquitous and less flexible than the above "recipe".
-- R;
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
