[Mingw-notify] [ mingw-Bugs-916114 ] ld dllexport bug still there (partially)

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

Bugs item #916114, was opened at 2004-03-15 07:44
Message generated for change (Comment added) made by dannysmith
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=916114&group_id=2435

Category: ld
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: OROSZI Balázs (oroszib)
Assigned to: Danny Smith (dannysmith)
Summary: ld dllexport bug still there (partially)

Initial Comment:
Hi!

gcc core version: 3.3.3 (candidate from mingw website)
g++ version: 3.3.3 (candidate from mingw website)

I got notified that gcc 3.3.3 fixed a bug related to
incorrectly exported symbols. However I still have the
problem.

Attached is a zip archive containing a (heavily
modified) header and a source file, sliced and stripped
from NeoEngine (neoengine.sf.net), as well as two batch
files (both contain one line, issuing the compilation).

1. build.bat compiles without optimization
2. build_o.bat compiles with -O1

Their output will be:
1. test.dll, libtest.a, test.def
2. test_o.dll, libtest_o.a, test_o.def

Note the difference between test.def and test_o.def
test_o.def doesn't have this symbol:

    _ZTVN9NeoEngine16TextureMatrixGenE @8 DATA

(however test.def has)
And that's a big problem, as compiling the rest of the
engine gives undefined reference errors to the above.
It seems the optimization "wipes out" that class. The
class is not a "normal" one, actually has only static
members and pure virtual methods.

Actually I wanted to get rid of the
--export-all-symbols flag when compiling, but this
error prevents me.
Any thoughts?

--
Greetings,
Balázs

P.S.: I also attached the .def files, in case you
cannot compile, but might be able to answer seeing the
outputs.


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

>Comment By: Danny Smith (dannysmith)
Date: 2004-03-15 10:05

Message:
Logged In: YES 
user_id=11494

Thanks for the report. 
In my tests, the vtable data  
_ZTVN9NeoEngine16TextureMatrixGenE
is  _not_ emitted at -O1  even if you build a static lib or if 
you use --export-all. 

I'll investigate further, but I think that this bug is not the
falure to export the symbol, but rather that vtable data is 
always marked as dllimport, when perhaps it should be 
emitted locally.

Danny

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

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