This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
AfterRE: dlltool not creating a proper import library
- To: "DJ Delorie" <dj at delorie dot com>
- Subject: AfterRE: dlltool not creating a proper import library
- From: "Andrew Begel" <abegel at eecs dot berkeley dot edu>
- Date: Mon, 4 Jun 2001 19:39:22 -0700
- Cc: <binutils at sources dot redhat dot com>,<abegel at cs dot berkeley dot edu>
After upgrading to binutils 2.11, I recreated my import library: my _bar
symbols were now gone. Since this didn't solve all my bugs, I snooped
around further and realized that I had modified my XEmacs include
headers to use __declspec(dllexport) around the Qt, Qnil symbols (etc),
but had forgotten to copy these include headers to my XEmacs build
directory, which is where I was including from to build this DLL. So,
the linker didn't know that those symbols were data symbols, and
subsequently tried to link them as functions, and failed.
Once I updated the headers correctly, everything started linking
perfectly. No more warnings, no more errors.
Oy.
Andrew
> -----Original Message-----
> From: Andrew Begel
> Sent: Monday, June 04, 2001 4:48 PM
> To: DJ Delorie
> Cc: binutils@sources.redhat.com; abegel@cs.berkeley.edu
> Subject: RE: dlltool not creating a proper import library
>
>
> > -----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
>