bugGNU Core Utilities - Bugs: bug #16325, Fixes needed to build coreutils on...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #16325: Fixes needed to build coreutils on Interix (SFU or SUA)

Submitter:  Matthew Woehlke <woehlkmp>
Submitted:  Tue 11 Apr 2006 06:46:54 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Jump to the original submission

Tue 19 Sep 2006 10:02:45 PM UTC, comment #6: 

These bugs all seem to be fixed now in CVS, except perhaps for the bit about the mount table, and you can open a new bug for that once you figure out how the mount table works there, or how to port the code, or something like that.

Paul Eggert <eggert>
Group administrator
Mon 17 Apr 2006 02:48:34 PM UTC, comment #5: 

Unfortunately, Paul's patch broke compilation on cygwin (and I'm assuming Linux, too, since cygwin modeled their statvfs after linux), where struct statvfs does not have an f_type member; only struct statfs:

if gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I. -I../lib -I../lib   -g2 -Wall -Werror -MT stat.o -MD -MP -MF ".deps/stat.Tpo" -c -o stat.o stat.c; \
then mv -f ".deps/stat.Tpo" ".deps/stat.Po"; else rm -f ".deps/stat.Tpo"; exit 1; fi
stat.c: In function `human_fstype':
stat.c:147: error: structure has no member named `f_type'
stat.c:284: error: structure has no member named `f_type'
make[3]: * [stat.o] Error 1

This followup patch fixes the issue for me, although I'm not sure it is the correct approach:

2006-04-17  Eric Blake  <ebb9@byu.net>

  • src/stat.c (USE_STATVFS): Define to 0 if f_type is needed, but

statvfs.f_type not present.


Index: src/stat.c
===================================================================
RCS file: /sources/coreutils/coreutils/src/stat.c,v
retrieving revision 1.92
diff -u -r1.92 stat.c
--- src/stat.c  12 Apr 2006 20:14:42 -0000      1.92
+++ src/stat.c  17 Apr 2006 14:45:04 -0000
@@ -20,7 +20,9 @@
 #include <config.h>
 
 #if (STAT_STATVFS \
-     && (HAVE_STRUCT_STATVFS_F_BASETYPE || ! HAVE_STRUCT_STATFS_F_FSTYPENAME))
+     && (HAVE_STRUCT_STATVFS_F_BASETYPE         \
+         || (! HAVE_STRUCT_STATFS_F_FSTYPENAME  \
+             && HAVE_STRUCT_STATVFS_F_TYPE)))
 # define USE_STATVFS 1
 #else
 # define USE_STATVFS 0
@@ -135,7 +137,7 @@
 static char const *trailing_delim = "";
 
 /* Return the type of the specified file system.
-   Some systems have statfvs.f_basetype[FSTYPSZ]. (AIX, HP-UX, and Solaris)
+   Some systems have statvfs.f_basetype[FSTYPSZ]. (AIX, HP-UX, and Solaris)
    Others have statfs.f_fstypename[MFSNAMELEN]. (NetBSD 1.5.2)
    Still others have neither and have to get by with f_type (Linux).  */
 static char const *

Eric Blake <ericb>
Group administrator
Wed 12 Apr 2006 08:53:56 PM UTC, comment #4: 

Unfortunately, msdn.microsoft.com is the most help you're going to get in that department (unless Microsoft is kind enough to fork over their source code, which I doubt). To hazard a guess, however, it looks like they might scan /dev/fs/[A-Z] and simply report on all available drive letters. (And this is getting technical for comments; please e-mail me if you are interested in further discussion).

I'd make a note of it (maybe open another bug at low priority?), but since it either isn't built or is being disabled by configure, I wouldn't worry about it. I much prefer the 'out of the box' build working in the next release or so than having to wait until df works.

I gave up trying to look at the diffs for fsusage, but everything else looked great! My only concern would be producing a sync command that is a no-op, but maybe that's nothing new?

Matthew Woehlke <woehlkmp>
Wed 12 Apr 2006 08:19:31 PM UTC, comment #3: 

I installed the attached patch in an attempt to address your points.  You'll have to help us out with "however the 'df' that comes with SFU/SUA does it", though; I don't have access to Interix so I can't figure it out for you.

Paul Eggert <eggert>
Group administrator
Wed 12 Apr 2006 04:07:57 PM UTC, comment #2: 

Hmm... "however the 'df' that comes with SFU/SUA does it", I guess. I didn't notice until you said something that the EXTRA_PROGRAMS (which 'df' is one of) are not built unless you do it 'by hand'. Therefore, I think my answer is "who cares, as long as the bin_PROGRAMS all build cleanly".

In other words, the changes I posted are not a complete port to Interix; merely enough for './configure ; make ; make install' to succeed. Maybe 'shred' and 'sync' should be moved to EXTRA_PROGRAMS?

Matthew Woehlke <woehlkmp>
Wed 12 Apr 2006 09:18:14 AM UTC, comment #1: 

If we can't read the mount table, how should "df -t" be implemented?

James Youngman <jay>
Tue 11 Apr 2006 06:46:54 PM UTC, original submission:  

There are some relatively minor changes needed to build coreutils on Interix (SFU 3.5 or SUA 5.2). Please consider integrating these into the next release:

- 'configure' should not abort when it is unable to determine how to read the mount table. There is a FIXME noting this!

- The targets 'shred' and 'sync' cannot be built because Interix has no 'sync'. 'sync' should be disabled; shred would need to be re-coded to not use sync or should be disabled.

- src/ln.c needs the code 'if (0) symlink ("/foo", "/foo");' just before the line 'linkfunc = symlink;'. If anyone knows WHY this is, I'd be curious to know, but it fixes a compiler error.

- src/stat.c needs to remove the condition '&& HAVE_STRUCT_STATVFS_F_BASETYPE' for including <sys/statvfs.h> and use 'HAVE_SYS_STATVFS_H' instead of 'HAVE_STRUCT_STATVFS_F_BASETYPE' when deciding to use statvfs instead of statfs.

- src/setuidgid needs calls to setgroups() removed. I used:
      #ifdef __INTERIX
      # define setgroups(a,b) 0
      #endif

Matthew Woehlke <woehlkmp>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #9773:  diff.txt added by eggert (14KiB - text/plain - Interix porting patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-09-19 eggert StatusNone Fixed
    Open/ClosedOpen Closed
2006-04-12 eggert Attached File- Added diff.txt, #9773

Back to the top

Powered by Savane 3.13-d3ae.
Corresponding source code