libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DLL_EXPORT and MinGW/Cygwin


From: Robert Collins
Subject: Re: DLL_EXPORT and MinGW/Cygwin
Date: Thu, 27 Dec 2001 12:03:51 +1100

----- Original Message -----
From: "Jon Leichter" <address@hidden>
> > You may be interested in looking into the auto-import capability
that is
> > hopefully going into libtool 1.5.
>
> Should I be able to see this in the HEAD branch of CVS? I did a quick
check
> for "auto-import" and didn't find anything significant. Am I missing
> something?

It's not in CVS yet. About 6+ months ago I post this :
http://cygwin.com/ml/cygwin-apps/2001-06/msg00007.html. Since then Chuck
Wilson has been instrumental in sheparding through the autoimport
capability to binutils. Gary Vaughn showed a lot of interest, but a lack
of time in the hacking I was doing... I tried two approaches: One via
defines for libraries, and one via auto import...
http://mail.gnu.org/pipermail/libtool/2001-June/thread.html contains a
bunch of dialog about libtool. I found (and corrected) the odd bug in
both libtool and automake at this time... it was suffering bitrot :}.

> > Also, with some automake perl magic the appropriate defines for
> > libraries can be added automagically to the compile line - I chose
> > *library*_DLL_IMPORT and *library*_DLL_EXPORT to allow correct
behaviour
> > with multiple libraries, including static and dynamic libraries.
>
> Are you saying that in addition to libtool, you ALSO use automake to
> accomplish this in your own projects? In other words, you are talking
about
> your own projects and not an extension/change to libtool, correct?

This was an orthogonal solution to the auto-import capability. I am
talking about a patch to automake
http://sources.redhat.com/ml/automake/2001-06/msg00026.html which is
actually a little different from what I recalled :}. The patch alters
the way automake calls libtool to compile the source files, so that a
compile to generate an object for a dll called foo gets
-DLIBfoo_COMPILATION -DDLL_EXPORT and (manually added but could be
changed as well) -DLIBbar_DLL_IMPORT -DLIBmu_DLL_IMPORT,
and a compile to generate the same object for the static library version
gets
-DLIBfoo_COMPILATION -DLIBbar_DLL_IMPORT -DLIBmu_DLL_IMPORT
which obviously allows any combination you desire. (See the email for
the details).

> Can you elaborate more on the process that you used to distinguish
between
> static and dynamic libraries?

Note that this automake approach is not in production anywhere - I put
it to the side when my tests on autoimport where so ELF-like and
effective. Unfortunately, complex variable exports from .dll's can't be
successfully imported without a .def or __declspec declaration (see
http://cygwin.com/ml/cygwin-announce/2001/msg00123.html which includes a
quick summary of the problem, I don't have a reference to the detail
handy (Chuck?).) So a more long term solution is needed... (*)

> When you build a project with an external
> library (in Windows), you need to know where that library lives,

You do for any platform. With cygwin the default locations are /usr/lib
and /usr/local/lib for static libraries and import libraries, with the
.dlls in ...bin.

> which type
> of library is available (i.e. static, dynamic, or both)

Libtool knows via the .la file in the same location as the import and
static versions of the library. For non libtool libraries the programmer
knows, and can create a dummy .la file with the approriate information.

> , and which type you
> will necessarily link with.

libtool will prefer shared libraries and fall back to static
unless -static or -shared are supplied, in which case it will only
choose that type, and fail if it's not present.

> Without this information, it's not possible to
> automagically set the appropriate defines.

Agreed.

(*) Long term solutions.
There are key criteria in my mind for a long term solution.
1) It must be programmer error free. Programmers should not need
__declspec(I have a broken linker) to write effective and fast code.
2) It must handle arbitrary types.
3) It must interoperate with existing libraries.

Today we have 1 (mostly) and 3, but not 2.

The automake hackup solution will work, but it's still going to uglify
code.

The crux of the problem is that gcc must know what symbols will become
dll imports at compile time (when it's traditionally unaware of link
time issues).

Possible solutions are:
a) A profile/feedback driven solution.
b) A programmer driven solution.
c) A push-the-PE-spec-boundary solution.

I'm not aware of any fundamentally different approaches.
b) doesn't fulfil my criterion 1). c) doesn't fulfil my criterion 2).
Let me describe a).

When compiling a translation unit gcc can read in profile information to
make optimisation choices. That information could be extended (or placed
in a new profile-like file) to contain information about symbols that
will be resolved via a link to a .dll, or to a .a, or within a single
.exe etc.

Then the make process would be as follows:
1 translate all source files
2 attempt to link, generating link-profile information at the same time.
Only update the disk files for this if it changes. (This will also allow
us to warn when an extern variable is never used, which currently
(AFAIK) cannot be done).
3 IFF the link fail due to an incorrect variable import format,
retranslate all the source files with newer link profile information
(1st time round this could be a killer :})
4 goto 2.

This could loop forever, if the link can fail on an incorrect import
format twice, but I don't see how that would happen as step 2 generates
the correct metadata about the symbols to allow linking to proceed.

This approach will meet criterion 1,2 and 3, at the cost of extra link
iterations.

I don't have the time myself to invest in doing this right now, but IMO
it's a better approach than the current auto-import one - which is
itself being pretty d**n useful :}.

Rob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]