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)
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!
Anyway, the best long-term solution is probably to submit an octave
bug report to get the octave header file fixed.
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
