From: SourceForge.net <no...@so...> - 2005-07-03 11:30:17
|
Support Requests item #1040825, was opened at 2004-10-05 13:10 Message generated for change (Comment added) made by earnie 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: Earnie Boyd (earnie) Date: 2005-07-03 07: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-03 00: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 23: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 22: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 19: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 14: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 22: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 20: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 |