bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Ozkan Sezer <sezeroz@gmail.com>
To: Bruno Haible <bruno@clisp.org>
Cc: bug-gnulib@gnu.org
Subject: Re: [PATCH] make gl_VISIBILITY to reject unsupported configurations with newer gcc
Date: Sat, 5 Jun 2021 19:21:10 +0300	[thread overview]
Message-ID: <CAA2C=vAU0gfVvz6_w8on=LfJa0PhdiLUZTcKsh=RbZTUEPning@mail.gmail.com> (raw)
In-Reply-To: <162293739.qyZAu42AHI@omega>

On 6/5/21, Bruno Haible <bruno@clisp.org> wrote:
> Ozkan Sezer wrote:
>> >> The attached patch makes gl_VISIBILITY to reject unsupported
>> >> configurations
>> >> with newer gcc: In its current form, mingw gcc-4.5.4 rejects the
>> >> attributes
>> >> but gcc-7.5 does not, apparently because the attributes are applied to
>> >> func
>> >> prototypes without their definitions.  Attaching a hidden visibility
>> >> attrib
>> >> to dummyfunc() makes gcc-7.5 to reject it properly.
>> >
>> > I don't fully understand why we should apply the patch.
>> >
>> > With gcc 7.5 on mingw and the visibility.m4 that is in gnulib now:
>> > What is the result of the
>> >   checking for simple visibility declarations...
>> > test? What are the effects: warnings? compilation errors? link errors?
>> > too
>> > many exported symbols? too few exported symbols?
>>
>> No warnings from the testcase in m4. In real-life, it results in
>> warnings,
>> see e.g.: https://github.com/libsndfile/libsamplerate/issues/154
>
> OK, I understand better now.
>
> In the GCC source code I see that the
>   "visibility attribute not supported in this configuration; ignored"
> warning is emitted when a definition is emitted. Therefore I think the
> safest patch is to add a definition for each declaration in the test code.
>
>
> 2021-06-05  Bruno Haible  <bruno@clisp.org>
>
> 	lib-symbol-visibility: Make configure check work for newer GCC.
> 	Reported by Ozkan Sezer <sezeroz@gmail.com> in
> 	<https://lists.gnu.org/archive/html/bug-gnulib/2021-05/msg00117.html>.
> 	* m4/visibility.m4 (gl_VISIBILITY): Add a function definition for each
> 	declaration in the test program.
>
> diff --git a/m4/visibility.m4 b/m4/visibility.m4
> index 8f27a12..d161bd7 100644
> --- a/m4/visibility.m4
> +++ b/m4/visibility.m4
> @@ -1,4 +1,4 @@
> -# visibility.m4 serial 7
> +# visibility.m4 serial 8
>  dnl Copyright (C) 2005, 2008, 2010-2021 Free Software Foundation, Inc.
>  dnl This file is free software; the Free Software Foundation
>  dnl gives unlimited permission to copy and/or distribute it,
> @@ -59,6 +59,10 @@ AC_DEFUN([gl_VISIBILITY],
>                extern __attribute__((__visibility__("hidden"))) int
> hiddenfunc (void);
>                extern __attribute__((__visibility__("default"))) int
> exportedfunc (void);
>                void dummyfunc (void);
> +              int hiddenvar;
> +              int exportedvar;
> +              int hiddenfunc (void) { return 51; }
> +              int exportedfunc (void) { return 1225736919; }
>                void dummyfunc (void) {}
>              ]],
>              [[]])],
>
>

Works for me:

configure:13230: checking for simple visibility declarations
configure:13261: x86_64-w64-mingw32-gcc -c -g -O2 -Wall
-fvisibility=hidden -Werror  conftest.c >&5
conftest.c: In function 'hiddenfunc':
conftest.c:37:15: error: visibility attribute not supported in this
configuration; ignored [-Werror=attributes]
               int hiddenfunc (void) { return 51; }
               ^~~
conftest.c: At top level:
conftest.c:47:1: error: visibility attribute not supported in this
configuration; ignored [-Werror=attributes]
 }
 ^
cc1: all warnings being treated as errors
configure:13261: $? = 1


      reply	other threads:[~2021-06-05 16:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25 15:54 [PATCH] make gl_VISIBILITY to reject unsupported configurations with newer gcc Ozkan Sezer
2021-05-25 23:54 ` Bruno Haible
2021-05-26  0:34   ` Ozkan Sezer
2021-06-05 15:10     ` Bruno Haible
2021-06-05 16:21       ` Ozkan Sezer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAA2C=vAU0gfVvz6_w8on=LfJa0PhdiLUZTcKsh=RbZTUEPning@mail.gmail.com' \
    --to=sezeroz@gmail.com \
    --cc=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).