Quantcast

More fun w/ dllexport and dllimport

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

More fun w/ dllexport and dllimport

Rich Collins
If I have libraries A, B and C where A and B use functions from C, I  
should __declspec(dllexport) in C.h when I compile the object files  
for C, but __declspec(dllimport) when I include C.h for compilation  
of A and B, right?

I will later combine libA.dll, libB.dll and libC.dll into libABC.dll,  
which will be used by other applications.  When these other  
applications are compiled, I will need to use __declspec(dllimport)  
in the headers for A, B and C?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Greg Chicares-2
On 2007-11-17 06:22Z, Rich Collins wrote:
> If I have libraries A, B and C where A and B use functions from C, I  
> should __declspec(dllexport) in C.h when I compile the object files  
> for C, but __declspec(dllimport) when I include C.h for compilation  
> of A and B, right?

Right. Usually macros are used, e.g.:

/* Begin lib_c.h */
#if defined BUILDING_LIB_C
#   define EXP_IMP_LIB_C __declspec(dllexport)
#elif defined USING_LIB_C
#   define EXP_IMP_LIB_C __declspec(dllimport)
...

void EXP_IMP_LIB_C lib_c_function();
/* End lib_c.h */

/* Begin lib_c.c */
void lib_c_function()
{
...
}
/* End lib_c.c */

Then you define BUILDING_LIB_C only when building library C:
  gcc -c -DBUILDING_LIB_C lib_c.c
  gcc -shared -o lib_c.dll lib_c.o
and define USING_LIB_C when using it. The building-using
distinction seems clearer than export-import.

The macro's conditional definition can be elaborated to suit
your needs. If you're going to require decorations, then you
may want an #error case when neither the BUILDING nor the
USING macro is defined: forgetting them is easy, but tracking
down the resulting problem might be hard. And you may want a
#   define EXP_IMP_LIB_C
case for platforms that don't use any decorations, or for msw
builds that rely on gcc's auto-import feature (so that you can
use the same object files for shared and static libraries).

> I will later combine libA.dll, libB.dll and libC.dll into libABC.dll,  
> which will be used by other applications.  When these other  
> applications are compiled, I will need to use __declspec(dllimport)  
> in the headers for A, B and C?

Yes, the principle is the same:
  __declspec(dllexport) for building libABC
  __declspec(dllimport) for using libABC

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Rich Collins
Actually, the only thing that I found to work was to export the  
symbols from A.h when building A.o, export the symbols from B.h when  
building B.o, but don't import from A.h, since they will all be in  
the same dll.

My macro now looks like this:

#if defined(EXPORT_API)
#define A_API __declspec(dllexport)
#elif defined(IMPORT_API)
#define A_API __declspec(dllimport)
#else
#define A_API
#endif

When I compile A.o I set the EXPORT_API macro
When I compile B.o and C.o, I don't define a macro
When I compile something that uses libABC.dll, I define the  
IMPORT_API macro
When I compile something that uses libABC.a, I don't define a macro

This all seems to work well, but when I try to build a static version  
that links in libABC.a I am getting error messages similar to this:

../_build/lib/libiovmall.a(Collector.o): In function `Collector_check':
/home/Customer/io/libs/garbagecollector/source/Collector.c:60:  
undefined reference to `__assert'

