Re: PE-COFF and import tables

["Vincent R." <forumer at smartmobili dot com>]

On Sat, 9 May 2009 22:20:16 +0100, Pedro Alves <pedro@codesourcery.com>
wrote:
> Pedro Alves wrote:
>> This was because libceoldname.a (from mingw, the equivalent of
>> libmoldname.a for CE) used to be built with `--dllname coredll.dll',
>> while coredll.def has `LIBRARY COREDLL'.  This wasn't a problem
>> for most devices, but, we've had reports of a few that refused
>> to load such binaries, so currently libceoldmane.a is build
>> with:
>> 
>> mingw/Makefile.in:
>> libceoldname.a: moldname-coredll.def $(MOLD_OBJS)
>>         $(DLLTOOL) --as $(AS) -k -U     \
>>                 --dllname COREDLL       \
>>                 --def moldname-coredll.def      \
>> 
>> So, with current sources, you'll not see "coredll.dll" anymore.
>> 
> 
> Dave Korn wrote:
>> >   Is it not working now?  You didn't yet say.  As far as I know, the
>> >   .DLL
>> > extension should be present in both cases.  I fixed a problem relating
>> > to this
>> > just recently:
>> > http://sourceware.org/ml/binutils/2009-03/msg00282.html
> 
> Thanks for the pointer.  Having now read this, I went to look at an
> executable generated by MSVC, and it has this for import:
> 
>  DLL Name: COREDLL.dll
> 
> Note that the problem I meantioned above was related to the missing
> .dll extension, but to having imports from both 'coredll.dll'
> and 'COREDLL' in the same binary,  IIRC, making libceoldname.a and
> libcoredll.a both export either 'coredll.dll' or 'COREDLL' fixed
> the issue, we ended up settling for COREDLL.  In any case,
> your fix will make use the same dll name MSFT uses, so it's
> good for CE too.
> 
>> ... are you using binutils from before or after 1st April (when the
patch
>> got
>> applied)?
> 
> If he's using binutils from cegcc svn, it's from before.


Yes and I have tested with a brand new binutils(09 May 2009) and now I have


> arm-mingw32ce-objdump -x libeet-1.dll | less

0001a050       0001a12c 00000000 00000000 0001a94c 0001a298

        DLL Name: COREDLL
        vma:  Hint/Ord Member-Name Bound-To
        1a5ac       4  _fileno
        1a5b6      19  _strdup

 0001a064       0001a138 00000000 00000000 0001aa18 0001a2a4

        DLL Name: COREDLL.dll
        vma:  Hint/Ord Member-Name Bound-To
        1a5c0     174  CreateFileW
        1a5ce     240  DeleteCriticalSection
        1a5e6     243  DeleteFileW
        1a5f4     260  DisableThreadLibraryCalls
        ...
        1a782    1322  _strdup


so there is still something wrong.

Here is the command line used to create the dll :

libtool: link: arm-mingw32ce-gcc -shared  .libs/libeet_la-eet_lib.o
.libs/libeet_la-eet_data.o .libs/libeet_la-eet_image.o
.libs/libeet_la-eet_cipher.o .libs/libeet_la-eet_dictionary.o
.libs/libeet_la-eet_node.o .libs/libeet_la-eet_utils.o  
-L/home/vincent/local/efl/mingw32ce-4.1.0/lib
-L/home/vincent/toolchains/mingw32ce-4.1.0/lib
/home/vincent/local/efl/mingw32ce-4.1.0/lib/libeina.dll.a
/home/vincent/local/efl/mingw32ce-4.1.0/lib/libdl.dll.a -lz -ljpeg
/home/vincent/local/efl/mingw32ce-4.1.0/lib/libevil.dll.a -lws2 
-Wl,--enable-auto-import -Wl,-s   -o .libs/libeet-1.dll
-Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
.libs/libeet.dll.a
Creating library file: .libs/libeet.dll.a
libtool: link: arm-mingw32ce-ar cru .libs/libeet.a  libeet_la-eet_lib.o
libeet_la-eet_data.o libeet_la-eet_image.o libeet_la-eet_cipher.o
libeet_la-eet_dictionary.o libeet_la-eet_node.o libeet_la-eet_utils.o
libtool: link: arm-mingw32ce-ranlib .libs/libeet.a
libtool: link: ( cd ".libs" && rm -f "libeet.la" && ln -s "../libeet.la"
"libeet.la" )
make[3]: quittant le rÃpertoire  /home/vincent/projects/efl/eet/src/lib
Â

I tried to understand why only _fileno and _strdup are put in a separate
entry and the only common
point is the fact these two symbols are actually defines and also that they
are defined in libcoredll.a 
and in libceoldname.a

in libcoredll.a they are defined as : _strdup and _fileno (prefixed by a _)
in libceoldname.a they are defined as : strdup and fileno