llvm dev - Dec 2011 - [LLVMdev] LLVM 3.0 - Windows - auto-importing issue with llvm::CallInst

Hi,

 

I have just upgraded to LLVM 3.0 (nice job btw!) which I have built as a
shared library on Windows using MinGW, and then use from within my Qt-based
application. Upon execution, everything works perfectly (incl. the call to
llvm::InitializeNativeTarget(); which used to cause problems upon exiting my
application; see
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-November/045597.html; in
other words, there is something wrong in LLVM 2.9, but that somehow got
fixed in LLVM 3.0).

 

However, there is one new (minor) issue which is that when building my
application I get a warning from the linker about auto-importing having been
activated without -enable-auto-import being specified on the command line.
Indeed, for some reason, the vtable for llvm::CallInst has to be resolved.?!
This is clearly not critical since I can get rid of the warning by adding
-enable-auto-import on the command line, but I wish I didn't have to do that
(it's not clean in my view).

 

So. how come I am getting that warning and how could I get rid of it without
having to rely on the -enable-auto-import argument?

 

Cheers, Alan.

 

PS: everything works is fine on Linux x86/x64 and Mac OS X. Brilliant! J

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111202/9bcefff6/attachment.html>

On 12/2/2011 9:09 AM, Alan Garny wrote:
>
> However, there is one new (minor) issue which is that when building my 
> application I get a warning from the linker about auto-importing 
> having been activated without --enable-auto-import being specified on 
> the command line. Indeed, for some reason, the vtable for 
> llvm::CallInst has to be resolved...?! This is clearly not critical 
> since I can get rid of the warning by adding --enable-auto-import on 
> the command line, but I wish I didn't have to do that (it's not
clean
> in my view).
>
Mostly harmless... for shared libs on Windows you'd normally have to 
either:
use __declspec(dllexport) on exported functions, and __declspec(dllimport)
on the prototypes for code that uses them; or:
list symbols to be exported in a .def file when building the dll, and
link with that .def file when building code that uses it.

GCC on mingw came up with the "auto-import" option to avoid those
nuisances by, automatically exporting everything, if otherwise there'd
be no exports and you're building a shared-lib.  When it does this
without being told to, it emits that warning message, so you know
it happened.

I think that that warning went away in later versions -- this seems
to be the most-appropriate behavior and apparently doesn't
cause problems, so for GCC, auto-import and no special markings
on your code is what you should usually do.

But I'm not an expert -- just trying to follow along.  There are
potential issues with relocations and thunks and position-independent
code and intermittent failures when DLL relocations "collide"...
but I really don't want to have to worry about that.


Kevin

(a couple interesting links ab't enable-auto-import):

[1] http://sourceware.org/binutils/docs-2.16/ld/WIN32.html
[2] http://www.delorie.com/gnu/docs/binutils/ld_4.html


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111203/ed514f3e/attachment.html>

Hi Kevin,

 

Yes, I am aware of all of this (i.e. the way shared libraries work on
Windows and of the auto-importing feature in MinGW gcc). However, I can't
explain to myself why I got that message for llvm::CallInst and no other
LLVM function.?! Also, I would rather MinGW gcc work the way it ought to on
Windows, rather than find a way around the problem, no matter how convenient
it may be.

 

Alan

 

From: Kevin Kelley [mailto:kevin at kelleysoft.com] 
Sent: 03 December 2011 13:52
To: Alan Garny
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] LLVM 3.0 - Windows - auto-importing issue with
llvm::CallInst

 


On 12/2/2011 9:09 AM, Alan Garny wrote: 

However, there is one new (minor) issue which is that when building my
application I get a warning from the linker about auto-importing having been
activated without -enable-auto-import being specified on the command line.
Indeed, for some reason, the vtable for llvm::CallInst has to be resolved.?!
This is clearly not critical since I can get rid of the warning by adding
-enable-auto-import on the command line, but I wish I didn't have to do that
(it's not clean in my view).

 

Mostly harmless... for shared libs on Windows you'd normally have to either:

use __declspec(dllexport) on exported functions, and __declspec(dllimport)
on the prototypes for code that uses them; or:
list symbols to be exported in a .def file when building the dll, and
link with that .def file when building code that uses it.

GCC on mingw came up with the "auto-import" option to avoid those
nuisances by, automatically exporting everything, if otherwise there'd
be no exports and you're building a shared-lib.  When it does this
without being told to, it emits that warning message, so you know
it happened.

I think that that warning went away in later versions -- this seems
to be the most-appropriate behavior and apparently doesn't
cause problems, so for GCC, auto-import and no special markings
on your code is what you should usually do.

But I'm not an expert -- just trying to follow along.  There are
potential issues with relocations and thunks and position-independent
code and intermittent failures when DLL relocations "collide"...
but I really don't want to have to worry about that.  


Kevin

(a couple interesting links ab't enable-auto-import):

[1] http://sourceware.org/binutils/docs-2.16/ld/WIN32.html
[2] http://www.delorie.com/gnu/docs/binutils/ld_4.html





-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111204/0435503c/attachment.html>