../_build/lib/libiovmall.a(IoSeq.o): In function  
`IoSeq_rawIsNotAlphaNumeric':
/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/
include/ctype.h:154: undefined reference to `__imp___pctype'
/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/
include/ctype.h:154: undefined reference to `__isctype'

../_build/lib/libiovmall.a(IoSystem.o): In function  
`IoObject_errnoDescription':
/home/Customer/io/libs/iovm/source/IoSystem.c:134: undefined  
reference to `__errno'





On Nov 17, 2007, at 6:31 AM, Greg Chicares wrote:

> On 2007-11-17 06:22Z, Rich Collins wrote:
>> If I have libraries A, B and C where A and B use functions from C, I
>> should __declspec(dllexport) in C.h when I compile the object files
>> for C, but __declspec(dllimport) when I include C.h for compilation
>> of A and B, right?
>
> Right. Usually macros are used, e.g.:
>
> /* Begin lib_c.h */
> #if defined BUILDING_LIB_C
> #   define EXP_IMP_LIB_C __declspec(dllexport)
> #elif defined USING_LIB_C
> #   define EXP_IMP_LIB_C __declspec(dllimport)
> ...
>
> void EXP_IMP_LIB_C lib_c_function();
> /* End lib_c.h */
>
> /* Begin lib_c.c */
> void lib_c_function()
> {
> ...
> }
> /* End lib_c.c */
>
> Then you define BUILDING_LIB_C only when building library C:
>   gcc -c -DBUILDING_LIB_C lib_c.c
>   gcc -shared -o lib_c.dll lib_c.o
> and define USING_LIB_C when using it. The building-using
> distinction seems clearer than export-import.
>
> The macro's conditional definition can be elaborated to suit
> your needs. If you're going to require decorations, then you
> may want an #error case when neither the BUILDING nor the
> USING macro is defined: forgetting them is easy, but tracking
> down the resulting problem might be hard. And you may want a
> #   define EXP_IMP_LIB_C
> case for platforms that don't use any decorations, or for msw
> builds that rely on gcc's auto-import feature (so that you can
> use the same object files for shared and static libraries).
>
>> I will later combine libA.dll, libB.dll and libC.dll into libABC.dll,
>> which will be used by other applications.  When these other
>> applications are compiled, I will need to use __declspec(dllimport)
>> in the headers for A, B and C?
>
> Yes, the principle is the same:
>   __declspec(dllexport) for building libABC
>   __declspec(dllimport) for using libABC
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Tor Lillqvist
Of course, none of this ugly dllimport/dllexport markup is really
necessary for functions if you use the gcc and the GNU linker which
automatically exports all global symbols if you don't provide any
exported symbols otherwise (through a .def file and/or dllexport
directives), and if you accept the insignificant (?) space and time
penalty from having function calls going through the import stubs.

For variables you must always use dllimport (and probably should use
dllexport, too, for consistency). That is why, if you have the choice,
having variables in the API of a library built as a DLL is not a good
idea.

Whether header files of libraries ported to Windows should be
"decorated" (uglified some would say) with dllexport and dllimport
attributes (and with calling convention attributes) or not is mostly a
matter of opinion and taste and divides developers. Personally I have
never gone that route for the stuff I have ported to Windows (the GTK+
stack, parts of the GNOME stack). Other cross-platform libraries do
use them.

--tml

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Rich Collins
It is still necessary because if you don't, you get different  
addresses for functions exported by the library when you reference  
the function from the library and from the module that the library is  
linked to.  This is a problem when you try to compare function pointers.

I solved the issue with errors like:
/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/
include/ctype.h:154: undefined reference to `__imp___pctype'

Turns out I forgot to add -mno-cygwin to the command in question.

On Nov 17, 2007, at 5:40 PM, Tor Lillqvist wrote:

> Of course, none of this ugly dllimport/dllexport markup is really
> necessary for functions if you use the gcc and the GNU linker which
> automatically exports all global symbols if you don't provide any
> exported symbols otherwise (through a .def file and/or dllexport
> directives), and if you accept the insignificant (?) space and time
> penalty from having function calls going through the import stubs.
>
> For variables you must always use dllimport (and probably should use
> dllexport, too, for consistency). That is why, if you have the choice,
> having variables in the API of a library built as a DLL is not a good
> idea.
>
> Whether header files of libraries ported to Windows should be
> "decorated" (uglified some would say) with dllexport and dllimport
> attributes (and with calling convention attributes) or not is mostly a
> matter of opinion and taste and divides developers. Personally I have
> never gone that route for the stuff I have ported to Windows (the GTK+
> stack, parts of the GNOME stack). Other cross-platform libraries do
> use them.
>
> --tml
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Tor Lillqvist
> This is a problem when you try to compare function pointers.

True, but that is not something code in general does very often? But
OK, if you have code that does this a lot, and/or want to guard
against that happening you do have to use dllimport decorations.
Personally I would just try to be careful and look out for that
gotcha, and when necesssary use GetProcAddress() (or a suitable
portability wrapper of it) to get the real address of imported
functions instead of using the symbol directly.

--tml

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Brian Dessent
Tor Lillqvist wrote:

> > This is a problem when you try to compare function pointers.
>
> True, but that is not something code in general does very often? But
> OK, if you have code that does this a lot, and/or want to guard

This was the very thing that started this whole thread.

