Just committed a large delta which checks for all file local globals and
uses Jaaks suggested method for initializing these to avoid global
initializer order conflicts.
The commit looks large, but it is a very regular change, there are some
whitespace changes as well when I saw code that didn't conform to our
style guide.
The details of the problem are as follows and exemplified in the minimal
test case http://crosswire.org/~scribe/global_init_order_bug.tar.gz
D.cpp has file local globals with constructors (not, for example, const
char *, which works fine)
main.cpp declares a global D instance object.
In this scenario, both compile units D.cpp and main.cpp have a global
init which each need to run. The C++ standard says that there is no
order specified for which one runs first.
In the failure case main.cpp's global initialization runs first and
tries to call methods on D (specifically D's c-tor) before D's global
initialization has run.
Jaak has well pointed out the problem and the solution, which I have
implemented in all of our option filters that used this pattern. Thanks
Jaak!
I just always unconsciously assumed the compile unit with main() would
be initialized last, after all libraries had already been initialized--
and it seems that every version of every compiler we've ever tried
before this recent version of g++ has implemented things this way. But
indeed the spec never says anything about the compile unit with main()
being any different than any other compile unit, so there's nothing
keeping a compiler from initializing it first.
Anyway, big commit, fairly uniform change, so not as big as it looks.
All regression tests pass. I'm not going to cut a new RC until I look
at the recent post from John Austin tomorrow, so have a go at SVN if you
have time.
Thanks again Jaak for the fix, and Peter for reporting the problem,
Troy
On 09/12/2013 12:07 PM, Jaak Ristioja wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 12.09.2013 09:54, Troy A. Griffitts wrote:
Thanks Jaak. I also tested surrounding the symbols in an anonymous
namespace but this alone did not fix the problem for me.
Do I understand you correctly, that the patch worked, but just using
an anonymous namespace didn't work? - This is what I think is to be
expected. The anonymous namespace might just help prevent these
globals from being exported as symbols from the library.
Can you explain again why there is even a problem at all?
Again, every one of those globals is in the same compile unit and
in the correct order, top down. The initialization spec you cite
does not seem to explain the issue, unless I'm daft.
No they are not in the same translation unit. The variable "oValues"
is in utfgreekaccents.cpp:41 and "greekAccentsFilter" is in
imp2gbs.cpp:62.
Sorry, no time to explain. ;( But please read
http://www.parashift.com/c++-faq/ctors.html
from 10.14(10.12) to 10.18, and the init_priority section from
http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html
I hope this helps.
Blessings,
Jaak
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQgcBAEBAgAGBQJSMZJzAAoJEEqsYmEt1rCO3UxAALM5l7xWMfL+4nqmFeZi/nmS
WKSk7xJ7KyLt+Tbj9y0MA5ZMhfObgNZRi/PHhkpNTdIIwWemFD+KoOuAv+kXB+9r
X5RPrkZCGbJ6hemio1LC+E7xaMLE1dQg7aeMY16f/UHlhZQfsQGe0cZWf5me+jgA
WOZaPpzGAaPh+edo8TyUVMfpP3SSJlgmaUoddZbYLrPdYjwRakvqP6Rhux/j68gi
lwlkHrAwubpdLJn2jAgaL8VtcxT6hux8KKLRyBfeGr65FPvSMwclVXq0phbWC6eO
YcGZdWlX9oIV+Hggi2EvDNCOdTcpqav5g3sRzKQZwkL/hbG7ZFcCeV8Wt4z/rxQh
CHBCj+UDlUletTpvFCpum/2uDbkmQwgCZS3dekRQgg3h3A+m346PNaYKgBD3n5T8
YhAsSHPLyPE0afLRYl569SjZNdBPwtjr/y74FPBzOwkathJ5jv5pusNcaiHfbMK9
4VuDZk6kGTMz12DFXh7Sv25yK69v1LxGZAV43ofa8Xs4U3REIAtxADsptxYekSjI
ywYKpz3gdjwn5N33G513eRlaqN71ZiqIBcrIlmq18bWoJJzDIoLhsz/0I6jBJh8k
h0Cb+ckFP1c/B6veRrOibfehF1rL6kDLULny+8p/DoYMXDR9wlf+PwLO8Xy0mibp
0ZTr8iiLTqIb2puC4TP8RqdDkV7PXP777+8kkRRLhS99jVX0fzmRq/EiYxUkSj41
nlxlxYsy4QLpHlctIRHZvY0LzCFzd+dEWQl5VTq13SL24aMjAEcsgePoiQH5CuJx
YNv2bxEhUkd9nRJMwN8h3PakKrS+gAi+N0Y8hEV8n9TIivb/jMaw1eroZQWCgn+g
6Yxm740ZipimIU+ZKFs+mx/+GM0DLzc4NfI0GJS/iY/ZkQ9cdULJZepQo79Jws/a
EYJZLSLsZGCLKNmRY6wGL4+hTZ1jWIt1gzn1C0c0qspsSPbdKaB8IMYr6x/LrRLA
8DnEU2TUAmGUfF1n8E6ULndeszWw/SX5/dhH6hiHQiOk5ge8/6uqp3vXTzgh6E0g
OhmOB+1c7Pl5x500K0xUHh6EiejSJpg2lj/8ZLeZ1QfU/cp5TkHIvKLTcUvA22UK
LZbE/J2v9SaETgWdjMHdu0ti8cHy6toJbKGAZwIGGMB/tHle/GOZrtJ4gvpc5iLP
9sEe6AGKp+VYlBrjCLmuJn+l7kMHInJ188JsNhr032zU/ee5ca3D8u5RSJ7kQ3rn
cTNw1Z3n7zpLcLa5rWr3ynbkP3PG55DOR47ju8R8vK7zuCmRXoyZlpKPA/MDJm0F
QqgHC+74IS0P1WHhs8nQZ9PSYX54+E14HlgvcgTI21wy4FM6jteb88xDj88gBlav
+4N0pPacs+PH+YGbSWOSmml6asxXZLEcNMqUm3zIUORaUUgztT2/vwKt7BfsUiBD
JQoiorF8COqa0VtcTtPiKvVmSLifF0u9iz957Q25WR0TpDMXoHXt0Oxc5FVvRbQ4
PCbsDedgix2c8XtXekTCPDJ4glNBEPhy7sZol7p60At4trzv2ex1NTFWAnhbr9H5
XUstb1kelaRqC82+qAspMyADreWVfEBDARiTH+jlKt52TCxo36H1Klf+2bz7SV64
gPgG+eVJuaGqggcT7DPuXxN+sLsBPyPmhrk76EjXOuEn+Ww1LfS4PArucjW5i48X
FX8pu96y4NfC80xH8wlBBrRgj/y9mT503voyChwOB+jmbhsu9UVQ4gqFWV7qk0FI
karI9tALKAWlTlZMgOQIO/HKkHGLSXsPVtZMchqaTGlFYIfPfX1PUQYDMni/YUQ0
ooIQDIBAC+tBQhln+tz4L34B8DysSzPY6sNmHLoobINB7rqXmmSrd+LPGAgTSZ2a
+RBpjK6mR5w5Is0CgMb8rJIrMD6ZeE4wuPJv0p60K2fJ7oMlImeBDEdRvxUOJ3bF
777//mvZVUDeCvsZhV8WTU/9amp/BwIJXUaccVx3Bgjstbqwr3rOEPt+XTkV3qoV
fKq+Ka6yZ+/6f5fdl8dqnkgXwBahKJ6WZXhgRZCC7XJUXSEeR7bMoOOxcNSkic6J
ci1vZkD4nlwQQS0zLvTRxOFx+QuaoU0JTOjwhqLusJzCT/7ZfBaJ8ftlM+GxfCEa
VA1MORSYk0OKg5w0LkAblLumDJWG6VrPu3a+omAbqdbRbTb9f5P+zIWQ8LllfOOP
Eu8Gf3EPG8ZL12XNR/JsmlNWLPWmWxEV3xRrFdcuVtttJf90ecwbzjIS1fwO2pEO
6gFmV890ggnutT7yl/tqsj3BCusFCctqbk8/BefPfmmWmdLrPDUFBIlpZVur/GgQ
1etzyLvqvxAKiXfZGKrGqExUVkArUCX9eDRe+weVam59fjJFjz9/LTY5Cd76jHwe
PrJT1ym+YYA1Q8gx/fyoWBYvHPNSaEajaqzQ1camnt4OgwHTtpNnvJsHmsZjgxcg
8OwHv9hb3fm8m81+ddgY1Bu37QGoUEvQXDf1+roEvuyp4wZIZyzcAVRHHn/reuNb
54VWl6ofymNjUh7c9MMKX1S5DQJmD6ziJ7CAtrgCUbl6Wp+eb4KPqAooVvPjhv9N
sacFw4A1mSerGfP8KLTU+CfcnYnZHRTYaVI4FLZ2hSirByMouAO9TIH7LnIOGeiH
xIJt4TJsAkSHTmHGwZka7SHDhYEW9c9OvBGVtqqriMc0x/6Bf6dC2P/GpGazK5aC
F4bCwmeVnE2f12Ffcr8O
=PRlE
-----END PGP SIGNATURE-----
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
