Re: autoconf macro for gcc symbol visibility

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

Re: autoconf macro for gcc symbol visibility

Ralf Wildenhues
* J.T. Conklin wrote on Tue, May 31, 2005 at 08:37:44PM CEST:

> Ralf Wildenhues <[hidden email]> writes:
> > * J.T. Conklin wrote on Sun, May 29, 2005 at 07:34:46PM CEST:
> >> Does anyone have a macro for testing gcc's symbol visibility options
> >> (-fvisibility=hidden, etc.)?  The ACE/TAO autoconf scripts currently
> >> checks for gcc/g++ >= 4.0, but that loses on non-ELF targets.
> >
> > I believe some Intel compilers support it as well.
> > Why don't you temporarily add this to CFLAGS/CPPFLAGS and test whether
> > the compiler barfs at the option?
> gcc/g++ appears to silently accept the visibility options (at least
> the version Apple distributes does).  The ACE library compiled fine,
> but the test programs failed to link.  An autoconf macro may have to
> compile and link several files together to test this.

I don't understand: gcc (which version?) accepts the option and does
exactly what on non-ELF targets?  I believe it should either warn or
just ignore it, but how can your code fail then?  Do you perchance
depend on hidden visibility being available?  If so, then please note
that your code is not portable to some systems.  I guess you knew that,
though (I actually rather think I have just misunderstood you).

> I'm not opposed to writing the autoconf macro, but I was hoping that
> someone had already done it.

I don't know of such a macro myself.


Autoconf mailing list
[hidden email]
Reply | Threaded
Open this post in threaded view

Re: autoconf macro for gcc symbol visibility

Ralf Wildenhues
Hi Stepan,

* Stepan Kasal wrote on Tue, May 31, 2005 at 08:30:03PM CEST:

> On Tue, May 31, 2005 at 05:27:08PM +0200, Ralf Wildenhues wrote:
> > Note also that some compilers won't error out on unknown flags (esp
> > Intel ones :)  but only issue a warning.  This may or may not matter for
> > you.  If it does: For example, Libtool-1.5.18 employs some trickery to
> > find out the difference (see AC_LIBTOOL_COMPILER_OPTION in libtool.m4):
> > compile a simple translation unit once without and once with the option
> > and compare the warnings generated.  BTW, if there is sufficient
> > interest, I could try to make a macro like this for general use to
> > Autoconf users (AC_LIBTOOL_COMPILER_OPTION is libtool-internal
> > interface).
> this looks as a general problem, so I guess the solution would really
> belong to Autoconf.

The problem to the "solution" is not well specified (yet).  Suppose I
want to check whether the compiler understands a given option.  First,
it may (and will) depend on the source file used.  Should that be user-
specified or rather whatever is the calculated by AC_LANG_PROGRAM and
the like?  For example, a given option `-DFOO=bar' will succeed, fail,
or warn depending on the source given.  Surely one might argue that such
an option is not a good candidate for such a macro, but the input might
come from some other precomputation.

Then, after this is solved, there is the issue that in order to be
error-prove, one would have to do two compilations for each compiler
option in question, once with and once without (because in theory the
two can interact, plus maybe the source file may have changed in
between).  With more knowledge it may be possible to speed this up.

Also in this thread it was already noted that such a macro would not
test for functionality in the sense that the compiler may accept the
option, but it won't do what you want (which is kind of against the
Autoconf Way[tm]).

Same discussion goes for linker options, mostly.


Autoconf mailing list
[hidden email]