On Mon, Sep 12, 2011 at 10:39:47AM -0700, Alan Irwin wrote: > On 2011-09-12 13:10+0100 Andrew Ross wrote: > >> >> Alan, >> >> Good idea. I was forgetting that you could redefine macros even after >> they had been used in further #define statements. > > Hi Andrew: > > I assume you have thoroughly tested that assumption so it must be > true, but that sure seems counter-intuitive to me, and I cannot find a > reference to it. Furthermore, K&H "The ANSI C Programming Language", > p. 89 state "subsequent occurrences of the token name will be replaced > ....", and that "subsequent" adjective seems to contradict the assumption.
Well to be honest I was rather surprised that it worked as I'd always assumed the contrary - which is why I didn't try this approach in the first instance. Anyway, following your email I tested it (with gcc-4.5) and it worked. Maybe this is a gcc feature? Anyway, the fix is limited to gcc. Still, further testing on different versions would be wise. You need to do something like CFLAGS="-fvisibility=hidden" CXXFLAGS="-fvisibility=hidden" cmake ../plplot to enable the gcc visibility options. The gcc manual seems to explain why this happens http://gcc.gnu.org/onlinedocs/cpp/Object_002dlike-Macros.html#Object_002dlike-Macros It works because all the occurences in oct-dlldefs.h are macros. > I now realize my previous idea implicitly depended on this assumption > as well because oct-dlldefs.h modifies other macros within it > depending on OCTAVE_EXPORT, and those won't get changed by my > subsequent OCTAVE_EXPORT redefinition if the assumption is incorrect. > > If further testing shows this assumption doesn't really work, then I > suggest a new idea which is we simply replace oct-dlldefs.h with our > own modified version where the replace the present OCTAVE_EXPORT > definition logic with the following logic (similar to what we do in > pldll.h(.in)): > > #if defined (_MSC_VER) > // Visual C/C++, Borland, MinGW and Watcom > #if defined ( __VISUALC__ ) || defined ( _MSC_VER ) || defined ( > __BORLANDC__ ) || defined ( __GNUC__ ) || defined ( __WATCOMC__ ) > #define OCTAVE_EXPORT __declspec(dllexport) > #else > #define OCTAVE_EXPORT > #endif > #elif defined ( __CYGWIN__ ) > #define OCTAVE_EXPORT __declspec(dllexport) > #elif defined ( __GNUC__ ) && __GNUC__ > 3 > #define OCTAVE_EXPORT __attribute__ ( ( visibility( "default" ) ) ) > #endif > > #ifndef OCTAVE_EXPORT > #define OCTAVE_EXPORT > #endif > > The only further issue is our updated header has to be #included > before any other octave header is #included (if the assumption fails). > In swig use the following directives > > %begin %{ > #include "oct-dlldefs_modified.h" > %} > > to accomplish that. The "#define octave_dlldefs_h 1" in our modified > header that is copied from the original means that further #includes > of oct-dlldefs.h effectively become preprocessor no-ops. I think this is probably not necessary for now. I'd rather not do this as it would be more work and might break with future octave versions. > Even if the assumption that the last #define of some token completely > supersedes previous #defines of that token is true so your present > solution works, then I suggest you modify that present solution so you > take full control of OCTAVE_EXPORT redefinition for all platforms > using preprocessor language like what I use above for the hypothetical > oct-dlldefs_modified.h. My approach was to make minimal interference, but I agree it is probably better to be consistent with pldll.h. Andrew ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
