RE: dlltool not creating a proper import library

RE: dlltool not creating a proper import library

[Andrew Begel]

> -----Original Message-----
> From: DJ Delorie [ mailto:dj@delorie.com ]
> Sent: Monday, June 04, 2001 4:39 PM
> 
> It sounds to me like you're not using the official versions
> of the sources, because:
> 
> 1. gcc doesn't have "nm_" anywhere in it's backend sources.
> 2. Nothing in the linker does either.
> 3. I can't find the string "auto-import" in the sources anywhere.

I'm using gcc-2.95.2-3 from the mingw distribution, and binutils and ld
from the same sourceforge projects (I'm using the distributions; I
didn't build anything from sources). 

Here's a sample of an actual run. The symbols Qnil, Qt, and the rest are
DATA symbols that I'm exporting from XEmacs 21.4.3 source code. Inside
my libxemacs.a is a libxemacs-import.a which is my import library
created from a .def file that lists Qt, Qnil and the rest as DATA
symbols. a2dll is a tool written by Paul Sokolovsky (sp?) that runs gcc
--shared --export-all and wraps -Wl,--whole-archive and
-Wl,--no-whole-archive around the libxemacs.a file:



(CC=g++ a2dll OBJ.i686-pc-mingw32/libxemacs.a -o
OBJ.i686-pc-mingw32/harmonia_xe
macs.dll     -Wl,-export-dynamic -Wl,--wrap,__builtin_new
-Wl,--wrap,__builtin_d
elete -Wl,--wrap,__builtin_vec_new -Wl,--wrap,__builtin_vec_delete
-L../../lk/O
BJ.i686-pc-mingw32 -llk.dll -L../../common/OBJ.i686-pc-mingw32
-lcommon.dll   -L
/usr/misc/lib -Lc:\mingw\lib -lgcimp  --relink; mv
libharmonia_xemacs.dll.a OBJ.
i686-pc-mingw32)
Creating shared library 'OBJ.i686-pc-mingw32/harmonia_xemacs.dll'
Warning: resolving _Qnil by linking to __imp__Qnil (auto-import)
Warning: resolving _print_readably by linking to __imp__print_readably
(auto-imp
ort)
Warning: resolving _Qt by linking to __imp__Qt (auto-import)
Warning: resolving _gcprolist by linking to __imp__gcprolist
(auto-import)
Warning: resolving _lrecord_type_count by linking to
__imp__lrecord_type_count (
auto-import)
Warning: resolving _lrecord_implementations_table by linking to
__imp__lrecord_i
mplementations_table (auto-import)
Warning: resolving _lrecord_markers by linking to __imp__lrecord_markers
(auto-i
mport)
Warning: resolving _Qstringp by linking to __imp__Qstringp (auto-import)
Creating library file: libxemacs.dll.a
fu000001.o(.idata$3+0xc): undefined reference to
`OBJ_i686_pc_mingw32_libxemacs_
import_a_iname'
fu000002.o(.idata$3+0xc): undefined reference to
`OBJ_i686_pc_mingw32_libxemacs_
import_a_iname'
fu000003.o(.idata$3+0xc): undefined reference to
`OBJ_i686_pc_mingw32_libxemacs_
import_a_iname'
fu000004.o(.idata$3+0xc): undefined reference to
`OBJ_i686_pc_mingw32_libxemacs_
import_a_iname'
fu000005.o(.idata$3+0xc): undefined reference to
`OBJ_i686_pc_mingw32_libxemacs_
import_a_iname'
fu000006.o(.idata$3+0xc): more undefined references to
`OBJ_i686_pc_mingw32_libx
emacs_import_a_iname' follow
nmth000000.o(.idata$4+0x0): undefined reference to `_nm__Qnil'
nmth000330.o(.idata$4+0x0): undefined reference to `_nm__print_readably'
nmth000338.o(.idata$4+0x0): undefined reference to `_nm__Qt'
nmth000373.o(.idata$4+0x0): undefined refemake: *** Deleting file
`OBJ.i686-pc-m
ingw32/harmonia_xemacs.dll'

> So, unless you can reproduce this with the official tools, nobody here
> is going to be able to help you much.  Have you tried reporting this
> to the mingw list?

Yes, a few days ago. Haven't got a response.

> 
> > However, when I use dlltool to make an import library from 
> a .def file,
> > I only get two  symbols for each exported symbol: _bar and 
> __imp_bar.
> 
> This is normal.  For data symbols, you only get the _imp_ one.  And,
> you'd get _imp__bar, not __imp_bar (the latter is obsolete).

Using dlltool from the mingw binutils distribution (2.10.91 1/14/01), I
get __imp__bar and _bar in my import library. 

:(

Andrew

Re: dlltool not creating a proper import library

[DJ Delorie]

It sounds to me like you're not using the official versions
of the sources, because:

1. gcc doesn't have "nm_" anywhere in it's backend sources.
2. Nothing in the linker does either.
3. I can't find the string "auto-import" in the sources anywhere.

So, unless you can reproduce this with the official tools, nobody here
is going to be able to help you much.  Have you tried reporting this
to the mingw list?

> However, when I use dlltool to make an import library from a .def file,
> I only get two  symbols for each exported symbol: _bar and __imp_bar.

This is normal.  For data symbols, you only get the _imp_ one.  And,
you'd get _imp__bar, not __imp_bar (the latter is obsolete).

dlltool not creating a proper import library

[Andrew Begel]

I'm try to use the Mingw32 dlltool to produce an import library from a
.def file I've got. But, the generated import library seems to be
missing a symbol that ld wants to see when it links the import library
with my code. 

When gcc -shared creates a DLL and associated import library (using the
-Wl,--outimp=libfoo.dll.a flag), for each exported symbol, in the
libfoo.dll.a file there are three symbols. One is the original symbol
_bar, the second is
__imp__bar, and the third is __nm__bar.=20

However, when I use dlltool to make an import library from a .def file,
I only get two  symbols for each exported symbol: _bar and __imp_bar.
When I try to link a DLL from a static library that contains my
generated import library (from the .def file), ld complains that
I'm missing the __nm__bar symbol:

i.e. nmth000000.o(.idata$4+0x0): undefined reference to `_nm__bar'

Before this error, I get a warning about the symbol:

Warning: resolving _bar by linking to __imp__bar (auto-import)

In my .def, I have

bar DATA

listed on its own line,

bar is decorated with

extern __declspec(dllimport) int bar;

in its .h file, and my C++ code that includes this .h, references bar.

Is this something where dlltool didn't get changed in sync with gcc
-shared, or is there a flag I can pass to make this work?

Thanks,

Andrew