discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] gnuradio library symbol visibility


From: Josh Blum
Subject: [Discuss-gnuradio] gnuradio library symbol visibility
Date: Mon, 20 Dec 2010 16:54:00 -0800
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7

Currently there is nothing in gnuradio to control the visibility of
symbols. That is, everything in every header file is probably an
exported symbol right now, though in many cases, that may not be desired.

GCC documents what they call "symbol visibility" here (see the macro
towards the bottom): http://gcc.gnu.org/wiki/Visibility

Basically, whenever a symbol is meant to be part of the API (called
through the library), you define it with a special macro:

Example:

class foo{..} becomes class GR_API foo{...}
void bar(...) becomes GR_API void bar(...)

The catch here is that libraries would be (in the case of GCC only)
built with -fvisibility=hidden. So if a class does not have the special
macro, it will not be available to the linked application.

This nice part is that this is easy to debug because a missing symbol
export will cause an obvious linker error when linking against a
dependent library.

---------------------------------------------------------------------
I would like to add to header files in gnuradio, the explicit
exportation of symbols that are supposed to be in the public API.

I will start off by adding the export macro to the headers of major
components and checking that it compiles as I go. These changes could be
safely merged into the next branch and not affect anybody's build so
long as the compiler option "-fvisibility=hidden" is unspecified by
default. When the work is completed, and we are comfortable with the
changes "-fvisibility=hidden" would be set by default.

This gives gnuradio a path to building in environments that require
explicit symbol exportation and importation. Example" building native on
windows with MSVC. Also, being explicit about the API and the available
symbols in a library seems to be a good thing to do.

Thanks,
-Josh



reply via email to

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