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'
-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 anon
Thanks Jaak. I also tested surrounding the symbols in an anonymous namespace
but this alone did not fix the problem for me.
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 initializat
On 11.09.2013 22:35, DM Smith wrote:
> The C++ standard does specify order w/in a file (top down), but not
> across files.
Yeah, something like that. It is explained in detail in 3.6.2 of the C++
03 standard. I've attached a patch which fixes the issue for these
globals (and as a side effect might
The C++ standard does specify order w/in a file (top down), but not across
files. This fact can be used to order across files by using a global from one
to initialize a global another. Don't recommend it, but it is nice when it is a
must.
-- DM
On Sep 11, 2013, at 12:56 PM, "Troy A. Griffitts"
Jaak, I disagree that your comments have anything to do with this problem. I
have confirmed that the 3 file globals immediately preceding the problem global
have been initialized. I doubt you are saying the c++ standard doesn't support
initializing a global array and then initializing a global s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It's not a compiler bug.
Basically the C++ standard does not enforce an initialization order
for globals. So the compiler is free to initialize such stuff in any
order. I think your toolchain just happens to be lucky enough to do
that in an the order
Hey Jaak,
Thank, yeah, but why? :)
My investigation turns up:
shared build works fine and valgrinds clean
static build on g++ (GCC) 4.8.1 (F19) fails
static build on g++ (GCC) 4.4.7 (RHEL 6.4) works fine and valgrinds clean
In the error case, it seems that std::list's c-tor(iterator start,
i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm pretty sure that the crash is because the global
const StringList oValues(&choices[0], &choices[2]);
in ../src/modules/filters/utf8greekaccents.cpp:41 is not initialized
when it is used in UTF8GreekAccents::UTF8GreekAccents() to initialize
the
I hate to bring this up, now, when we really all want 1.7 out, but
current svn head produces a segmentation fault in imp2gbs. The other
utilities insofar as I tested them seem to be fine.
Below the stacktrace. Tell me if you need more. I basically use
usrinst.sh produced binaries, with the only mo
10 matches
Mail list logo
