From: SourceForge.net <no...@so...> - 2003-03-26 08:01:42
|
Bugs item #683455, was opened at 2003-02-09 16:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=683455&group_id=2435 Category: gcc Group: None Status: Open Resolution: None Priority: 5 Submitted By: Johnny Willemsen (jwillemsen) Assigned to: Danny Smith (dannysmith) Summary: Getting auto-import warnings even when explicit im/ex Initial Comment: I am working on the ACE/TAO port to MingW (see www.cs.wustl.edu/~schmidt). I have setup a daily build that builds ACE/TAO daily with MinGW. The results of the build are available at http://doc.ece.uci.edu/scoreboard/ We do explict import and export using __declspec import/export. But we still get a few auto-import warnings. This is a class with 2 static members but we only get a warning on one of them, the other gave warnings before we did explicit import/export but now not anymore. When we disable auto import we still get these warnings. I think we should be able to get rid of this warning, now we do explicit import/export. ---------------------------------------------------------------------- >Comment By: Johnny Willemsen (jwillemsen) Date: 2003-03-26 08:15 Message: Logged In: YES user_id=585332 I don't completely understand your last remark. Who's bug is this now? I thought it is a MinGW/Cygwin specific and must be fixed there. I can imagina that my remark about GCC confused you. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-03-25 20:01 Message: Logged In: YES user_id=11494 I expect that it is deep within the cp parser in gcc/cp. I have tried experimenting with the sub-target frontend bits in config/i386/winnt.c , but with no sucess. If you submit a bug repor or request for help on gcc lists you should probably base it on a build from FSF sources rather than mingw gcc sources, since many of the functions which relate to C++ dlimport have been modified in mingw sources. Danny ---------------------------------------------------------------------- Comment By: Johnny Willemsen (jwillemsen) Date: 2003-03-25 11:43 Message: Logged In: YES user_id=585332 I have checked this and adding ACE_Export to the forward declaration fixes the warning. It is now gone but now is the question how to continue. This is not a real show stopper and MSVC and Borland C++ Builder don't have a problem with this so this can be considered a bug. Any idea when this bug can be fixed in GCC. MingW and Cygwin both have the same problem and I can imagina that much more people get this warning. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-03-25 11:07 Message: Logged In: YES user_id=11494 Attached is a small testcase that shows a bug that may be the problem in ACE as well. In ACE.h, change the "forward" declaration from class ACE_Time_value to class ACE_Export ACE_Time_Value and see if that fixes. If the class is declared without the dllimport attribute it overrides the earlier attribute on the definition. This doesn't effect any simple data imports (the static int instances in my testcase) since they have already been marked, but does affect the static object that requires static initialization using the class constructor. Also there seems to no problem if the dllimport'd definition actually follows the forward declaration I realise that this may be considered a bug when compared to MSVC behaviour, but it may be difficult to fix within gcc. Danny ---------------------------------------------------------------------- Comment By: Johnny Willemsen (jwillemsen) Date: 2003-03-25 07:01 Message: Logged In: YES user_id=585332 The warning we get is: Info: resolving __ZN14ACE_Time_Value8max_timeE by linking to __imp___ZN14ACE_Time_Value8max_timeE (auto- import) On the scoreboard at http://doc.ece.uci.edu/scoreboard/integrated.html you will find the MingW results, but at this moment someone made an error in ace so you don't see this warning. Probably you will see these warnings tomorrow on the build again ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-03-25 00:05 Message: Logged In: YES user_id=11494 I think I have a solution fot GCC trunk (3.4) but need some help from you before proceding. What _exactly_ (ie, stderr, verbatim) is the error message you get with ACE (just to be sure we're looking at the same bug). Danny ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-03-24 22:56 Message: Logged In: YES user_id=11494 I've got a reasonably sized testcase now, but need to reduce it further. For unknown reason(s) it passes on my build of gcc-3.2.2 but shows the bug you report on gcc-3.3. I don't know if or when you can expect a fix. But it is an important bug because it affects vtable imports too. Danny ---------------------------------------------------------------------- Comment By: Johnny Willemsen (jwillemsen) Date: 2003-03-24 06:56 Message: Logged In: YES user_id=585332 Several peopl already have tried to reproduce the problem in a simple test application but nodoby succeeded. Does this fix also is used by the cygwin people? The Cygwin compiler has the same problem. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-03-24 00:12 Message: Logged In: YES user_id=11494 The problem with comments in dlltool-generated def files is fixed in binutils CVS, following Luke's suggestion. However, I don't have any evidence that the def file was the problem. I have tried to construct a small testcase with dllimport of static const data members, but have not been able yet to reproduce your error, so I'm missing something. If you could provide such a testcase, I could answer your question about a fix. Danny ---------------------------------------------------------------------- Comment By: Johnny Willemsen (jwillemsen) Date: 2003-03-23 18:39 Message: Logged In: YES user_id=585332 Sounds that you are on the right track. Anyone a clue when there is an updated version we can try to see if the warnings are gone? ---------------------------------------------------------------------- Comment By: Johnny Willemsen (jwillemsen) Date: 2003-03-19 10:40 Message: Logged In: YES user_id=585332 Both are static const members. From the ACE header file class ACE_OS_Export ACE_Time_Value { public: static const ACE_Time_Value zero; static const ACE_Time_Value max_time; From the .cpp file // Static constant representing `zero-time'. // Note: this object requires static construction. const ACE_Time_Value ACE_Time_Value::zero; const ACE_Time_Value ACE_Time_Value::max_time (LONG_MAX, ACE_ONE_SECOND_IN_USECS - 1); You can also see the complete files at http://cvs.doc.wustl.edu/cvsweb.cgi/ACE_wrappers/ace/Time_ Value.h?rev=4.21&content-type=text/x-cvsweb-markup and http://cvs.doc.wustl.edu/cvsweb.cgi/ACE_wrappers/ace/Time_ Value.cpp?rev=4.7&content-type=text/x-cvsweb-markup ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-03-19 10:24 Message: Logged In: YES user_id=11494 I'll guess that these two symbols ACE_Time_Value::zero ACE_Time_Value::max_time are static const members. Yes? I'll also guess that "zero" is initialised inline? say to a zero Filetime-like union? How/where is max_time initilaised? There is a bit of confusion about how static consts should be treated wrt dllimport. IIRC initialised plain ordinary data is not imported, but there was problem with static const members that were objects that need constructors. This was partially sorted out with 2.95 and the patch was ported to 3.x but I've not really looked at it much. It my not have travelled well. Does it sound like I'm on the right track? Danny ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2003-03-19 10:22 Message: Logged In: YES user_id=30442 ld only allows ";" comments in .def files at the beginning of a line, but dlltool allows them anywhere (at the start of a token) so to make them compatible ld should probably be changed. However, MS says that comments must be at the beginning of a line so technically dlltool's output is incorrect. http://msdn.microsoft.com/library/default.asp?url=/library/en- us/vccore/html/_core_Rules_for_Module.2d.Definition_Statem ents.asp Danny: If we decide that ld should be changed then we need to change this (ld/deffilep.y): if (saw_newline && c == ';') to this: if (c == ';') On the other hand, dlltool could be changed to put the demangled name in comment on the line preceding or following the exported name. Which do you think is best? ---------------------------------------------------------------------- Comment By: Johnny Willemsen (jwillemsen) Date: 2003-03-19 08:10 Message: Logged In: YES user_id=585332 We haven't been able to reproduce the problem yet in a small example. Can this be caused by the following which is done in the makefile structure of ACE? dlltool --export-all --output-def $(VSHDIR)$@.def --dllname @ \ $(VSHOBJS1) \ && mv $(VSHDIR)/$@.def $(VSHDIR)/$@.def.old \ && sed 's/;.*$$//g' < $(VSHDIR)/$@.def.old > $(VSHDIR)/@.def \ && $(SOLINK.cc) -Wl,--enable-auto-image-base -Wl,--out- implib,$@.a \ -shared -o $@ $(LDFLAGS) $(VSHDIR)/$@.def \ $(VSHOBJS1) $(ACE_SHLIBS) $(LIBS) The comments are stripped from the .def file. When we let the comment stay, we get a crash of ld. This is on the lines that have ... at the end of the line or are from a operator == From the .def file this are the things we have problems with _ZN14ACE_Time_Value4zeroE @ 1067 DATA ; ACE_Time_Value::zero _ZN14ACE_Time_Value8max_timeE @ 1068 DATA ; ACE_Time_Value::max_time Does anyone know something to do about this? ---------------------------------------------------------------------- Comment By: Johnny Willemsen (jwillemsen) Date: 2003-03-19 08:09 Message: Logged In: YES user_id=585332 We haven't been able to reproduce the problem yet in a small example. Can this be caused by the following which is done in the makefile structure of ACE? dlltool --export-all --output-def $(VSHDIR)$@.def --dllname @ \ $(VSHOBJS1) \ && mv $(VSHDIR)/$@.def $(VSHDIR)/$@.def.old \ && sed 's/;.*$$//g' < $(VSHDIR)/$@.def.old > $(VSHDIR)/@.def \ && $(SOLINK.cc) -Wl,--enable-auto-image-base -Wl,--out- implib,$@.a \ -shared -o $@ $(LDFLAGS) $(VSHDIR)/$@.def \ $(VSHOBJS1) $(ACE_SHLIBS) $(LIBS) The comments are stripped from the .def file. When we let the comment stay, we get a crash of ld. This is on the lines that have ... at the end of the line or are from a operator == From the .def file this are the things we have problems with _ZN14ACE_Time_Value4zeroE @ 1067 DATA ; ACE_Time_Value::zero _ZN14ACE_Time_Value8max_timeE @ 1068 DATA ; ACE_Time_Value::max_time Does anyone know something to do about this? ---------------------------------------------------------------------- Comment By: Johnny Willemsen (jwillemsen) Date: 2003-02-10 08:13 Message: Logged In: YES user_id=585332 The disabling of the warnings works, but I think it is not the correct way to go. I will try to create a small test application soon. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2003-02-09 20:02 Message: Logged In: YES user_id=11494 If you add -Wl,--enable-auto-import that should get rid of warnings. Could you please send an example of a class that is causing the warning (for one member but not the other). even with explict __declspec(dllimport). Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=683455&group_id=2435 |