Re: Exporting Symbols...
Re: Exporting Symbols...
- Subject: Re: Exporting Symbols...
- From: Andreas Grosam <email@hidden>
- Date: Sat, 23 Jul 2005 18:17:06 +0200
On 22.07.2005, at 19:44, Dave Thorup wrote:
On Jul 22, 2005, at 12:27 PM, Chris Espinosa wrote:
Try the visibility attributes in gcc 4.0. They're meant to be
parallel to __declspec. In fact you can define a macro that expands
to __declspec(dllexport) on Windows and
__attribute__((visibility("default"))) on Mac.
http://developer.apple.com/documentation/DeveloperTools/Conceptual/
CppRuntimeEnv/Articles/SymbolVisibility.html
Thanks for the info on GCC 4. There are also pragmas that can be used:
#pragma GCC visibility push(default)
void g() { }
void h() { }
#pragma GCC visibility pop
This might be easier for us since it works more like the CodeWarrior
method.
This is all great for GCC 4.0, but what about those of us that need to
support Mac OS X 10.2.0? C++ binaries built with GCC 4.0 can only run
on 10.3.9 and later. Until you make it so that GCC 4.0 supports
10.2.0 and later we will not be able to use it.
So, is there any other way (besides an exported symbols file) to
export symbols with GCC 3.3?
gcc exports all symbols by default.
For gcc-3.x you need an exported symbols file to limit exported symbols.
For gcc-4.x, you may change the default so that all symbols are private
extern per default (== visibility = hidden). There are two Build
settings which you need to enable:
Symbols Hidden by Default
Inline Functions Hidden
Then in your sources use macros to explicitly export classes,
functions, static variables, member functions, etc. only if this is
required:
class API_EXPORT MyPublicClass { /*...*/}; // exported
class MyPrivate {}; // local, or private extern.
A portable solution for your export macros may look like this:
// file export_macros.h
#include "config.h" // determine compiler capabilities, e.g.
GCC_HAS_VISIBILITY_ATTR
//
------------------------------------------------------------------------
----
// Export macros
//
------------------------------------------------------------------------
----
#ifdef _MSC_VER
# ifdef BUILDING_DLL
# define API_EXPORT __declspec(dllexport)
# else
# define API_EXPORT __declspec(dllimport)
# endif
# define API_LOCAL
#elif defined (__GNUC__)
# ifdef GCC_HAS_VISIBILITY_ATTR
# define API_LOCAL __attribute__ ((visibility ("hidden")))
# define API_EXPORT __attribute__ ((visibility ("default")))
# else
# define API_LOCAL
# define API_EXPORT
# endif
#else
# error Unsupported Compiler in Configuration
#endif
// Throwable classes must always be visible in all DSOs
#ifdef _MSC_VER
# define EXCEPTION_API(api) api
#elif defined (__GNUC__)
# ifdef GCC_HAS_VISIBILITY_ATTR
# define EXCEPTION_API(api) API_EXPORT
# else
# define EXCEPTION_API(api)
# endif
#else
# error Unsupported Compiler in Configuration
#endif
btw: some noted, that gcc-3.3 does not generate better code, i
disagree. If you carefully and intensively leverage the visibility
attributes, less functions will be exported and can be kept private
local, and thus the compiler is able to apply better optimizations.
I observed 30% better performance in some heavy templatized code with
many inlined functions, which would otherwise not be inlined.
Furthermore, when variables and functions are exported access is more
costly.
Regards
Andreas
Thanks
_____________________________
Dave Thorup
Software Engineer
email@hidden
http://www.kuwan.net
Defaults Manager - The premier editor for Mac OS X's User Defaults /
Preferences database.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden