After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 655027 - struct statvfs has no members f_mntonname f_mntfromname f_fstypename
struct statvfs has no members f_mntonname f_mntfromname f_fstypename
Status: RESOLVED DUPLICATE of bug 617949
Product: glib
Classification: Platform
Component: gio
2.29.x
Other Mac OS
: Normal blocker
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-07-21 06:07 UTC by Ryan Schmidt
Modified: 2011-08-12 11:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
complete build log from MacPorts (24.22 KB, application/x-bzip2)
2011-07-21 06:07 UTC, Ryan Schmidt
Details

Description Ryan Schmidt 2011-07-21 06:07:12 UTC
Created attachment 192359 [details]
complete build log from MacPorts

glib 2.29.12 fails to build on Mac OS X 10.6.8 with Xcode 3.2.6 with the following error:


gunixmounts.c: In function '_g_get_unix_mounts':
gunixmounts.c:601: warning: passing argument 1 of 'getmntinfo' from incompatible pointer type
gunixmounts.c:610: error: 'struct statvfs' has no member named 'f_mntonname'
gunixmounts.c:611: error: 'struct statvfs' has no member named 'f_mntfromname'
gunixmounts.c:612: error: 'struct statvfs' has no member named 'f_fstypename'


glib 2.29.10 built fine on this system.


I see a number of hits on Google for this error message; perhaps one is relevant:


http://www.google.com/search?q=%22%27struct+statvfs%27+has+no+member+named+%27f_mntonname%27%22
Comment 1 Matthias Clasen 2011-07-22 01:19:21 UTC
I think it is time to split up gunixmounts.c into pieces that can be understood individually. I can't find my way in that source file anymore.

glinuxmounts.c vs gsolarismounts.c, maybe ?
Comment 2 John Ralls 2011-07-22 14:06:27 UTC
I'm confused (as usual, I suppose). It compiles fine on Fedora 14, but those symbols aren't found anywhere in /usr/include. Where do they come from?

Bracketing the 3 lines with @ifndef HAVE_CARBON...#endif lets it build, but that's probably not the right solution long-term.

Mattias: Yes, it would seem most portable to have a gposixmounts.c which is the default and gfoomounts.c for cases like linux where there's an advantage to specializing.
Comment 3 Colin Walters 2011-07-22 16:52:15 UTC
I don't think we're going to get this fixed without someone active who can build on OS X and test patches.  Ryan, can you do that?

Patrick, any ideas?
Comment 4 John Ralls 2011-07-22 17:06:15 UTC
I'm active, I have commit privs, and I can build and test on all supported OSX builds, from Tiger through Lion.
Comment 5 Colin Walters 2011-08-06 13:28:58 UTC
Does the commit from bug 656048 help the OS X build?
Comment 6 John Ralls 2011-08-06 23:53:04 UTC
Unfortunately, no, and neither does passing ac_cv_func_statvfs=no to configure.
Comment 7 Colin Walters 2011-08-12 11:01:21 UTC

*** This bug has been marked as a duplicate of bug 617949 ***
Comment 8 Patrick Welche 2011-08-12 11:44:47 UTC
I agree with the sentiment of comment 1. When solving bug 617949 I had to write

#ifdef HAVE_MNTENT_H
#elif defined (HAVE_SYS_MNTTAB_H)
#elif defined(HAVE_SYS_MNTCTL_H) && defined(HAVE_SYS_VMOUNT_H) && defined(HAVE_SYS_VFS_H)
#elif defined(HAVE_GETMNTINFO) && defined(HAVE_FSTAB_H) && defined(HAVE_SYS_MOUNT_H)
#elif defined(__INTERIX)
#else
#error No _g_get_unix_mounts() implementation for system
#endif

on a sheet of paper to keep track!

Sorry I missed Comment 3 - should I set up my bugzilla account in some way to be emailed such things? (I saw 617949 was reopened because I was still on the cc: )