Alan W. Irwin wrote:
>
> Here is what I suggest you and Werner do to follow up on this. You have
> already indicated earlier in this thread you were not quite sure about
> what
> circumstances required use of __declspec(dllimport). So I suggest you
> look
> very carefully at all traditional and
On 2008-09-12 09:07+0200 Arjen Markus wrote:
> - Are symbols imported from the C library to accommodate the Fortran or other
> bindings automatically visible via these other libraries? I mean: is the
> visibility
> transitive?
Fortunately, the above complicated case does not apply to our Fortran
Alan W. Irwin wrote:
>
> Nevertheless, every time there is a Windows visibility issue, you would
> wonder whether ignoring dllimport for the undefined symbols for some
> of our
> libraries is the culprit. Furthermore, for consistencies sake, since the
> import issue is treated properly for libpl
Hi Andrew:
In my reading about visibility for C and C++ for gcc on Linux, I can find
no reference to _import_ visibility in the gcc info pages, the Ulich Drepper
reference, or in
http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html
Thus,
On 2008-09-11 09:11+0200 Arjen Markus wrote:
> Werner Smekal wrote:
>
>>
>> I think that you are actually right. We would need MAKINGPLCXXDLL (for the
>> source) and USINGPLCXXDLL (for the examples) definitions. And since the
>> cpp library uses c functions from liplplotd USINGPLDLL must be def
Hi Arjen,
just a short note:
> and g95 installation kicked in). I moved that out of the way (renamed
> the MSYS
> installation directory) and then found out that the GCC distribution I
> had installed
> (version 4.2.1) was incomplete: no linker (ld) program.
>
Since you installed 4.2.1 "by ha
Werner Smekal wrote:
>
> I think that you are actually right. We would need MAKINGPLCXXDLL (for
> the source) and USINGPLCXXDLL (for the examples) definitions. And
> since the cpp library uses c functions from liplplotd USINGPLDLL must
> be defined. I wonder, why it worked so far for Windows.
Hi,
Alan W. Irwin wrote:
> On 2008-09-10 18:08+0100 Andrew Ross wrote:
>
>> On Wed, Sep 10, 2008 at 09:22:48AM -0700, Alan Irwin wrote:
>>> [...]Also, notice that libplplotd uses
>>> some DLL symbols and also makes others. That is handled by PROPERTIES
>>> COMPILE_FLAGS "-DMAKINGPLDLL -DUSINGCSA
On 2008-09-10 18:08+0100 Andrew Ross wrote:
> On Wed, Sep 10, 2008 at 09:22:48AM -0700, Alan Irwin wrote:
>> [...]Also, notice that libplplotd uses
>> some DLL symbols and also makes others. That is handled by PROPERTIES
>> COMPILE_FLAGS "-DMAKINGPLDLL -DUSINGCSADLL -DUSINGNNDLL". Similarly,
>> s
On Wed, Sep 10, 2008 at 09:22:48AM -0700, Alan Irwin wrote:
> On 2008-09-10 08:47+0200 Arjen Markus wrote:
>
> >Hi Alan, Andrew,
> >
> >what may be hidden because of all the #ifdefs is that for the
> >Windows/MSVC/(I|C)VF
> >case we do use the PLDLLEXPIMP macro, so the visibility issue _is_ taken
On 2008-09-10 08:47+0200 Arjen Markus wrote:
> Hi Alan, Andrew,
>
> what may be hidden because of all the #ifdefs is that for the
> Windows/MSVC/(I|C)VF
> case we do use the PLDLLEXPIMP macro, so the visibility issue _is_ taken care
> of.
The C++ case is pretty simple, but I cannot figure it ou
Alan W. Irwin wrote:
> There are some questions below for Arjen and Werner in addition to my
> response to some of Andrew's comments.
>
>
>
> Here is a question for Arjen and Werner. One thing I am confused about at
> the present time is whether there has been any visibility work done
> yet for
>
On Tue, Sep 09, 2008 at 04:08:12PM -0700, Alan Irwin wrote:
> There are some questions below for Arjen and Werner in addition to my
> response to some of Andrew's comments.
>
> On 2008-09-09 23:21+0100 Andrew Ross wrote:
>
> >From a more general point of view, I suspect this won't have a
> >large
There are some questions below for Arjen and Werner in addition to my
response to some of Andrew's comments.
On 2008-09-09 23:21+0100 Andrew Ross wrote:
> From a more general point of view, I suspect this won't have a
> large time or size impact on plplot.
> [...]That aside, this is probably the
On Tue, Sep 09, 2008 at 11:55:56AM -0700, Alan Irwin wrote:
> Hi Andrew:
>
> Thanks very much for all your Linux GCC visibility fixups this morning.
> As of revision 8761, I get a completely clean build of a fully configured
> plplot. To be specific my cmake options for this full configuration we
Hi Andrew:
Thanks very much for all your Linux GCC visibility fixups this morning.
As of revision 8761, I get a completely clean build of a fully configured
plplot. To be specific my cmake options for this full configuration were
my usual ones, i.e.,
-DCMAKE_INSTALL_PREFIX=$prefix and
-DBUILD_TE
On 2008-09-08 21:54+0100 Andrew Ross wrote:
> A quick look suggests some implementational issues with the gcc
> visibility stuff.
>
> The #pragma statements are at the beginning / end of plplot.h. This
> means anything defined elsewhere (for example in plplotP.h) will be
> public by default. Funct
On Sat, Sep 06, 2008 at 09:00:22PM +0100, Andrew Ross wrote:
> On Fri, Sep 05, 2008 at 05:56:02PM -0700, Alan Irwin wrote:
> > Revision 8753 makes infrastructure available to
> > play with gcc-4.x visibility following what was done for the Windows
> > compiler
> > cases and following the ideas in
On Fri, Sep 05, 2008 at 05:56:02PM -0700, Alan Irwin wrote:
> Revision 8753 makes infrastructure available to
> play with gcc-4.x visibility following what was done for the Windows compiler
> cases and following the ideas in http://gcc.gnu.org/wiki/Visibility.
>
> The idea here is any symbol marke
19 matches
Mail list logo
