Not only Panther, I see it on the Mac Tinderbox (PPC) with Tiger as well.

running "build" in i18npool over and over again finally gets the module built

(the one that just broke, compiles fine the second time, but another one then fails)
I didn't try the run "build" over and over again method too often, but when
it occurs, you need quite a bit of runs (more than 10) - building the very same 
code on another day doesn't break at all.

*** Issue 79308 has been marked as a duplicate of this issue. ***

remover linebreak from summary

Trying to build with gcc 3.3 (one can use gcc_select 3.3 to switch compiler)
will  always break at the first localedata (en_AU) - multiple builds won't help
in that case.

Using cppuhelper from SRC680_m211 doesn't break - so the cause is very likely
buried somewhere in there. Some sideeffects of bunoexttm seem to cause this.

Adding Kay to CC:.

I can reproduce the problem on linux as well → OS to Unix/ALL

I tried with a rather old compiler (gcc 3.2.3) and it fails hard, with a
segmentation fault. Multiple builds don't help, just as with gcc 3.3 on Mac.

Using cppuhelper from m211 worksaround the problem on linux as well.

I'll attach a gdb log that was generated as follows:
configure with --enable-symbols, additionally build=debug in bridges, cppuhelper
and i18npool

I hope it helps tracking down the problem

Created attachment 47442 [details]
gdb generated backtrace

Created attachment 47443 [details]
valgrind log - not sure whether this helps or not (all on m225)

As it is reportedly broken on SRC680m225:  Seems that for some reason in
bridges/source/cpp_uno/shared/cppinterfaceproxy.cxx:1.7 either dso_init is not
called or dso_exit is called too early.  Maybe the __attribute__((constructor))
stuff does not work on all GCC versions, and dso_init is not called at all.

Yay, that seems to be the cause. Using rev 1.6 of
bridges/source/cpp_uno/shared/cppinterfaceproxy.cxx allows to build i18npool on
both linux (gcc 3.2.3) and Mac (with gcc 3.3)

Hi cloph, thanks for your analyze, could you please add
--leak-check=full to valgrind to be more verbose?

BTW:
MacOSX Tiger+SRC680_m222 (AQUA) build failed like:

ccache gcc-4.0 -fsigned-char -fmessage-length=0 -malign-natural -c -O2
-fno-strict-aliasing   -I.  -I../../../unxmacx
p.pro/inc/localedata -I../inc -I../../../inc/pch -I../../../inc
-I../../../aqua/inc -I../../../unx/inc -I../../../unx
macxp.pro/inc -I.
-I/Volumes/OpenOffice.org/Tiger/2.0/work.SRC680_m222.AQUA/SRC680_m222/solver/680/unxmacxp.pro/incdo
nt_use_stl
-I/Volumes/OpenOffice.org/Tiger/2.0/work.SRC680_m222.AQUA/SRC680_m222/solver/680/unxmacxp.pro/inc/external
 -I/Volumes/OpenOffice.org/Tiger/2.0/work.SRC680_m222.AQUA/SRC680_m222/solver/680/unxmacxp.pro/inc
-I/Volumes/OpenOff
ice.org/Tiger/2.0/work.SRC680_m222.AQUA/SRC680_m222/solenv/unxmacxp/inc
-I/Volumes/OpenOffice.org/Tiger/2.0/work.SRC6
80_m222.AQUA/SRC680_m222/solenv/inc
-I/Volumes/OpenOffice.org/Tiger/2.0/work.SRC680_m222.AQUA/SRC680_m222/res -I/Volu
mes/OpenOffice.org/Tiger/2.0/work.SRC680_m222.AQUA/SRC680_m222/solver/680/unxmacxp.pro/incdont_use_stl
-I/System/Libr
ary/Frameworks/JavaVM.framework/Versions/Current/Headers
-I/System/Library/Frameworks/JavaVM.framework/Headers     -I
/Volumes/OpenOffice.org/Tiger/2.0/work.SRC680_m222.AQUA/SRC680_m222/solver/680/unxmacxp.pro/inc/offuh
-I. -I../../../
res -I. -pipe -fsigned-char -malign-natural  -Wall -Wendif-labels -fPIC
-fno-common -DMACOSX -DUNX -DVCL -DGCC -DC341
 -DPOWERPC -DCVER=C341 -DGLIBC=2 -D_PTHREADS -D_REENTRANT -DNO_PTHREAD_PRIORITY
-DPOWERPC -DPPC -DSTLPORT_VERSION=400
 -D_USE_NAMESPACE=1 -DHAVE_GCC_VISIBILITY_FEATURE -DNO_AUDIO -D__DMAKE -DUNIX
-DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr
/include/c++/4.0.0 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL
-DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA -DS
RC680=SRC680  -DBUILD_OS_APPLEOSX -DBUILD_OS_MAJOR=10 -DBUILD_OS_MINOR=4
-DBUILD_OS_REV=10 -DQUARTZ -DSHAREDLIB -D_DL
L_   -o ../../../unxmacxp.pro/slo/localedata_others_version.o
../../../unxmacxp.pro/misc/localedata_others_version.c
if ( -e ../../../unxmacxp.pro/slo/localedata_others_version.o ) touch
../../../unxmacxp.pro/slo/localedata_others_ver
sion.obj 
../../../unxmacxp.pro/bin/saxparser en_AU en_AU.xml
../../../unxmacxp.pro/misc/localedata_en_AU.cxx ../../../unxmacxp
.pro/bin/localedata_en_AU.rdb
/Volumes/OpenOffice.org/Tiger/2.0/work.SRC680_m222.AQUA/SRC680_m222/solver/680/unxmacxp
.pro/bin/types.rdb
dmake:  Error code 132, while making
'../../../unxmacxp.pro/misc/localedata_en_AU.cxx'
---* tg_merge.mk *---

