msync on Hurd, dev_t on MIPS
rra at stanford.edu
Tue Nov 3 01:12:27 UTC 2009
Julien ÉLIE <julien at trigofacile.com> writes:
> The Debian build of INN 2.5.1 on Hurd gives a few warnings (which do not
> prevent the package from being successfully compiled):
> storage/libstorage.a(cnfs.o): In function `CNFSflushhead':
> storage/cnfs/cnfs.c:214: warning: warning: msync is not implemented and will always fail
I wonder if MMAP_NEEDS_MSYNC or MMAP_MISSES_WRITES are defined on Hurd.
If so, this error message means that there will probably be some data
corruption if someone runs innd on the Hurd.
> storage/libstorage.a(shmem.o): In function `smcReleaseExclusiveLock':
> storage/buffindexed/shmem.c:130: warning: warning: semop is not implemented and will always fail
> storage/libstorage.a(shmem.o): In function `smcGetSemaphore':
> storage/buffindexed/shmem.c:29: warning: warning: semget is not implemented and will always fail
> storage/libstorage.a(shmem.o): In function `smcCreateSemaphore':
> storage/buffindexed/shmem.c:62: warning: warning: semctl is not implemented and will always fail
Nothing we can do about the latter; it implies that Hurd just doesn't have
SysV shared memory. I think buffindexed now requires it.
> On MIPS, we have:
> hisv6/hisv6.c: In function 'hisv6_closefiles':
> hisv6/hisv6.c:272: warning: large integer implicitly truncated to unsigned type
> hisv6/hisv6.c: In function 'hisv6_new':
> hisv6/hisv6.c:480: warning: large integer implicitly truncated to unsigned type
> It corresponds to the cast to dev_t:
> h->st.st_dev = (dev_t)-1;
> How can we change that?
That's an odd one. I'm not sure what to make of that error. It sounds
almost like st_dev isn't a dev_t, but that doesn't make any sense to me.
You should be able to cast -1 to an unsigned type; that's a common C
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
More information about the inn-workers