On 2011-09-08 12:41+0100 Andrew Ross wrote:
> On Wed, Sep 07, 2011 at 12:46:23PM -0700, Alan Irwin wrote:
>> On 2011-09-06 11:52+0100 Andrew Ross wrote:
>>
>>>
>>> I've committed a perl script to do this. It would be nicer to do it in
>>> sed but I'm not sure how. The old octave bindings required perl anyway
>>> so it is not an extra constraint. I have not yet modified CMakeFiles.txt
>>> to actually call the script as I'm not sure how to do this neatly to
>>> integrate with the cmake SWIG support. Alan, do you have any thoughts
>>> on the best way to do this?
>>
>> Before commenting on that, I want to be sure I have the correct
>> overview of what you are trying to do. My apologies in advance if you
>> have already covered this overview in previous e-mails, but I have been
>> distracted by non-PLplot development this summer so I have not been
>> paying as close attention as usual.
>>
>> My understanding is
>>
>> #pragma GCC visibility push(default)
>>
>> is the same thing as a temporary use of -fvisibility=default for all
>> the code until
>>
>> #pragma GCC visibility pop
>>
>> In other words this is just a workaround installed into the source
>> code for some problem for gcc and Octave with -fvisibility=hidden.
>>
>> IIRC, you mentioned in previous e-mails that the issue occurred
>> because of a problem for one of the octave headers we were using, but
>> is the proposed fix for that case also a workaround like above, or is
>> it a real fix? If there is a real fix, why can't we deploy that same
>> fix ourselves rather than using a workaround?
>>
>> Assuming your answer to this overview question is we could deploy the
>> real fix ourselves, then I suggest that you implement that. Here are two
>> possible
>> approaches I am thinking about that make sense from the CMake
>> perspective.
>>
>> (1) From the man page, CMake allows you to
>>
>> SET_SOURCE_FILES_PROPERTIES( ${swig_generated_file_fullname}
>> PROPERTIES COMPILE_FLAGS "-bla")
>>
>> So if the real fix for the octave header can be reduced to defining
>> and undefining a series of macro values with the -D and -U options,
>> then I suggest this is the way to go.
>>
>> (2) Alternatively, if the real fix demands a more complicated octave
>> header transformation than can be expressed as a series of
>> preprocessing #define and #undef commands, then I suggest a sed or perl
>> script is
>> the right way to go to transform the octave header before we use it.
>>
>> The problem with your present proposal (besides it being a workaround)
>> is that I am not sure how easy it is going to be to modify
>> swig-generated source code from the CMake level. The relevant CMake
>> logic appears to be
>>
>> # Set up swig + c wrapper.
>> swig_add_module(plplot_octave octave plplot_octave.i)
>> swig_link_libraries(
>> plplot_octave ....
>>
>> But I am virtually certain the first command sets up run-time
>> generation of the appropriate octave interface code AND the run-time
>> build of that code into a shared object, while the second simply
>> modifies how that build is linked.
>>
>> To interfere in that process and modify the code after it is generated
>> at run time but before it is built into a shared object may require a
>> special version of FindSWIG.cmake and/or UseSwig.cmake that we
>> maintain from now on. I would prefer to avoid that maintenance burden
>> if at all possible so I think transforming the octave header in one of
>> the two alternative ways I mentioned above would be a better way to
>> go (and also give us access to the real fix if that is known).
>>
>
> What plplot does and what swig also does on the whole is to explicitly
> mark any function which is to be exported with
> __attribute__ ( ( visibility( "default" ) ) )
> on gcc version > 3. With -fvisibility=hidden then anything not explicitly
> exported is hidden. We do this through all the PLDLLxxx macros in pldll.h
> The same macros are defined differently to import / export functions with
> windows. This makes it easy to write code which will work on multiple
> systems.
>
> Octave also defines an OCTAVE_EXPORT macro in oct-dlldefs.h which does
> this job on windows, but is not defined at all on gcc. To my mind the
> best fix would be for octave to define OCTAVE_EXPORT as
> __attribute__ ( ( visibility( "default" ) ) )
> on gcc. Unfortunately the definition of OCTAVE_EXPORT in oct-dlldefs.h is
> unconditional so there is no way to over-ride it with compiler flags. This
> rules out option (1)
I was thinking along the lines of #including the following header
_before_ any other octave header
#include <oct-dlldefs.h>
#if !defined (_MSC_VER)
#undef OCTAVE_EXPORT
#define OCTAVE_EXPORT __attribute__ ( ( visibility( "default" ) ) )
#endif
(I am oversimplifying here since we would want to check gcc version,
etc., but I assume you have already thought of this idea so understand
what I am driving at).
But when I looked up
build_dir/bindings/octave/plplot_octaveOCTAVE_wrap.cxx
it #included plplotP.h long after all the octave includes.
Is there a swig directive to force our headers to be #defined
first? If so, I believe this idea would work. I
couldn't find anything that seemed relevant at
http://www.swig.org/Doc1.3/Preprocessor.html, but you might
want to take a look there yourself. Or maybe you have already
decided there is no way to make this work with swig and
moved on?
>
> You could try to locate and massage oct-dlldefs.h automatically with
> cmake using a perl / sed scripti (option 2). The gcc -M option would
> find the absolute path of the include file, then use sed to replace the
> definition of OCTAVE_EXPORT. The following should do it.
>
> cat "#include <octave/oct-dlldefs.h>" > test.c
> mkdir -p octave
> sed -e 's/^#define OCTAVE_EXPORT$/#define OCTAVE_EXPORT __attribute__ ( (
> visibility( "default" ) ) )/' `gcc -M test.c |cut -d\ -f 3` >
> octave/oct-dlldefs.h
>
> You'd probably want to add some include path stuff to the gcc options
> in case the octave headers were in a non-standard location. If the
> masssaged version of octave oct-dlldefs.h appeared in the
> bindings/octave/octave directory then it should be picked up by the
> build ahead of the system version. Note the only complication is the
> need to create the octave subdirectory since the include file is
> referenced as octave/oct-dlldefs.h.
>
> My solution using the #pragma statements is an alternative way of
> marking a function to be exported and seems to be a little less error
> prone in this case. It's what I did in the old octave bindings to
> work round the same problem. The net effect should be the same
> as redefining OCTAVE_EXPORT, but it is more transparent. I agree
> with your analysis of the problems with the CMake swig support. This
> was the conclusion I reached, hence asking if you had any better ideas!
Sorry, I couldn't help you there.
It's frustrating that we know what we want to do, but CMake blocks us
from doing that easily, and it appears swig does as well. I will ask further
on the swig list about possibilities for getting our header included
first, but that might not lead to a solution.
>
> Anyway, the best long-term solution is probably to submit an octave
> bug report to get the octave header file fixed.
Yes, please!
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
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
