[1] no idea if its a valid fix or just a workaround tho.
It looks like a reasonable workaround. There is a more fundamental
problem to address, if you've grep-ed your code for warnings. For
example, this kind of code generates a warning:
extern __dllimport int exit_failure;
int exit_failure = 1;
GCC 4.6.x and 4.7.x both expect consistency with declaration
attributes, despite the fact that the warnings are fairly harmless.
Unless a gettext maintainer says otherwise, I'm inclined to rework
the
Makefile.am and header files so that the suggestions from the "GCC
visibility" pages are implemented properly. That is, using libintl as
an
example:
- Change "DLL_VARIABLE" to something more meaningful, such as
"LIBINTL_VISIBILITY".
- config.h.in contains something like this:
#if HAVE_VISIBILITY && COMPILING_ON_WINDOWS_PLATFORM
# if BUILDING_LIBINTL
# define LIBINTL_VISIBILITY __declspec(dllexport)
# else
# define LIBINTL_VISIBILITY __declspec(dllimport)
# endif
#elif defined HAVE_VISIBILITY && BUILDING_LIBINTL
#define LIBINTL_VISIBILITY __attribute__((__visiblity__("default")))
#else
#define LIBINTL_VISIBILITY
#endif
- Eliminate the woe32dll "-export.c" files, since the declaration
attribute takes care of the problem.
- Introduce an install pre-hook that replaces "LIBINTL_VISIBLE" with
"__declspec(dllimport)" when the header files are installed on win32
and
win64.
Yes, I know it will probably break something on FreeBSD or Linux, but
the result will be a more robust code base and allow for future
function
visibility modifications for ELF DSOs.
-scooter
"GCC visibility" page:
intl-visibility.patch