[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GL_LINK_WARNING
From: |
Eric Blake |
Subject: |
Re: GL_LINK_WARNING |
Date: |
Tue, 15 Dec 2009 21:37:15 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
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
- fcntl for mingw, Eric Blake, 2009/12/10
- Re: fcntl for mingw, Bruno Haible, 2009/12/11
- Re: GL_LINK_WARNING (was: fcntl for mingw), Bruno Haible, 2009/12/15
- Re: GL_LINK_WARNING, Eric Blake, 2009/12/15
- Re: GL_LINK_WARNING (was: fcntl for mingw), Eric Blake, 2009/12/16
- Re: GL_LINK_WARNING, Eric Blake, 2009/12/16
- Re: GL_LINK_WARNING, Bruno Haible, 2009/12/16
- Re: GL_LINK_WARNING, Eric Blake, 2009/12/16
- Re: GL_LINK_WARNING, Bruno Haible, 2009/12/19
- Re: GL_LINK_WARNING, Jim Meyering, 2009/12/16
- va-args (was: GL_LINK_WARNING), Eric Blake, 2009/12/23