apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 46175] Full Mingw+MSys support
Date Fri, 01 Apr 2011 13:34:16 GMT

--- Comment #25 from Carlo Bramini <carlo.bramix@libero.it> 2011-04-01 09:34:12 EDT
You are right, this fact escaped to my attention.
The presence of "-DAPR_DECLARE_EXPORT" into apr-2-config is a damage because
the declaration of public functions will be always prefixed by __dllexport
rather than __dllimport.
Instead, "-DAPR_DECLARE_STATIC" is required for a static build even by client
In my opinion the solution is to separate the flags used by compilation of APR
itself from the ones used by client applications:
static build: APR_DECLARE_STATIC for both.
shared build: APR_DECLARE_EXPORT when compiling APR and no additional macros
for client apps.

Is there already this chance available in APR building system?

There is also another alternative, that could automatically solve the trouble,
at least in theory: remove all APR_DECLARE_STATIC and APR_DECLARE_EXPORT
additions (and also APU_MODULE_DECLARE_STATIC since we are fixing) to apr.h.in,
remove the same addition in configure.in and just tell to libtool to export all
symbols, we just need to add an options to its flags.

I think that the second choice would be better, if things are getting too

Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org

View raw message