A couple problems building OpenSSH 5.2p1 on an older RedHat Linux system (6.2). Both of these could probably be easily fixed in the configuration script. (1) My version of /usr/include/netinet/in.h did not define in_port_t, causing compiler to fail on channels.c line 2472. Worked around by changing in_port_t to uint16_t on that line. (2) sftp-server.c line 507 buffer_put_int64(&msg, FSID_TO_ULONG(st->f_fsid)); got "incompatible type" error. FSID_HAS_VAL was not defined: checking if f_fsid has val members... no causing FSID_TO_ULONG to be defined in defines.h: # define FSID_TO_ULONG(f) ((f)) but I don't see how this could work---was it intentional that sftp-server.c would get an error if this was not defined? Or was it expected that f_fsid would itself be a 64-bit integer in that case? In any case, __fsid_t is defined like this in <bits/types.h> on my system: typedef struct { int __val[2]; } __fsid_t; /* Type of file system IDs. */ and I worked around it by copying the "good" definition of FSID_TO_ULONG in defines.h and changing val to __val.
#1 has already been fixed in -current: $ cvs log configure.ac [...] revision 1.416 date: 2009/03/07 01:32:22; author: dtucker; state: Exp; lines: +3 -3 - (dtucker) [configure.ac defines.h] Check for in_port_t and typedef if needed. As for #2, on some platforms f_fsid is in an integral type (ulong, usually), on others it's a struct with a member "val". The macro handles those two cases. It sounds like you have a third case where the structure has a member "__val", for which the existing test and macro fail. The configure test and macro could be extended to handle that case too, but first check the man page for statvfs and see what type specified for f_fsid is (it's possible we just need to include the right header).
There's no man page for statvfs. "man statfs" says struct statfs { long f_type; /* type of filesystem (see below) */ long f_bsize; /* optimal transfer block size */ long f_blocks; /* total data blocks in file system */ long f_bfree; /* free blocks in fs */ long f_bavail; /* free blocks avail to non-superuser */ long f_files; /* total file nodes in file system */ long f_ffree; /* free file nodes in fs */ fsid_t f_fsid; /* file system id */ long f_namelen; /* maximum length of filenames */ long f_spare[6]; /* spare for later */ }; The man page also says #include <sys/vfs.h>. On my system sys/vfs.h consists only of #include <sys/statfs.h>. Let me know if you want to see any .h files.
Created attachment 1649 [details] Handle f_fsid.__val too Please try this patch. You will need to run "autoreconf" from autoconf to rebuild configure, then rerun ./configure and rebuild.
Sorry, the patch didn't work, but I think it's because the code to check for this in the configuration said "struct fsid_t t;", and fsid_t isn't a struct on this system, but a typedef. If you remove the "struct" it will probably work. I tried compiling a small C program myself that did the same check, trying to set t.__val[0], and it worked without the "struct".
Created attachment 1650 [details] Handle __val, attempt 2 Good point. In fact I'm kinda surprised the current one works in retrospect. Please try this one. It tests for the best case and only pokes the struct if that fails.
(In reply to comment #5) > Created an attachment (id=1650) [details] > Handle __val, attempt 2 > Good point. In fact I'm kinda surprised the current one works in > retrospect. > Please try this one. It tests for the best case and only pokes the > struct if that fails. OK, this seems to work. Thanks.
patch applied, thanks.
Mass move of RESOLVED bugs to CLOSED now that 5.3 is out.