On Sun, Oct 12, 2003 at 12:38:40AM -0400, John E. Malmberg wrote:
Unlikely. That isn't the sort of thing that gets removed.
Won't work. LOG_DAEMON is defined in syslog.h.
Didn't there use to be a HAVE_SYSLOG or USE_SYSLOG in the source before?
OpenVMS currently does not have a syslog facility, so it does not have a syslog.h.
If I put an empty syslog.h in my build directory, than the compiler is happy, so it does not appear to be a needed header file if you do not have such a facility.
I can use the empty syslog.h, but I was hoping that this could be a CONFIGURE option, so if and when OpenVMS adds a SYSLOG type facility, it would pick it up with out the local syslog.h file causing a problem.
Making it something autoconf detects would be reasonable setting a HAVE_SYSLOG.
If you don't have a syslog facility i'd expect you to be getting link errors.
I have not seen any that I could attribute to that. The only one I am seeing is for getpass() being missing and I know how to fix that.
I'm surprised at that. What about the calls to syslog() and openlog() in log.c?
I found out that I was running an edit macro to condionally compile them out when LOG_SYSLOG was not defined. I had forgotten about that.
I am using an editor macro to put the same conditional around the include.
Apparently before the #include was in log.c and not rsync.h.
The MACRO LOG_SYSLOG is being used in the LOADPARAM.C module.
I can probably build a stub to implement a SYSLOG module after I get the file transfer working.
There does not appear to be any recent CVS snapshots available for download, so I am going with the 2.5.6 release as a base.For a long-term project that may be fairly safe but the
resulting code would have to be brought up-to-date with CVS
for patches to be accepted. Given the diff between 2.5.6
and CVS head i'd suggest setting yourself use CVS head and
keep fairly up-to-date.
I am making any of my patches through editor macros, so I can move to more upto date snapshots easily. I expect that 2.5.6 is close enough for me to verify simple functinality.
And I can pull down individual modules from CVS before submitting things.
The RSYNC web page implies that the CVS snapshots should be more frequent then they are, and this indicates that some automatic process is broken.
I am basically down to one unresolved compilier diagnostic.
The HP/COMPAQ/DEC C compiler is concerned about this line in TOKEN.C
4 22136 temp_byte = (char) n >> 8;
........................................1
%CC-I-RIGHTSHIFTOVR, (1) In this statement, the right shift count
"8" is greater than or equal to the size of the unpromoted operand
"(char)n".If I am interpreting this right, the value n is an integer, and is being cast to be a 8 bit size. And this results in all the higher bits being discarded. So the >> should shift out all 8 remaining significant bits.
Is this really what is intended? Or should there be parenthesis around (n >> 8) to make sure that it happens first.
The actual assembly code generated is:
LDL R10, n ; R10, 16(FP)
SLL R10, 56, R10
SRA R10, 63, R10
STQ R10, temp_byte ; R10, 8(FP)-John [EMAIL PROTECTED] Personal Opinion Only
-- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
