Ralf Wildenhues wrote:
> > > There is dangerous ambiguity. In the past this kind of ambiguity
> > > cause most of the dllimport-related ICE's in GCC.
> >
> > I assume that GCC has enough maintainers to fix ICEs inside GCC.
>
> But it's not Libtool's job to push GCC, Libtool tries to encode what
* Bruno Haible wrote on Wed, Sep 06, 2006 at 06:37:08PM CEST:
> Danny Smith wrote:
>
> > There is dangerous ambiguity. In the past this kind of ambiguity
> > cause most of the dllimport-related ICE's in GCC.
>
> I assume that GCC has enough maintainers to fix ICEs inside GCC.
But it's not Libto
>
> I propose to make 'dllexport' unnecessary, and to make it
> possible to use 'dllimport' everywhere where the users were
> used to write either 'dllimport' or 'dllexport', depending on
> the compilation pass and unit.
I think what bothers me most is that this will encourage people to use
Danny Smith wrote:
> Thinking more about this, the whole problem goes away with
> -funit-at-a-time and that is turned on by default at
> optimization level of 1 or higher.
Not the whole problem, only the case of a reference in the same compilation
unit as the definition of the variable.
> It see
> gcc reports warnings:
>
> warning: 'externvar' defined locally after being referenced
> with dllimport linkage
> warning: 'externfunc' defined locally after being referenced
> with dllimport linkage
>
> Once libtool is changed to not cause link errors for
> self-references, there is no need
Hello Ralf,
> | Woe32 problem 1: Exports
> [...]
> | Methods 2b and 2c don't work for C++, because of the name mangling.
>
> Well, that assumes that you create an export list (or the asm
> statements) manually.
Yes, that's what I meant by "a selected set of symbols".
> That does not have to be
Danny Smith wrote:
>
> ...
> there is no need any more for this warning. gcc should remove this
> warning.
>
>
> Are you sure about that.
>
> The reason that gcc emits these warnings is this:
> gcc -S dllimp.c
>
> .file "dllimp.c"
> .text
> .globl _externfunc2
> .def_ex
Hello Bruno, all,
First of all, let me thank you for all your work on this! And apologies
in advance for a slightly unsorted list of thoughts in reply.
* Bruno Haible wrote on Mon, Sep 04, 2006 at 01:48:55PM CEST:
>
> There are 4 ways to deal with the problem of exported variables when
> buildi
> You find complete details about this approach in
> http://www.haible.de/bruno/woe32dll.html
>
extern __declspec(dllimport) int externvar[5];
extern __declspec(dllimport) int externfunc(int);
int externfunc2 (int x)
{
return externvar[x] + externfunc (0);
}
int externvar[5] = { 11, 22, 3
