rsync.h always including syslog.h even when not used.
John E. Malmberg
wb8tyw at qsl.net
Mon Oct 13 14:21:35 EST 2003
jw schultz wrote:
> On Sun, Oct 12, 2003 at 12:38:40AM -0400, John E. Malmberg wrote:
>>>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?
> Unlikely. That isn't the sort of thing that gets removed.
>>>>OpenVMS currently does not have a syslog facility, so it does not have a
>>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
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;
%CC-I-RIGHTSHIFTOVR, (1) In this statement, the right shift count
"8" is greater than or equal to the size of the unpromoted operand
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)
wb8tyw at qsl.network
Personal Opinion Only
More information about the rsync