headers
K. Frank | 26 Oct 2011 02:41
Picon

Revisiting spurious (?) "redeclared without dllimport attribute ..." warning -- how to fix?

Hello List!

I am getting the following warning (many times over):

   qwt_interval.h:270:13: warning: 'bool QwtInterval::isValid() const'
redeclared without dllimport attribute after being referenced with dll
linkage [enabled by default]

It's getting to be a minor problem, in that "real" warnings can get
lost in the noise.

I believe that this is a known issue, maybe first occurring in qwt 6.0.0.
See, for example Uwe's reply to Shane's question about this:

   http://sourceforge.net/mailarchive/message.php?msg_id=26384458

Anyway, I am still seeing this in qwt 6.0.1 (with qt 4.8.0 and mingw-w64
g++ 4.7.0).

Does anybody understand what is causing this, and more practically, how
to make it go away?

(I have seen several references to this issue, both with qwt and
independently of qwt, but I haven't found one yet with a fix.)

Thanks for any help.

K. Frank

------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply |
headers
David Stranz | 26 Oct 2011 04:11

Re: Revisiting spurious (?) "redeclared without dllimport attribute ..." warning -- how to fix?

You probably have not defined QWT_DLL as compiler and/or linker option.

David

_______________________________________________________________
David Stranz, Ph.D.	david_stranz <at> MassSpec.com

Sierra Analytics, Inc.
5815 Stoddard Road, Suite 601
Modesto, CA  95356

Tel: (209) 545-8508
http://www.massspec.com
_______________________________________________________________

On 10/25/2011 5:41 PM, K. Frank wrote:
> Hello List!
>
> I am getting the following warning (many times over):
>
>     qwt_interval.h:270:13: warning: 'bool QwtInterval::isValid() const'
> redeclared without dllimport attribute after being referenced with dll
> linkage [enabled by default]
>
> It's getting to be a minor problem, in that "real" warnings can get
> lost in the noise.
>
> I believe that this is a known issue, maybe first occurring in qwt 6.0.0.
> See, for example Uwe's reply to Shane's question about this:
>
(Continue reading)

Permalink | Reply |
headers
K. Frank | 26 Oct 2011 16:22
Picon

Re: Revisiting spurious (?) "redeclared without dllimport attribute ..." warning -- how to fix?

David -

Thanks for your reply.

On Tue, Oct 25, 2011 at 10:11 PM, David Stranz
<David_Stranz <at> massspec.com> wrote:
> You probably have not defined QWT_DLL as compiler and/or linker option.

It looks like I do have QWT_DLL defined as a compiler option.  My
qmake / mingw32-make generated compile commands contain

   -DQWT_DLL

I didn't put this in by hand, but it looks like the qwtcoinfiig.pri and qwt.prf
files are configured to use set QWT_DLL by default.

(My link command does not contain QWT_DLL, but I should point out
that the "redeclared without dllimport attribute ..." warning is issued at
compile time and not at link time.)

Any further thoughts would be appreciated.

> David
> David Stranz, Ph.D.     david_stranz <at> MassSpec.com

Best.

K. Frank

> ...
(Continue reading)

Permalink | Reply |
headers
David Stranz | 26 Oct 2011 17:02

Re: Revisiting spurious (?) "redeclared without dllimport attribute ..." warning -- how to fix?

 > (My link command does not contain QWT_DLL, but I should point out
 > that the "redeclared without dllimport attribute ..." warning is
 > issued at compile time and not at link time.)

Ah, the "redeclared" word is a big, waving flag.  It probably means that 
exactly the situation I described in my last post is happening.  The 
same header is being included twice, with opposite DLL specifications.

qwt_global.h is where some of this occurs.  I notice that there is a 
#define QWT_TEMPLATEDLL that is present for DLL building, but not 
defined for DLL use.  I wonder if some use of this in another header 
file is resulting in the conflict?

I don't have Qwt 6 installed here, so can't check.

David
_______________________________________________________________
David Stranz, Ph.D.	david_stranz <at> MassSpec.com

Sierra Analytics, Inc.
5815 Stoddard Road, Suite 601
Modesto, CA  95356

Tel: (209) 545-8508
http://www.massspec.com
_______________________________________________________________

On 10/26/2011 7:22 AM, K. Frank wrote:
> David -
>
(Continue reading)

Permalink | Reply |
headers
K. Frank | 26 Oct 2011 23:56
Picon

Re: Revisiting spurious (?) "redeclared without dllimport attribute ..." warning -- how to fix?

Hello Uwe and David (and Shane, if you're still here...)!

Well, I think I've found a fix/workaround for the dllimport warning.

First, let me issue the disclaimer that I have no idea what is going on
here, or why my fix appears to work.

First, the context:

>>>> I am getting the following warning (many times over):
>>>>    qwt_interval.h:270:13: warning: 'bool QwtInterval::isValid() const'
>>>>    redeclared without dllimport attribute after being referenced with dll
>>>>    linkage [enabled by default]
>>>> ...

The fix appears to be to add back the "inline" keyword to the declaration
of QwtInterval::isValid() inside the declaration of the QwtInterval class.

Specifically, line 90 of qwt_interval.h (the qwt-6.0.1 version) becomes:

    inline bool isValid() const;

(It was "bool isValid() const;" originally, without the "inline".)

After I made this change, I rebuilt qwt just to be safe.  I don't know whether
the rebuild step was necessary or not.  Anyway, now when I build my
applications that use qwt, I no longer get the dllimport warnings.

For those who are curious, Shane's post:
(Continue reading)

Permalink | Reply |
headers
David Stranz | 27 Oct 2011 00:17

Re: Revisiting spurious (?) "redeclared without dllimport attribute ..." warning -- how to fix?

Strange - when I look at the online documentation for qwt_interval.h, 
all of the method implementations -do- have the inline keyword.

http://qwt.sourceforge.net/qwt__interval_8h_source.html

Is there some discrepancy between the online docs and the actual source? 
  Or are you saying that the declarations within the class definition 
also need the inline keyword in order to make g++ happy?

What happens if you add the QWT_EXPORT keyword to the method 
implementations (and remove the inline keyword from the method declaration)?

E.g. (maybe the order of "inline" and "QWT_EXPORT" needs to be swapped)

inline QWT_EXPORT bool QwtInterval::isValid()
{
	// ...
}

Regards,

David
_______________________________________________________________
David Stranz, Ph.D.	david_stranz <at> MassSpec.com

Sierra Analytics, Inc.
5815 Stoddard Road, Suite 601
Modesto, CA  95356

Tel: (209) 545-8508
(Continue reading)

Permalink | Reply |
headers
K. Frank | 27 Oct 2011 02:01
Picon

Re: Revisiting spurious (?) "redeclared without dllimport attribute ..." warning -- how to fix?

Hi David!

On Wed, Oct 26, 2011 at 6:17 PM, David Stranz <David_Stranz <at> massspec.com> wrote:
> Strange - when I look at the online documentation for qwt_interval.h,
> all of the method implementations -do- have the inline keyword.
>
> http://qwt.sourceforge.net/qwt__interval_8h_source.html

Yes, I agree with this.

> Is there some discrepancy between the online docs and the actual source?

No, I don't think so.

>  Or are you saying that the declarations within the class definition
> also need the inline keyword in order to make g++ happy?

Yes, I'm talking about the inline keyword applied to the member-function
declaration inside of the class declaration.  It's that use of inline that was
removed when moving from 5.2.0 to 5.2.1,  inline was, and still is used
for the member-function implementations that are given outside of the
class declaration (but in the same file).

By the way, Marshall Cline comments in his C++-FAQ-lite on the
use of inline for member-function declarations in class declarations:

   http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.9

If I read him correctly, the usage is perfectly legal, but bad style.  Perhaps
that sort of  consideration is what prompted the removal of inline when
(Continue reading)

Permalink | Reply |
headers
David Stranz | 27 Oct 2011 04:34

Re: Revisiting spurious (?) "redeclared without dllimport attribute ..." warning -- how to fix?

On 10/26/2011 5:01 PM, K. Frank wrote:
 > Uwe did comment that isValid() is different in that it is not only
 > inline, but is called by other inline member functions.  Why this
 > would matter, I have no idea, but isValid() was the only problem
 > child (that I know of) with regard to the dllimport issue.

That is probably the reason why the compiler complains, but every reason 
I can think of would be a linker problem instead.

You would think that #ifndef guards on the header files would ensure 
that the same header isn't included twice, but even so if you are 
*compiling* then all inclusions of the same header should be using the 
same export convention.  A function with an inline declaration *should* 
expand to just inline code, but maybe in this case the compiler has 
decided it can't inline the method (or maybe the one that uses 
isValid()), so it creates a non-inline version with the wrong export type.

I don't know; it's very strange.  At least you know of a way to solve it.

Best regards,

David

_______________________________________________________________
David Stranz, Ph.D.	david_stranz <at> MassSpec.com

Sierra Analytics, Inc.
5815 Stoddard Road, Suite 601
Modesto, CA  95356
(Continue reading)

Permalink | Reply |
headers
Uwe Rathmann | 27 Oct 2011 08:26
Picon

Re: Revisiting spurious (?) "redeclared without dllimport attribute ..." warning -- how to fix?

On 10/27/2011 02:01 AM, K. Frank wrote:

> By the way, Marshall Cline comments in his C++-FAQ-lite on the
> use of inline for member-function declarations in class declarations:
>
>     http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.9
>
> If I read him correctly, the usage is perfectly legal, but bad style.  Perhaps
> that sort of  consideration is what prompted the removal of inline when
> moving from 5.2.0 to 5.2.1.

I can't remember the reason in detail, but I'm afraid it was because of 
an issue ( maybe in a warning level ) of another compiler. Otherwise I 
wouldn't have removed the inline in the class declaration.
Concerning "bad style": as I don't have most of the target platforms 
myself I'm trying to follow how Qt code does it - hoping, that this is 
written in a way, that is valid for all platforms.

I will check my archives - may I can identify the reason,

Uwe

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning <at> Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
Permalink | Reply |
headers
Uwe Rathmann | 26 Oct 2011 16:22
Picon

Re: Revisiting spurious (?) "redeclared without dllimport attribute ..." warning -- how to fix?

On 10/26/2011 02:41 AM, K. Frank wrote:
> Does anybody understand what is causing this, ...

No - this has been reported several times but nobody ever knew a 
workaraound. In the end it should be a compiler bug.

> ... and more practically, how to make it go away?

Guess you could move the code to the cpp file. You might lose inlining, 
what should be no problem as long as it is not used in important loops.

Uwe

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning <at> Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
Permalink | Reply |
headers
David Stranz | 26 Oct 2011 16:42

Re: Revisiting spurious (?) "redeclared without dllimport attribute ..." warning -- how to fix?

Uwe, Frank,

In my experience, warnings such as this are due to some mismatch between 
the export / import declarations for header files used in a DLL, and can 
be traced down to one or more more header files being #included in two 
different compilation units with conflicting declarations.

In other words, in one place the file is included with dllimport, and 
another with dllexport.  This could happen with nested header files - if 
a header file inside the DLL uses dllimport, but another file in the 
application uses it with dllexport, then there is a mismatch.  Usually 
#ifdef guards in header files prevent this, but maybe something else is 
going on here.

Regards,

David

_______________________________________________________________
David Stranz, Ph.D.	david_stranz <at> MassSpec.com

Sierra Analytics, Inc.
5815 Stoddard Road, Suite 601
Modesto, CA  95356

Tel: (209) 545-8508
http://www.massspec.com
_______________________________________________________________

On 10/26/2011 7:22 AM, Uwe Rathmann wrote:
(Continue reading)

Permalink | Reply |

Gmane