bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#9141: Coreutils Compiler Warnings on OSX 10.7 (Lion)


From: Herb Wartens
Subject: Re: bug#9141: Coreutils Compiler Warnings on OSX 10.7 (Lion)
Date: Thu, 21 Jul 2011 16:08:13 -0700



On Thu, Jul 21, 2011 at 3:08 PM, Paul Eggert <address@hidden> wrote:
On 07/21/11 02:16, Herb Wartens wrote:
> OSX does have fdatasync defined as part of the libsystem_kernel.dylib library.
> The problem is that there is no header on OSX that actually provides the function.

Thanks again for reporting this.


No problem.

 
What is the exact symptom of failure here?
If 'configure' successfully linked to fdatasync, then
presumably coreutils can link to it too.  So presumably
your compiler complained about the missing declaration.
But did it go ahead and use fdatasync anyway?  If so,
we're done: you can just ignore the diagnostic.  If not,


I prefer to have my code always compile cleanly.  I have found that when compiling code that generates a lot of warnings, people tend to ignore them (even important ones).  The linker was able to resolve the fdatasync and include it in the binaries:

# nm /usr/local/apps/Utils/coreutils/bin/dd | grep fdatasync
                 U _fdatasync

# otool -L /usr/local/apps/Utils/coreutils/bin/dd                 
/usr/local/apps/Utils/coreutils/bin/dd:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)

# otool -L /usr/lib/libSystem.B.dylib 
/usr/lib/libSystem.B.dylib:
<snip>
/usr/lib/system/libsystem_kernel.dylib (compatibility version 1.0.0, current version 1699.22.73)
</snip>

# nm /usr/lib/system/libsystem_kernel.dylib | grep fdatasync
0000000000017430 T _fdatasync

 
perhaps 'configure' should check that fdatasync is declared
(and not just linkable too), and use fdatasync only if it
is declared; that would be more-conservative.


It would be more conservative, but we really could use it since we have it defined in a library.  Unfortunately Apple did not include a header to define it properly.  It's your call though as I would think either way is fine (though some may prefer to actually have the fdatasync functionality).

 
Have you checked, via "grep -r fdatasync /usr/include/", whether
fdatasync is actually present anywhere?  It might be declared only
if some other symbol is #define'd, in which case, we should find
out what that is and #define it.


Yes I have checked, but I will leave you the results so that you candouble-check me...=)
> grep -R fdatasync /usr/include      
/usr/include/pg_config.h:/* Define to 1 if you have the declaration of `fdatasync', and to 0 if you
/usr/include/pg_config.h:/* Define to 1 if you have the `fdatasync' function. */
/usr/include/postgresql/internal/c.h:extern int fdatasync(int fildes);
/usr/include/postgresql/server/access/xlogdefs.h: * configure determined whether fdatasync() is.
/usr/include/postgresql/server/c.h:extern int fdatasync(int fildes);
/usr/include/postgresql/server/pg_config.h:/* Define to 1 if you have the declaration of `fdatasync', and to 0 if you
/usr/include/postgresql/server/pg_config.h:/* Define to 1 if you have the `fdatasync' function. */
/usr/include/postgresql/server/port/linux.h: * Set the default wal_sync_method to fdatasync.  With recent Linux versions,
/usr/include/postgresql/server/storage/fd.h:extern int pg_fdatasync(int fd);
/usr/include/python2.5/pyconfig.h:/* Define if you have the 'fdatasync' function. */
/usr/include/python2.5/pyport.h:extern int fdatasync(int);
/usr/include/python2.6/pyconfig.h:/* Define if you have the 'fdatasync' function. */
/usr/include/python2.6/pyport.h:extern int fdatasync(int);
/usr/include/python2.7/pyconfig.h:/* Define if you have the 'fdatasync' function. */
/usr/include/python2.7/pyport.h:extern int fdatasync(int);
/usr/include/sys/syscall.h:#define SYS_fdatasync      187 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]