Hi,
I just admitted lot of changes to get this import/export issue right.
What I basically did I explain in pldll.h:
#ifndef __PL_DLL_H
#define __PL_DLL_H
************************************************************************
This is now different. We only get into this part of the header file, if
USINGDLL is defined. This macro must be defined if a static library is
built or used. Depending on the compiler PLDLLEXPORT and PLDLLIMPORT are
correctly defined. These macros should not be used in source or header
files.
************************************************************************
#ifdef USINGDLL
#if defined(WIN32)
/* Visual C/C++, Borland, MinGW and Watcom */
#if defined(__VISUALC__) || defined(_MSC_VER) ||
defined(__BORLANDC__) || defined(__GNUC__) || defined(__WATCOMC__)
#define PLDLLEXPORT __declspec(dllexport)
#define PLDLLIMPORT __declspec(dllimport)
#else
#define PLDLLEXPORT
#define PLDLLIMPORT
#endif
#elif defined(__CYGWIN__)
#define PLDLLEXPORT __declspec(dllexport)
#define PLDLLIMPORT __declspec(dllimport)
#elif defined(__GNUC__) && __GNUC__ > 3
/* Follow ideas in http://gcc.gnu.org/wiki/Visibility for GCC
version 4.x
* The following forces exported symbols specifically designated with
* PLDLLEXPORT to be visible. */
#define PLDLLEXPORT __attribute__ ((visibility("default")))
#define PLDLLIMPORT
#endif
#endif
************************************************************************
If USINGDLL was not defined (static library) or for an unknown compiler
we clear the PLDLLEXPORT/PLDLLIMPORT macros.
************************************************************************
/* For an unknown compiler or static built we clear the macros */
#ifndef PLDLLEXPORT
#define PLDLLEXPORT
#define PLDLLIMPORT
#endif
************************************************************************
So for every single shared library we have we set corresponding macros,
e.g. for the c++ bindings PLDLLIMPEXP_CXX. If this library is just
built, cmake sets the plplotcxxd_EXPORTS macro - in this case we use the
PLDLLEXPORT macro. If the plplotcxxd_EXPORTS macro is not defined, we
use the library (or not at all) and we use the PLDLLIMPORT macro. In my
opinion this should get all the correct imports/exports right (if you
use the correct macro in your source and header files).
************************************************************************
/* The IMPEXP macros will always be set to DLLIMPORT (even for
the static library, but DLLIMPORT is empty in this case), if
cmake didn't set the corresponding macro xxxx_EXPORTS when the
corresponding library is built (DLLIMPEXP is set to DLLEXPORT
then) */
#if defined(plplotd_EXPORTS)
#define PLDLLIMPEXP PLDLLEXPORT
#define PLDLLIMPEXP_DATA(type) PLDLLEXPORT type
#else
#define PLDLLIMPEXP PLDLLIMPORT
#define PLDLLIMPEXP_DATA(type) PLDLLIMPORT type
#endif
#if defined(plplotcxxd_EXPORTS)
#define PLDLLIMPEXP_CXX PLDLLEXPORT
#define PLDLLIMPEXP_CXX_DATA(type) PLDLLEXPORT type
#else
#define PLDLLIMPEXP_CXX PLDLLIMPORT
#define PLDLLIMPEXP_CXX_DATA(type) PLDLLIMPORT type
#endif
#if defined(plplotf77d_EXPORTS)
#define PLDLLIMPEXP_F77 PLDLLEXPORT
#define PLDLLIMPEXP_F77_DATA(type) PLDLLEXPORT type
#else
#define PLDLLIMPEXP_F77 PLDLLIMPORT
#define PLDLLIMPEXP_F77_DATA(type) PLDLLIMPORT type
#endif
#if defined(plplotf95d_EXPORTS)
#define PLDLLIMPEXP_F95 PLDLLEXPORT
#define PLDLLIMPEXP_F95_DATA(type) PLDLLEXPORT type
#else
#define PLDLLIMPEXP_F95 PLDLLIMPORT
#define PLDLLIMPEXP_F95_DATA(type) PLDLLIMPORT type
#endif
#if defined(plplotwxwidgetsd_EXPORTS)
#define PLDLLIMPEXP_WX PLDLLEXPORT
#define PLDLLIMPEXP_WX_DATA(type) PLDLLEXPORT type
#else
#define PLDLLIMPEXP_WX PLDLLIMPORT
#define PLDLLIMPEXP_WX_DATA(type) PLDLLIMPORT type
#endif
#endif /* __PL_DLL_H */
************************************************************************
This works for me now for Win32, C and C++. I switch now to Linux to see
if it still works :). If not I have to revert a lot of files ;). Things
left to do are now the shared drivers. I hope that cmake also sets a
export macro for this case, but here we defined only one import/export
macro for all drivers, since the drivers don't depend on each other,
e.g.
#if defined(svg_EXPORTS) && defined(ps_EXPORTS) .....
#define PLDLLIMPEXP_DRIVER PLDLLEXPORT
#define PLDLLIMPEXP_DRIVER_DATA(type) PLDLLEXPORT type
#else
#define PLDLLIMPEXP_DRIVER PLDLLIMPORT
#define PLDLLIMPEXP_DRIVER_DATA(type) PLDLLIMPORT type
#endif
Let's see if this works.
Regards,
Werner
Alan W. Irwin wrote:
> Arjen said:
>
>> If I understand the issue of IMPORT/EXPORT correctly, then:
>> - EXPORT is always necessary to make the function visible
>> outside the DLL.
>> - IMPORT is used to tell the linker that the function is coming
>> from another library, so that it can prepare for a faster call
>> (otherwise one or two extra instructions are required).
>> - IMPORT is _not_ needed for a function when that function is
>> called by another function in the same library - it makes
>> the call less efficient even. So, IMPORT should go into
>> the header files exclusively.
>>
>> The situation Andrew describes with the dynamic drivers can be
>> schematised as follows:
>>
>> We have functions A and B in the core library and function C
>> in the driver library. A uses C and C uses B.
>>
>> When making the core library:
>>
>> EXPORT: A (if it is part of the public interface or used by the bindings)
>> EXPORT: B (because it is needed - at least - by the driver)
>> IMPORT: C (as it is used by A)
>>
>> When making the driver library:
>>
>> EXPORT: C (part of the "public" interface of the driver)
>> IMPORT: B (C needs to call it)
>>
>> If this schema is complete and I read the sources (and especially
>> the header files) correctly, then we do have an issue with the
>> IMPORT part:
>>
>> When compiling the driver library:
>>
>> #include "plplotP.h" <-- PLDLLIMPEXP is defined and so are the
>> import/export attributes for A and B
>> from the core library. So, as we are
>> compiling a DLL: the attribute is EXPORT
>> #include "drivers.h" <-- defines the atttribute for C to be
>> PLDLLIMPEXP and therefore EXPORT
>>
>> It would seem necessary to have a setup in the driver library as:
>>
>> #define USINGDLL
>> #include "plplotP.h" <-- IMPORT: A, B (only B needed)
>> #undef USINGDLL
>> #define MAKINGDLL
>> #include "pldll.h"
>> #include "drivers.h" <-- EXPORT: C
>>
>> and in the core:
>>
>> #define USINGDLL
>> #include "pldll.h"
>> #include "drivers.h" <-- IMPORT: C
>> #define MAKINGDLL
>> #include "plplotP.h" <-- EXPORT: A, B
>>
>> Please examine this carefully, because it is fairly complicated
>> and the IMPORT attribute has only a subtle effect (that is: it
>> affects the performance, getting it wrong will not cause a
>> compile or link error!).
>
> I suggest you simplify the above logic by separating the driver namespace
> from the core library one just as we currently do for the csa and nn
> libraries. What I had in mind was using MAKINGDRDLL, USINGDRDLL,
> DRDLLEXPORT, DRDLLIMPORT, and DRDLLIMPEXP for the driver-related symbols
> with MAKINGPLDLL, USINGPLDLL, PLDLLEXPORT, PLDLLIMPORT, and PLDLLIMPEXP
> strictly reserved for the core library symbols. If you follow my
> suggestion, I don't think you will have to change the order of #includes or
> change from USING to MAKING in mid-stream like you suggest above.
>
> Instead, for the dynamic device case (ENABLE_DYNDRIVERS=ON) build libplplotd
> with -DMAKINGPLDLL -DUSINGCSADLL -DUSINGNNDLL -DUSINGDRDLL, and build the
> dynamic devices with -DMAKINGDRDLL -DUSINGPLDLL. This way of doing things
> is only a small conceptual departure from what we do now (USING and MAKING
> controlled by CMake, xxxDLLIMPEXP used in the headers and defined as import
> or export depending on whether USING or MAKING). The only real difference
> from what we have now in my proposal is the driver/library namespace
> separation issues are dealt with properly.
>
> I should also mention that separating the driver namespace from the core
> library one is also important for the (usual Windows) case where dynamic
> loading of drivers is disabled (ENABLE_DYNDRIVERS=OFF). In this case, the
> device driver code is put into libplplotd so import/export of library and
> driver code with each other is no longer relevant. Instead, we want to
> hide all driver symbols from the external world in this case. That is
> easily arranged by setting DRDLLIMPEXP to nothing while setting PLDLLIMPEXP
> to the appropriate value.
>
> 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); PLplot scientific plotting software
> package (plplot.org); 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
> __________________________
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Plplot-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
--
Dr. Werner Smekal
Institut fuer Allgemeine Physik
Technische Universitaet Wien
Wiedner Hauptstr 8-10
A-1040 Wien
Austria
email: [EMAIL PROTECTED]
web: http://www.iap.tuwien.ac.at/~smekal
phone: +43-(0)1-58801-13463 (office)
+43-(0)1-58801-13469 (laboratory)
fax: +43-(0)1-58801-13499
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
