This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

AfterRE: dlltool not creating a proper import library


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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]