Brian

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Rich Collins
In reply to this post by Tor Lillqvist
This is a port of http://iolanguage.com/about/ to Windows / MinGW.  
You can create C extensions that are loaded at runtime.  Certain  
"type checks" use the address of the function that creates a new  
object to determine type.  If you run one of these type checks from  
the extension, it will compare a function whose address was found  
doing something like: the_objects_struct->clone_function ==  
IoSeq_cloneFunction.

I'm not sure how many changes would have to take place to use  
GetProcAddress.  If it is only the one location, perhaps I can use  
that approach.

On Nov 17, 2007, at 5:55 PM, Tor Lillqvist wrote:

>> This is a problem when you try to compare function pointers.
>
> True, but that is not something code in general does very often? But
> OK, if you have code that does this a lot, and/or want to guard
> against that happening you do have to use dllimport decorations.
> Personally I would just try to be careful and look out for that
> gotcha, and when necesssary use GetProcAddress() (or a suitable
> portability wrapper of it) to get the real address of imported
> functions instead of using the symbol directly.
>
> --tml
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Rich Collins
In reply to this post by Brian Dessent
Almost everything is working.  Now I am running into an issue where I  
get an undefined reference to error where the symbol is an inline  
function that is included from a the header file of another library  
(that is linked in as a dll).

Since the function is inline, I don't see why I should have to  
__declspec(dllimport) it.

On Nov 17, 2007, at 5:59 PM, Brian Dessent wrote:

> Tor Lillqvist wrote:
>
>>> This is a problem when you try to compare function pointers.
>>
>> True, but that is not something code in general does very often? But
>> OK, if you have code that does this a lot, and/or want to guard
>
> This was the very thing that started this whole thread.
>
> Brian
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

John Brown



On Sat, 17 Nov 2007 19:57:59 -0800, Rich Collins wrote:
>
> Almost everything is working. Now I am running into an issue where I
> get an undefined reference to error where the symbol is an inline
> function that is included from a the header file of another library
> (that is linked in as a dll).
>
> Since the function is inline, I don't see why I should have to
> __declspec(dllimport) it.
>

Do you __declspec(export) the function in the DLL? I'm just guessing, but
logically, I would say that if do, then you force it to be *not* inline, but an
actual function with a name and address.
_________________________________________________________________
You keep typing, we keep giving. Download Messenger and join the i’m Initiative now.
http://im.live.com/messenger/im/home/?source=TAGLM
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Rich Collins
No, I don't.  The function proto from the included header file:

extern inline void IoObject_shouldMark(IoObject *self)
{
        Collector_shouldMark_(IOCOLLECTOR, self);
}

On Nov 18, 2007, at 5:00 AM, John Brown wrote:

>
>
>
> On Sat, 17 Nov 2007 19:57:59 -0800, Rich Collins wrote:
>>
>> Almost everything is working. Now I am running into an issue where I
>> get an undefined reference to error where the symbol is an inline
>> function that is included from a the header file of another library
>> (that is linked in as a dll).
>>
>> Since the function is inline, I don't see why I should have to
>> __declspec(dllimport) it.
>>
>
> Do you __declspec(export) the function in the DLL? I'm just  
> guessing, but
> logically, I would say that if do, then you force it to be *not*  
> inline, but an
> actual function with a name and address.
> _________________________________________________________________
> You keep typing, we keep giving. Download Messenger and join the  
> i’m Initiative now.
> http://im.live.com/messenger/im/home/?source=TAGLM
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Keith Marshall-3
On Sun, 2007-11-18 at 13:11 -0800, Rich Collins wrote:
> No, I don't.

You don't what?  Please do not top post.

> The function proto from the included header file:
>
> extern inline void IoObject_shouldMark(IoObject *self)
> {
>         Collector_shouldMark_(IOCOLLECTOR, self);
> }

Declaring a function `inline' does not, AIUI, force the compiler to
inline it -- it is merely a hint that it may be considered for inlining,
depending on the optimisation level being employed.  When you declare
`extern inline', as you do here, you must also provide an external
implementation, to satisfy linking of any module in which the compiler
chooses *not* to inline the code.

If you want to avoid exposing that public symbol, then you could declare
`static inline', rather than `extern inline'.

Regards,
Keith.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Rich Collins
>> No, I don't.
>
> You don't what?  Please do not top post.

