[Mingw-notify] [ mingw-Support Requests-1040825 ] Binutils bug?

[SourceForge.net <no...@so...>]

Support Requests item #1040825, was opened at 2004-10-05 11:10
Message generated for change (Comment added) made by haleykd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=1040825&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Earnie Boyd (earnie)
Assigned to: Danny Smith (dannysmith)
Summary: Binutils bug?

Initial Comment:
I think the attached bugit.zip file represents a bug. 
Can you please confirm it?

----------------------------------------------------------------------

Comment By: lost-coder (haleykd)
Date: 2005-07-03 19:37

Message:
Logged In: YES 
user_id=485500

Then there must be something I'm missing.  I'm assuming your
test case mirrors the scenario.  One dll source file defines
a variable and marks it for export.  Another dll source file
wants to use that variable.  If that's the case then the
following works:

a.c:
__declspec(dllexport) int foo;

b.c:
extern int foo;

dll=a+b


----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2005-07-03 05:30

Message:
Logged In: YES 
user_id=15438

But the scenario that caused me to ask and create my test
case required the data to be specifically dllimported by ld.
 Ld itself give the suggestion to dllimport.  So removing
the dllimport isn't the answer.  Perhaps I need to modify my
test case.

----------------------------------------------------------------------

Comment By: lost-coder (haleykd)
Date: 2005-07-02 22:15

Message:
Logged In: YES 
user_id=485500

Sorry Earnie but I can't upload files remember?  Anyway I
got you test to compile by removing the dllimport.  The way
it can work without doing that is your method, modify ld to
work like vc, or modify ld to work something like I suggested.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2005-07-02 21:49

Message:
Logged In: YES 
user_id=15438

Binutils bfd library is one of those that imports its own
exports.  It is not unheard of for a library to import a
variable in object foo that was created in object bar and
both foo and bar are used to create library baz.

extern char * bar; // is used in foo
char * bar = "Hello, foo!"; // is created in bar

For the DLL import/export it becomes

extern __declspec(dllimport) char * bar; // Actually extern
is ignored
__declspec(dllexport) char * bar = "Hello, foo";

So now I need an import library to resolve the reference of
bar used in foo.  And as I stated M'soft link will create
the import library and use it to build the dll.

So the RFE would be for ld to do the same without my manual
need to use dlltool.

Anyway, play with the small test case and tell me how I'm
wrong by changing it and uploading a new file.

Earnie

----------------------------------------------------------------------

Comment By: lost-coder (haleykd)
Date: 2005-07-02 20:50

Message:
Logged In: YES 
user_id=485500

Earnie,  you don't need dllimport wihtin the dll.  That's
only needed by someone outside the dll.  Also if you check
the dll only _Foo is defined there.  __imp_Foo is in the dll.a.

The best case here would be if ld recognized that it was
going to output __imp_Foo and linked any internal occurences
to _Foo.  Right now I would say this is more of a feature
request than a bug, and that any dll that imported its own
exports was probably buggy.

Since ld needs to keep a list of symbol->location why not
add the __imp variation to the list when an exported symbol
is encountered?

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2004-10-11 17:49

Message:
Logged In: YES 
user_id=15438

So this silly example demostrates how VC works this.

<file name="Foo.c">
__declspec(dllexport) int Foo1 = 1;
__declspec(dllimport) int Foo2;
int Foo3 = 2;
extern int Foo4;

int main(void) {return 1;}
</file>

So when one creates the executable Foo.exe from ``cl Foo.c''
it also creates a Foo.exp and a Foo.lib file to link with it.

Doing ``dlltool -l libFoo.a -D Foo.exe Foo.o'' is all that
is required to resolve the missing definitions and you need
to ``gcc -o Foo.exe Foo.c -L. -lFoo'' in order to get a
working executable.

One could use ``gcc -o Foo.exe Foo.c
-Wl,-out-implib,libFoo.a -L. -lFoo'' but ld complains that
it can't find -lFoo.

Earnie

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2004-10-08 12:32

Message:
Logged In: YES 
user_id=15438

So shouldh't 

__declspec(dllexport) int Foo = 0;

create a __imp__Foo symbol?  The dllimport does create a
__imp__Foo symbol.

Earnie

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2004-10-05 20:06

Message:
Logged In: YES 
user_id=15438

Better error messages are always a good thing, however ld
knows about the __imp__Foo symbol, it outputs it to
libfoo.dll.a.  Changing the make file to:

<file name="Makefile">
CFLAGS = -O0 -g --save-temps

all: exportFoo.o importFoo.o libfoo.dll

exportFoo.o: exportFoo.c

importFoo.o: importFoo.c

libfoo.dll: importFoo.o exportFoo.o
	dlltool -l $@.a -D libfoo.dll $^
	gcc -shared -o $@ $^ $@.a

clean:
	rm -f *.o *.dll *.a *.i *.s
</file>

causes the creation of the dll.

----------------------------------------------------------------------

Comment By: Danny Smith (dannysmith)
Date: 2004-10-05 18:19

Message:
Logged In: YES 
user_id=11494

I don't know if it is a 'bug', but it may well be a feature that 
MS linker supports and ld doesn't.  The importFoo code asks 
for __imp__Foo, but exportFoo only defines _Foo.  I don't 
know how hard it would be to have ld fixup the unresolved 
symbol.  Would you settle for just a better error message?

Danny

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=1040825&group_id=2435