Re: GL_LINK_WARNING

[Eric Blake]

Simon Josefsson <simon <at> josefsson.org> writes:

> > Another thing to consider.  Why are we even bothering with a link warning, 
> > which only works for ELF, when gcc provides a more generic solution that 
will 
> > also work for Cygwin and other non-ELF platforms?
> 
> Because gcc is not the only supported compiler?

We already have enough magic in place to turn the GL_LINK_WARNING output into a 
no-ops for non-gcc compilers.  Also, the point of GNULIB_POSIXCHECK was not 
whether other compilers can detect the problem, so much as making it easy for a 
random developer on Linux to quickly determine if they are using something that 
merely happened to work because they were on Linux, but would fail during 
porting to other platforms, without having to have access to the other 
platforms.  If other compilers can be taught to issue a similar warning - 
great.  But that is not the driving use case of why we introduced the 
GL_LINK_WARNING in the first place.

> 
> However, looking at link-warning.h, it seems it only works when the
> system uses GNU LD _and_ ELF.  So I'm not sure link-warning.h provides
> anything substantial that a Gcc-specific solution wouldn't.

More than that - the current link-warning.h is _already_ gcc-specific, thanks 
to the compound expression ({}), as evidenced by the __GNUC__ guard:

  /* This works on platforms with GNU ld and ELF object format.
     Testing __GLIBC__ is sufficient for asserting that GNU ld is in use.
     Testing __ELF__ guarantees the ELF object format.
     Testing __GNUC__ is necessary for the compound expression syntax.  */
# if defined __GLIBC__ && defined __ELF__ && defined __GNUC__

>  Are there
> popular environments that use GNU LD but not Gcc?

Maybe, but they won't represent a regression if we changed from a link warning 
to attribute((__warning__)), since they already fail the __GNUC__ portion of 
the above check.

Also, there are some non-GNU compilers that support some forms of __attribute__ 
(although our current usage pattern tends to use __attribute__ based on hard-
coded preprocessor tests against a minimum gcc version, rather than a more 
generic autoconf test for whether a particular attribute is supported by the 
current $CC).  So if we ever do add support for using __attribute__ on non-gcc, 
it can only help portability to go with an attribute rather than a link warning.

Meanwhile, I just filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42384, to 
see if we can get attribute((warning)) to also warn about the mere act of 
taking a function's address (since that represents one place that our current 
GL_LINK_WARNING warns but not the attribute).

>  Adding support for
> cygwin would be useful though.

Indeed.  So now that I have your vote of confidence, I'll probably start 
working on a proposal to implement my option 4, by revamping GNULIB_POSIXCHECK 
to use attributes rather than link warnings.

-- 
Eric Blake