Sorry,  He asked if I declare the function as __declspec(dllexport)

> When you declare
> `extern inline', as you do here, you must also provide an external
> implementation, to satisfy linking of any module in which the compiler
> chooses *not* to inline the code.

Why does it work in the unix gcc compilers?

Could it be that I declare other functions in the dll to be exported,  
so it doesn't export the implementation? (if that makes sense)

On Nov 18, 2007, at 1:21 PM, Keith Marshall wrote:

> On Sun, 2007-11-18 at 13:11 -0800, Rich Collins wrote:
>> No, I don't.
>
> You don't what?  Please do not top post.
>
>> The function proto from the included header file:
>>
>> extern inline void IoObject_shouldMark(IoObject *self)
>> {
>>         Collector_shouldMark_(IOCOLLECTOR, self);
>> }
>
> Declaring a function `inline' does not, AIUI, force the compiler to
> inline it -- it is merely a hint that it may be considered for  
> inlining,
> depending on the optimisation level being employed.  When you declare
> `extern inline', as you do here, you must also provide an external
> implementation, to satisfy linking of any module in which the compiler
> chooses *not* to inline the code.
>
> If you want to avoid exposing that public symbol, then you could  
> declare
> `static inline', rather than `extern inline'.
>
> Regards,
> Keith.
>
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

James Steward-2
On Sun, 2007-11-18 at 13:30 -0800, Rich Collins wrote:
> On Nov 18, 2007, at 1:21 PM, Keith Marshall wrote:
> > When you declare
> > `extern inline', as you do here, you must also provide an external
> > implementation, to satisfy linking of any module in which the compiler
> > chooses *not* to inline the code.
>
> Why does it work in the unix gcc compilers?

Maybe there (on a *nix system), the compiler does choose to inline the
code.  You could test the hypothesis by disassembling the resultant, and
see if the code for the function is inlined, or if there is a function
call to it.

Regards,
James.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Rich Collins
OK I figured out exactly what happens.

There is a macro in the header file where the function is declared.  
When the function is included into "its" C file, it is declared  
inline. When the function is included into other C files, it is  
declared extern inline.  I am including the header in a C file that  
will be compiled into a dll that does not include the object code  
where the function was declared inline.  It would seem that I need to  
declare the function __declspec(dllexport) inline when the header is  
included into "its" C file, and declare it __declspec(dllimport)  
extern inline when I include the header file into the C file that  
will be linked to the other dll.

:S

On Nov 18, 2007, at 2:17 PM, James Steward wrote:

> On Sun, 2007-11-18 at 13:30 -0800, Rich Collins wrote:
>> On Nov 18, 2007, at 1:21 PM, Keith Marshall wrote:
>>> When you declare
>>> `extern inline', as you do here, you must also provide an external
>>> implementation, to satisfy linking of any module in which the  
>>> compiler
>>> chooses *not* to inline the code.
>>
>> Why does it work in the unix gcc compilers?
>
> Maybe there (on a *nix system), the compiler does choose to inline the
> code.  You could test the hypothesis by disassembling the  
> resultant, and
> see if the code for the function is inlined, or if there is a function
> call to it.
>
> Regards,
> James.
>
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: More fun w/ dllexport and dllimport

Rich Collins
In reply to this post by James Steward-2
The solution was:

__declspec(dllexport) inline when the header is included in the C  
file it "belongs to"
extern inline when the header is included into a C file within the  
same dll as the object produced by the C file it "belongs to"
__declspec(dllimport) extern inline when the header is included into  
a C file within the a different dll from the object produced by the C  
file it "belongs to"

On Nov 18, 2007, at 2:17 PM, James Steward wrote:

> On Sun, 2007-11-18 at 13:30 -0800, Rich Collins wrote:
>> On Nov 18, 2007, at 1:21 PM, Keith Marshall wrote:
>>> When you declare
>>> `extern inline', as you do here, you must also provide an external
>>> implementation, to satisfy linking of any module in which the  
>>> compiler
>>> chooses *not* to inline the code.
>>
>> Why does it work in the unix gcc compilers?
>
> Maybe there (on a *nix system), the compiler does choose to inline the
> code.  You could test the hypothesis by disassembling the  
> resultant, and
> see if the code for the function is inlined, or if there is a function
> call to it.
>
> Regards,
> James.
>
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Loading...