On 2011-09-06 11:52+0100 Andrew Ross wrote:
> On Sat, Sep 03, 2011 at 10:47:52PM +0100, Andrew Ross wrote:
>> I've played around and it looks like the best thing to do is exactly
>> the same trick I used to get the matwrapped octave bindings to work
>> with -fvisibility=hidden, namely to put
>>
>> #if defined(__GNUC__) && __GNUC__ > 3
>> #pragma GCC visibility push(default)
>> #endif
>>
>> before the function definition of plplot_octave - the line starting with
>> DEFUN_DLD in the code
>>
>> and then
>>
>> #if defined(__GNUC__) && __GNUC__ > 3
>> #pragma GCC visibility pop
>> #endif
>>
>> after the function definition. I've tested this and it works. This patch
>> would best be merged into swig until octave fixes visibility support,
>> but in the meantime does anyone have an idea what the best way to
>> postprocess the swig generated code is in order to do this in plplot?
>
> 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).
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
__________________________
------------------------------------------------------------------------------
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
