acl-devel
[Top][All Lists]
Advanced

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

Re: [Acl-devel] [RFC] Add attribute visibility("default") to API functio


From: Yury Usishchev
Subject: Re: [Acl-devel] [RFC] Add attribute visibility("default") to API functions
Date: Wed, 24 Feb 2016 13:18:43 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Hello all!

Andreas Grünbacher <address@hidden> writes:
> Can we leave the #ifndef ... #endif clause out of the public headers
> and install them through "sed -e 's:ACL_API_EXPORT:extern:g'"? If so,
> can we also rename ACL_API_EXPORT to EXPORT so that the indentation
> will stay the same.

The problem that I am trying to solve is build fail(and incorrect build of 
library) when -fvisibility=hidden CFLAGS is
enabled:

CFLAGS="-O2 -g -flto -fvisibility=hidden" AR=gcc-ar RANLIB=gcc-ranlib 
../configure

By enabling such CFLAGS I want to allow compiler to use information about 
(explicitly) exported and hidden symbols to use
more aggressive optimizations.


This problem can be solved only by explicitly marking API functions with 
default visibility.
This marking can be done in several(identical from compilers point of view) 
ways:

1) ACL_API_EXPORT as in last proposed patch. This adds visibility attribute to 
each API function through C preprocessor.
Also hides visibility information from users of library, as it is useless to 
them.

As drawback we have one more macros in public headers that will be available to 
users.

2) EXPORT as Andreas proposed. Same as 1) but we use sed to remove macro from 
headers at install time.
User headers are not changed at all.

As drawback we have to use sed at install time.

3) GCC pragmas:
#ifdef ACL_API_EXPORT
#pragma GCC visibility push(default)
#endif

We can even use HAVE_VISIBILITY_ATTRIBUTE define here

This way does not use sed:) and does not create additional macro available to 
users.
But we have some useless to user lines in headers and in some conditions 
provide to users useless visibility
information.


>From these options I prefer whichever will get accepted :)
If some agreement will be achieved I can prepare appropriate patch.

PS. Same approach is likely to be used in attr later

BR,
Yury Usisichev



reply via email to

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