Re: [RFC] w32 and Libtool.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Wed, Oct 13, 2010 at 11:53:55PM CEST:
> Den 2010-10-13 20:50 skrev Ralf Wildenhues:
> > Two spaces after period.
> 
> I consider that part of texification.

Sure.

> >> int one (void)
> >> {
> >>   return 1;
> >> }
> >>
> >> int two (void)
> >> {
> >>   return 2;
> >> }
> >>
> >> int three = 3;
> > 
> > Isn't this less-than fully general, in the sense that having in addition
> > references to one and three from within two would possibly be more
> > complex to handle?
> 
> I don't remember ever having problems with that, but I suppose two () could
> be written as { return three - one (); } if that makes you sleep better.

I don't care much, but that's the difference that exposes missing -fPIC
on GNU/Linux (non-x86) systems.  Suppose that bit is irrelevant for
COFF.

> >> an explicit __declspec(dllexport) is seen. The GNU tools is doing this
> >> to not make more symbols visible for projects that have already taken
> >> the trouble to decorate all symbols. There is no similar way to limit
> > 
> > s/all// ?  (because how can you know that it did do so for all symbols,
> > when parts of the project may come from third parties?)
> 
> You have to decorate all symbols you wish to export, because if you miss
> some, auto-export will have been disabled by the symbols that was indeed
> decorated.

Right.  But to me, the sentence can be read to imply that, when the user
has forgotten to decorate some symbols, then GNU tools will somehow
still magically do TRT.

Maybe an example is in order here, to explain why I stumbled over this:
you include third-party code in your project (e.g., helper functions
like those from gnulib), and that code is decorated (unlike gnulib)
but your own code is not.  Boom, that's trouble, but not in the way
you intended.

> I'll still remove "all" though, because you really only need
> to decorate the symbols that you wish to export, and that is typically
> not *all* symbols.

OK.  That also avoids my (arguably weird) misreading.

> >> No matching help with auto-import is provided by Libtool for neither
> >> proprietary tools nor older GNU tools, so symbols *must* be decorated in
> >> order to import them from a DLL for everything but contemporary GNU
> >> tools on Windows.
> > 
> > But can we not assume that older GNU tools are irrelevant?  What would
> > keep people from updating them?
> 
> I don't know. I felt that a bit of history wouldn't hurt here. Maybe I'm
> just muddying the waters?

Oh, mentioning older GNU tools seems like a good idea to me; but I also
think that you can regard them as irrelevant for current libtool
operation.

> >> With
> >> Microsoft tools you typically get away with always compiling the code as
> >> if it is going to be linked with a DLL. There are cases when this does
> >> not work, such as when only variables and no functions are imported from
> >> the library. There is also a price connected to this liberal use of
> >> imports in that an extra indirection is introduced when you are
> >> consuming the static version of the library. That extra indirection is
> >> always present when the DLL is consumed, but it is not needed when
> >> consuming the static library.
> > 
> > This paragraph is fairly vague.  I understand if you don't want to tell
> > all the gory details about this, but in that case maybe a pointer to
> > more detailed documentation would be good here.
> 
> I don't know where this is spelled out, and it is intentionally vague as
> I don't know all the answers.

OK.  Maybe somebody else can fill this in, or we leave it like this for
now.

> >> For older GNU tools and other proprietary tools there is no generic way
> >> to make it possible to consume either of the DLL or the static library
> >> without user intervention, the tools needs to be told what is intended.
> >> Or, to be exact, the author are not aware of any generic way. One
> > 
> > s/are/is/  This sounds a bit awkward still.
> 
> Don't know what to do about that.

Well, how about let's remove the sentence starting with "Or"?

> Here's an update:

Looks good to me, given comments above.

Thanks,
Ralf