Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'
On 07/18/2018 08:33 AM, Barath Aron wrote: In order to test things, I'll install a NetBSD and (probably) a FreeBSD. Despite I have ideas, I want to install these systems before changing/suggesting anything. I didn't have enough time to install them, but I looked into the gnulib itself. I made a clone, the last commit is: commit 2fe9cab33250d8e4e366d29c02c057814ff5523d Author: Paul Eggert Date: Tue Jul 17 16:13:46 2018 -0700 It seems the getmntinfo() call is handled both for 4.4BSD and NetBSD 3.0, which is promising. As a progress update (after I've implemented getmntinfo() on Threos): findutils is no longer fails due to the mysterious struct fsstat (that part still not works, but the configure could choose an alternate implementation). It looks gnulib is happy with getmntinfo(), but I think there is messup in the getfsstat() branch. I grepped on the entire source code to find out where/how 'struct fsstat' is used, but I found the "fsstat" (as a whole word) only in Changelog and m4 files. I would guess the raw getfsstat() branch is for some really exotic system. For now, I stop to figure out why struct fsstat is used in the m4 files. Since gnulib is happy with 4.4BSD style getmntinfo(), so do I. Thanks to Bruno for the getmntinfo() suggestion. And thank you all for the valuable help to solve my configuration issue. The next task for me is to try to replace forks with posix_spawn in findutils. Aron
Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'
On 07/17/2018 09:05 PM, Barath Aron wrote: Thanks, I'll let you know about my findings. As a start, I got all the headers from a NetBSD 4.0 with gcc installed. After looking into those headers, I noticed the following: a) There is no getfsstat(), but there is getvfsstat(), and its argument is not 'struct statfs' but 'struct statvfs'. b) getmntinfo() uses the 'struct statvfs' as getvfsstat() -- which is odd, but on the other hand it is reasonable: they have the same struct as POSIX describes, with additional fields (that's still good for POSIX). Manpage for this: http://netbsd.gw.com/cgi-bin/man-cgi?getmntinfo+3+NetBSD-4.0 "The getmntinfo() function first appeared in 4.4BSD. It was converted from using getfsstat(2) to getvfsstat(2) in NetBSD 3.0." c) The struct statvfs has the f_fstypename field that gnulib expect in struct fsstat. d) The previously known types are not exist: struct statfs, struct fsstat. In order to test things, I'll install a NetBSD and (probably) a FreeBSD. Despite I have ideas, I want to install these systems before changing/suggesting anything. Aron
Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'
On 07/17/2018 08:49 PM, Paul Eggert wrote: Barath Aron wrote: Does gnulib support BSD's getmntinfo()? Since it looks not, what can we do? Gnulib ports to the operating systems (including BSD operating systems) available at the time Gnulib was written, and it still ports to the current versions of these operating systems as far as we know. I try to get access to a current BSD to see how it works on it. If even works. So you can either change your new OS to emulate one of the existing OSes better, Yes, it was my original intention with BSD's getfsstat() and getmntinfo(), but I got stuck with struct fsstat which I do not understand, and seems to be undocumented (at this time -- maybe in the past it was). or you can change Gnulib to work with whatever primitives your OS provides. Nice, I'm glad to hear that. Changes are not welcomed in all GNU projects. :) Lately I replaced many forks with posix_spawn in open source projects, but the maintainers rarely accept the patches. I don't see any other options, offhand. Thanks, I'll let you know about my findings.
Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'
Barath Aron wrote: Does gnulib support BSD's getmntinfo()? Since it looks not, what can we do? Gnulib ports to the operating systems (including BSD operating systems) available at the time Gnulib was written, and it still ports to the current versions of these operating systems as far as we know. So you can either change your new OS to emulate one of the existing OSes better, or you can change Gnulib to work with whatever primitives your OS provides. I don't see any other options, offhand.
Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'
I don't want to flood the mailing lists, so let me merge Bruno's mail again. On 07/17/2018 05:49 PM, Paul Eggert wrote: On 07/16/2018 10:41 PM, Barath Aron wrote: I guess it is more like a hack than a solution. Quite true. We need a real solution here, not a hack. But that will need someone to look into it. If Threos is supposed to be like POSIX, it should use the POSIXish part of the relevant Gnulib code, not the BSDish part. So you could look into why the POSIXish part isn't working. I prefer POSIX over BSD. The issue here, explicitly at mount lists, POSIX does not define an API for it, but BSD does. I choosed the BSD approach instead of the Linux's. Actually, it even worse, because getmntent(3) came from SunOS, according to the manpage. I like the BSD approach better, because the Linux solution wants file to be placed in the file system, but BSD is pure API that is not related to any magic file. The only relevant functions in POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_statvfs.h.html And this is not too much. :( On 07/17/2018 07:09 PM, Bruno Haible wrote: Barath Aron wrote: ... on an OS that partially (mostly?) supports POSIX, and implements widely used BSD functions. And when I saw the getfsstat() and now the getmntinfo() functions I put them into the libc If you want to minimize porting efforts in the long run, I would suggest to implement the POSIX functions, rather than the BSD functions. Rationale: * Lots of applications have been ported to run on Linux, and use the POSIX API to that effect. * POSIX is a standard that has even some dark corner-cases fledged out. Like you said here: > I cannot implement something in libc based on > presumption. That's why I'm looking for at least a manual page that > clearly defines ... * Test suites exist that you can use to validate your implementation (even if the implementation, as for Threos, is closed-source). Bruno I absolutely agree, it is a goal to support as many POSIX functions as possible. The only issue is that POSIX, as far as I know, does not define any API to query the mount list with. I think I conclude with this: I implemented the BSD's getmntinfo() and getfsstat() functions according the manual pages that I found. Therefore, the original question turned into this: Does gnulib support BSD's getmntinfo()? Since it looks not, what can we do? The struct fsstat still bothers me, but this will remain a mystery. Aron
Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'
On 07/16/2018 10:41 PM, Barath Aron wrote: I guess it is more like a hack than a solution. Quite true. We need a real solution here, not a hack. But that will need someone to look into it. If Threos is supposed to be like POSIX, it should use the POSIXish part of the relevant Gnulib code, not the BSDish part. So you could look into why the POSIXish part isn't working.
Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'
Hi, Thank you all for the answers. Let me merge Bruno's mail first: On 07/17/2018 12:02 AM, Bruno Haible wrote: The configuration of the gnulib 'mountlist' module (used by findutils and coreutils, among others) is written in such a way that on OpenBSD it uses the getmntinfo() function https://man.openbsd.org/getmntinfo.3 which, according to this manual page, invokes getfsstat(). Why would you make it call getfsstat() directly? I do not really need getfsstat(), but this was the first function that configure complained about. Personally, I like getmntinfo() much better, but I didn't know it until now. :) That test is not meant to succeed on OpenBSD. As the comments indicate, it's there for OSF/1 and Darwin. I saw the comment, but I thought they use the same API shown in BSD, because their manual says "The getfsstat() function first appeared in 4.4BSD" and "The getmntinfo() function first appeared in 4.4BSD". Still, some reference to "struct fsstat" would be nice, since OSF/1 manpage talks about "struct statfs". http://polarhome.com/service/man/?qf=getmntinfo&tf=2&of=OSF1&sf= For Darwin (this is the best source I found, because https://developer.apple.com/documentation/Darwin/Reference/ManPages/ is dead): http://polarhome.com/service/man/?qf=getmntinfo&af=0&sf=0&of=Darwin&tf=2 http://polarhome.com/service/man/?qf=statfs&tf=2&of=Darwin&sf=2 Forgive my confusion, but I do not see "struct fsstat" anywhere. It is maintained in gnulib, module 'mountlist'. This is good news. :) Bruno On 07/16/2018 11:11 PM, Paul Eggert wrote: On 07/16/2018 01:05 PM, Bernhard Voelker wrote: So, my questions are: a) Why the configure use a different type name? Comments suggest that this is what OSF/1 used. I used the BSD manual pages, becase the best hit was identical to the BSD's API. It might was a mistake, but I prefer to implement something according to (as least) a consistent manual page. http://polarhome.com/service/man/?qf=getfsstat&tf=2&of=OSF1&sf= b) If it is intentional, then where that type is defined? Presumably in system include files. This is problem to me. :( Unfortunately, I cannot implement something in libc based on presumption. That's why I'm looking for at least a manual page that clearly defines struct fsstat. OSF/1 manpage isn't mention struct fsstat. c) Is this branch of the configure still maintained, or it is abandoned? OSF/1 is long dead. I know. :) The related code that use this API is also still maintained? Not as far as I know. However, it shouldn't be used on OpenBSD or FreeBSD, I expect. Someone (probably you :-) needs to figure out why it's being used. Sorry, I don't know what is normally used on OpenBSD and/or FreeBSD these days. Well, I do not know it is used on BSDs or not. I try to compile findutils on an OS that partially (mostly?) supports POSIX, and implements widely used BSD functions. And when I saw the getfsstat() and now the getmntinfo() functions I put them into the libc, because the API looked way too simple, and they were implemented purely in libc. The intention was to support convenient API to query mount points. The OS is called Threos. You can find further info about this OS: https://threos.io The cross-compiler used on x86_64 is basically a very simple wrapper around x86_64-pc-linux-gnu-gcc with a few flags set, i.e. -ffreestanding -nostdlib -nostdinc -I/path/to/include and some libraries. It also sets some other flags for linking. After cleaning it up, it will be published. Side note: If I replace one line in the configure script, everything is fine. But I guess it is more like a hack than a solution. -ac_fn_c_check_member "$LINENO" "struct fsstat" "f_fstypename" "ac_cv_member_struct_fsstat_f_fstypename" "$getfsstat_includes +ac_fn_c_check_member "$LINENO" "struct statfs" "f_fstypename" "ac_cv_member_struct_fsstat_f_fstypename" "$getfsstat_includes Aron
Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'
On 07/16/2018 01:05 PM, Bernhard Voelker wrote: So, my questions are: a) Why the configure use a different type name? Comments suggest that this is what OSF/1 used. b) If it is intentional, then where that type is defined? Presumably in system include files. c) Is this branch of the configure still maintained, or it is abandoned? OSF/1 is long dead. The related code that use this API is also still maintained? Not as far as I know. However, it shouldn't be used on OpenBSD or FreeBSD, I expect. Someone (probably you :-) needs to figure out why it's being used. Sorry, I don't know what is normally used on OpenBSD and/or FreeBSD these days.
Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'
[forwarding to gnulib]
On 07/11/2018 02:00 PM, Barath Aron wrote:
> Hello,
>
> I have a little issue around the detection of the getfsstat() function.
>
> According to multiple manuals from different BSD versions [1,2], the
> signature of the BSD's getfsstat() is this:
> int getfsstat(struct statfs *buf, long bufsize, int mode);
>
> Note, it refers to 'struct statfs'. The statfs structure contains a
> field that will be interesting in the following [3,4]:
>
> struct statfs {
> ...
> char f_fstypename[MFSNAMELEN]; /* filesystem type name */
> ...
> };
>
> The configure script tries to detect the getfsstat() function but
> failes, because:
> configure:31706: checking for struct fsstat.f_fstypename
> configure:31706: /path/to/some-cross-gcc -c conftest.c >&5
___^^^
What environment did you use?
> conftest.c: In function 'main':
> conftest.c:473:22: error: storage size of 'ac_aggr' isn't known
> static struct fsstat ac_aggr;
> ^~~
> configure:31706: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "GNU findutils"
> | #define PACKAGE_TARNAME "findutils"
> | #define PACKAGE_VERSION "4.6.0"
> ...
> | int
> | main ()
> | {
> | static struct fsstat ac_aggr;
> | if (ac_aggr.f_fstypename)
> | return 0;
> | ;
> | return 0;
> | }
>
> However, the used type in the failed program was 'struct fsstat'. By the
> definition of 'struct statfs' found in the BSD manuals, does have a
> field 'f_fstypename'. But the name is different.
>
> My goal is to compile the findutils by supplying the BSD's getfsstat()
> API to get mountlist. For now, I do not want to implement the Linux's
> stuff, I like the BSD approach.
>
> So, my questions are:
> a) Why the configure use a different type name?
> b) If it is intentional, then where that type is defined? Unfortunately,
> I did not found anything.
> c) Is this branch of the configure still maintained, or it is abandoned?
> The related code that use this API is also still maintained?
>
> Aron
>
> [1] https://man.openbsd.org/getfsstat.2
> [2] https://www.freebsd.org/cgi/man.cgi?query=getfsstat&sektion=2
> [3] https://man.openbsd.org/statfs.2
> [4] https://www.freebsd.org/cgi/man.cgi?query=statfs&sektion=2
These seem to be questions for upstream gnulib.
Have a nice day,
Berny
Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'
On 07/11/2018 05:54 PM, Bernhard Voelker wrote: This is a question for upstream gnulib. Before we move the discussion there and it is an already-fixed issue there, did you try to build findutils from latest Git as well? (4.6.0 is the latest release, but already quite aged...) Have a nice day, Berny Yes, freshly cloned findutils does the same. | #define PACKAGE_STRING "GNU findutils 4.6.0.180-e3b9" Aron
Re: configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'
On 07/11/2018 02:00 PM, Barath Aron wrote:
> Hello,
>
> I have a little issue around the detection of the getfsstat() function.
>
> According to multiple manuals from different BSD versions [1,2], the
> signature of the BSD's getfsstat() is this:
> int getfsstat(struct statfs *buf, long bufsize, int mode);
>
> Note, it refers to 'struct statfs'. The statfs structure contains a field
> that will be interesting in the following [3,4]:
>
> struct statfs {
> ...
> char f_fstypename[MFSNAMELEN]; /* filesystem type name */
> ...
> };
>
> The configure script tries to detect the getfsstat() function but failes,
> because:
> configure:31706: checking for struct fsstat.f_fstypename
> configure:31706: /path/to/some-cross-gcc -c conftest.c >&5
> conftest.c: In function 'main':
> conftest.c:473:22: error: storage size of 'ac_aggr' isn't known
> static struct fsstat ac_aggr;
> ^~~
> configure:31706: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME "GNU findutils"
> | #define PACKAGE_TARNAME "findutils"
> | #define PACKAGE_VERSION "4.6.0"
> ...
> | int
> | main ()
> | {
> | static struct fsstat ac_aggr;
> | if (ac_aggr.f_fstypename)
> | return 0;
> | ;
> | return 0;
> | }
>
> However, the used type in the failed program was 'struct fsstat'. By the
> definition of 'struct statfs' found in the BSD manuals, does have a field
> 'f_fstypename'. But the name is different.
>
> My goal is to compile the findutils by supplying the BSD's getfsstat() API to
> get mountlist. For now, I do not want to implement the Linux's
> stuff, I like the BSD approach.
>
> So, my questions are:
> a) Why the configure use a different type name?
> b) If it is intentional, then where that type is defined? Unfortunately, I
> did not found anything.
> c) Is this branch of the configure still maintained, or it is abandoned? The
> related code that use this API is also still maintained?
>
> Aron
>
> [1] https://man.openbsd.org/getfsstat.2
> [2] https://www.freebsd.org/cgi/man.cgi?query=getfsstat&sektion=2
> [3] https://man.openbsd.org/statfs.2
> [4] https://www.freebsd.org/cgi/man.cgi?query=statfs&sektion=2
This is a question for upstream gnulib. Before we move the discussion there
and it is an already-fixed issue there, did you try to build findutils from
latest Git as well? (4.6.0 is the latest release, but already quite aged...)
Have a nice day,
Berny
configure issue: getfsstat(), 'struct statfs' and 'struct fsstat'
Hello,
I have a little issue around the detection of the getfsstat() function.
According to multiple manuals from different BSD versions [1,2], the
signature of the BSD's getfsstat() is this:
int getfsstat(struct statfs *buf, long bufsize, int mode);
Note, it refers to 'struct statfs'. The statfs structure contains a
field that will be interesting in the following [3,4]:
struct statfs {
...
char f_fstypename[MFSNAMELEN]; /* filesystem type name */
...
};
The configure script tries to detect the getfsstat() function but
failes, because:
configure:31706: checking for struct fsstat.f_fstypename
configure:31706: /path/to/some-cross-gcc -c conftest.c >&5
conftest.c: In function 'main':
conftest.c:473:22: error: storage size of 'ac_aggr' isn't known
static struct fsstat ac_aggr;
^~~
configure:31706: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU findutils"
| #define PACKAGE_TARNAME "findutils"
| #define PACKAGE_VERSION "4.6.0"
...
| int
| main ()
| {
| static struct fsstat ac_aggr;
| if (ac_aggr.f_fstypename)
| return 0;
| ;
| return 0;
| }
However, the used type in the failed program was 'struct fsstat'. By the
definition of 'struct statfs' found in the BSD manuals, does have a
field 'f_fstypename'. But the name is different.
My goal is to compile the findutils by supplying the BSD's getfsstat()
API to get mountlist. For now, I do not want to implement the Linux's
stuff, I like the BSD approach.
So, my questions are:
a) Why the configure use a different type name?
b) If it is intentional, then where that type is defined? Unfortunately,
I did not found anything.
c) Is this branch of the configure still maintained, or it is abandoned?
The related code that use this API is also still maintained?
Aron
[1] https://man.openbsd.org/getfsstat.2
[2] https://www.freebsd.org/cgi/man.cgi?query=getfsstat&sektion=2
[3] https://man.openbsd.org/statfs.2
[4] https://www.freebsd.org/cgi/man.cgi?query=statfs&sektion=2
