bug-coreutils
[Top][All Lists]
Advanced

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

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


From: Herb Wartens
Subject: 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]