maybe this bug is not gcc3.3 specific but applies to gcc4.

Created attachment 47512 [details]
valgrind log with --leak-check=full

Created attachment 47514 [details]
valgrind log with --leak-check=full --show-reachable=yes

Looking into this ...

Anything else I need to know to reproduce this? Just successfully build i18npool
twice on a

  Darwin 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007;
root:xnu-792.22.5~1/RELEASE_I386 i386 i386

By the way, is this Panther? And how can I find out?

Using gcc:
:~/m225/i18npool$ gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

not using ccache.

You missed two facts already mentioned here:

With the default compiler (4.0.1) it only breaks "randomly", not at every build
and
When you switch compiler to the alternative one (with gcc_select 3.3), then it
breaks every time.

It is 100% reproducible with gcc 3.3 on Mac OSX Tiger

(darwin 8 is Tiger)

Spend some time on this ... unfortunately the gcc-3.3s on our local Macs don't
seem to work, likely need to (re-)install them.

Tried gcc-3.3 as well on Linux, basically stumbling over STL and BOOST problems
... this seems to be a mess.

There are two error traces in this issue, one with with gcc-3.3 and another one
with gcc-4.0, Maho saying something that this happens with gcc-4.0 as well,
which basically is the reason I tried gcc-4.0 first.

->Cloph: What does randomly mean? Could you be more precise, e.g. 1 of 10
attempts or something?

As mentioned elsewhere, the whole thing is related to a c++ (mis-)feature wrt to
atexit, leading to crashes while terminating if using static values. If it comes
out that __attribute__((constructor)) etc. are indeed not working with gcc-3.3
as expected, I am likely going to do the "real" fix and to ref-count the vtable,
constructing it on first bridge instantiation and destructing it on last bridge
destruction.

By the way, is gcc-3.3 still required or could we just abandon it?

> Cloph: What does randomly mean? Could you be more precise, e.g. 1 of 10
attempts or something?

I'm not cloph... randomly mean, 1 of 10 attempts goes well and the other 9
fails, and sometimes passes without errors, etc.

Created attachment 47727 [details]
a crashreport that apples crashreporttool creates

I failed to create a corefile (ulimit -c unlimited, then it crashed but I
couldn't found any coredump file - neither in the current directory nor in
/cores), but maybe the crashreport already contains the necessary data?

(built with gcc 4.0.1 on tiger)

Reason for not getting a corefile was simple: My unprivileged build user didn't
have write access to /cores - so now I can generate core-files en masse...

Created attachment 47746 [details]
Patch for bridges cppinterfaceproxy to not use __attribute__((constructor)) etc in case of gcc 3.3, but to export dso_init / dso_exit as C functions ...

Created attachment 47747 [details]
Patch for bridges ... makefile.mk to build (and link) gpp33wad.c in case of GCC

Created attachment 47748 [details]
Workaround for G++ 3.3 not calling __attribute__((constructor)) etc. for dso_init/-exit; to be placed into bridges/source/cpp_uno_/shared as "gpp33wad.c"

Just add three attachments fixing the vtable construction problem at least on
Erics box ... please give it a try :-)

->Eric: Could you confirm the patches are fixing the problem?

the changes at least work for me on linux with the old compiler, but since
nothing is changed for Tiger (Mac OSX 10.4) or more precise for gcc 4.x (which
is the default on Tiger), the problem persists...

->Cloph: The attached patch addresses an issue regarding
"__attribute__((constructor))" and friends not working with g++ 3.x . As far as
I can tell, this is an either it works or it does not work issue, and may not
fail randomly ...

So, this issue seems to be two ...

Yes, you are right.

As written above, the problem on linux with gcc 3.2, or on tiger with the
alternative, older compiler (gcc 3.3) are not random, they always fail. 

The problem on tiger with the default (gcc 4) is "random".

it does happens on PPC Tiger. change summary.

Created attachment 55690 [details]
a workaround ....

Does the last workaround solve the issue completely on your system, or does it
make the error appear less frequently?

And is -g really needed or is -O0 enough? (one could use the NOOPTFILES then
instead of fiddling with CDEFS directly - would IMHO be a cleaner way to
workaround it)

I did a few tests 
for file in <different makefiles>; do cp -f $file source/localedata/makefile.mk
; for ((i=1; i<=15; i++)); do echo $i >> $file.log; rm -rf unxmacxp.pro/ ; build
|| break ; done; done

where the different makefiles had different combinations of one or two of the
three obj-files in the NOOPTFLAGS macro. The only combination that did pass all
15 iterations was the combination of the saxparser.obj and LocaleNode.obj

While this only tells that other combinations don't work (might reduce frequency
of the breakers, but not workaround them completely), this combinations seems to
do the trick.

As it is a non-reproducible failure, one might need to add all three to really
make the problem go away.

I did start a new test with 50 iterations with the two files as nooptfiles - if
that works, I'm pretty confident that the two are enough.

Created attachment 56095 [details]
use nooptfiles macro instead of modifying CDEFS directly

:-( unfortunately that patch is not enough, adding all is not enough in a
real-life build.

The only way that always (well, at least 'til now) results in a successful build
is to compile cppu with debug.

.

*** This issue has been marked as a duplicate of 96647 ***

duplicate -> closed