look like compiled with stl, but not linked with stl. iirc there was a related
issue, kevin ?

Hi, 
 
This is pure c code and should not need or use or link with stl. 
 
In fact, both the msofntextract.patch and the main makefile.mk use  
 
[kbhend@base1 msfontextract]$ grep STL * 
makefile.mk:NO_DEFAULT_STL=TRUE 
msfontextract.patch:! NO_DEFAULT_STL=TRUE 
 
So it should not be using stl or linking with stl at all. 
 
Perhaps, he is using an old version of msfontextract? 
 
Here is what ldd shows on my machine as being the dependencies of msofntextract. 
 
[kbhend@base1 bin]$ ldd msfontextract 
        libdl.so.2 => /lib/libdl.so.2 (0x0ffdd000) 
        libpthread.so.0 => /lib/libpthread.so.0 (0x0ff6c000) 
        libm.so.6 => /lib/libm.so.6 (0x0fed6000) 
        libc.so.6 => /lib/libc.so.6 (0x0fd76000) 
        /lib/ld.so.1 => /lib/ld.so.1 (0x48000000) 
 
 
 
So have you tried doing a cvs update and a clean rebuild in msfontextract? 
 
Kevin 
 

Hi, 
 
Perhaps this is not an stll issue at all? 
 
[kbhend@base1 kbhend]$ echo "_ZTVSt9bad_alloc" | c++filt 
vtable for std::bad_alloc 
 
This is straight C not C++ code.  
 
What does ldd show when run on your msfontextract? 
 
Could you have inadvertently used g++ to compile or link instead of gcc? 
 
Kevin 
 

Hi, 
 
I ran nm on my binary and not bad_alloc symbols of any type exist in the binary 
 
[kbhend@base1 bin]$ nm msfontextract | grep bad_alloc 
 
 
Perhaps you are using g++ to do the final link? 
What does your build log show? 
 
Mine shows ... 
 
gcc -Wl,-export-dynamic -Wl,--noinhibit-exec -L../../../../..//unxlngppc.pro/lib -L../lib 
-L/src2/ooo112/solenv/unxlngppc/lib -L/src2/ooo112/solver/645/unxlngppc.pro/lib 
-L/src2/ooo112/solenv/unxlngppc/lib -L/src4/IBMJava2-ppc-141/lib 
-L/src4/IBMJava2-ppc-141/jre/bin -L/src4/IBMJava2-ppc-141/jre/bin/classic 
-L/src4/IBMJava2-ppc-141/jre/bin -L/usr/X11R6/lib -o ../../../../..//unxlngppc.pro/bin/msfontextract 
../../../../..//unxlngppc.pro/obj/system.o ../../../../..//unxlngppc.pro/obj/cabd.o 
../../../../..//unxlngppc.pro/obj/lzxd.o ../../../../..//unxlngppc.pro/obj/ministub.o 
../../../../..//unxlngppc.pro/obj/msfontextract.o \ 
-ldl -lpthread  
 
which clearly uses gcc to do the linking.  In fact, we could probably remove -ldl -lpthread -lm from 
the link list compeltely since this is single thread code that does not use dlfcn functions although 
they should not hurt anything or be causing the problems. 
 
Kevin 
 
 
  
 
 

i cvs update and rebuild daily but it could be > 24h old, anyway i just did
another update so will see...here is the current version that complains. 

jim@sun:~/OpenOffice.org1.1.2/program$ ldd msfontextract
        libdl.so.2 => /lib/libdl.so.2 (0x7002c000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x70040000)
        libm.so.6 => /lib/libm.so.6 (0x700a0000)
        libc.so.6 => /lib/libc.so.6 (0x70134000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x70000000)
I configure with: 
--enable-mozilla, --with-system-zlib, --with-lang=FREN,GERM,ENUS

jim@sun:~/OpenOffice.org1.1.2/program$ nm msfontextract | grep bad_alloc
0002a788 d DW.ref._ZTISt9bad_alloc
         U _ZNSt9bad_allocD1Ev
0002a770 V _ZTISt9bad_alloc
0001a5f0 V _ZTSSt9bad_alloc
         U _ZTVSt9bad_alloc

ccache gcc-3.3 -z combreloc -Wl,-export-dynamic -Wl,--noinhibit-exec
-L../../../../..//unxlngs.pro/lib -L../lib -L/home/jim/112/solenv/unxlngs/lib
-L/home/jim/112/solver/645/unxlngs.pro/lib -L/home/jim/112/solenv/unxlngs/lib
-L/usr/local/j2sdk1.4.1/lib -L/usr/local/j2sdk1.4.1/jre/lib/sparc
-L/usr/local/j2sdk1.4.1/jre/lib/sparc/client
-L/usr/local/j2sdk1.4.1/jre/lib/sparc/native_threads -L/usr/X11R6/lib -o
../../../../..//unxlngs.pro/bin/msfontextract
../../../../..//unxlngs.pro/obj/system.o ../../../../..//unxlngs.pro/obj/cabd.o
../../../../..//unxlngs.pro/obj/lzxd.o
../../../../..//unxlngs.pro/obj/ministub.o
../../../../..//unxlngs.pro/obj/msfontextract.o \
-Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive -ldl -lpthread -lm
-rwxr-xr-x    1 jim      jim         62413 2004-04-15 22:19
../../../../..//unxlngs.pro/bin/msfontextract


I got these other errors while building
Making: ../../../../..//unxlngs.pro/bin/msfontextract
unx
cat ../../../../..//unxlngs.pro/misc/msfontextract.cmd
ccache gcc-3.3 -z combreloc -Wl,-export-dynamic -Wl,--noinhibit-exec -L../../../../
..//unxlngs.pro/lib -L../lib -L/home/jim/112/solenv/unxlngs/lib -L/home/jim/112/sol
ver/645/unxlngs.pro/lib -L/home/jim/112/solenv/unxlngs/lib -L/usr/local/j2sdk1.4.1/
lib -L/usr/local/j2sdk1.4.1/jre/lib/sparc -L/usr/local/j2sdk1.4.1/jre/lib/sparc/cli
ent -L/usr/local/j2sdk1.4.1/jre/lib/sparc/native_threads -L/usr/X11R6/lib -o ../../
../../..//unxlngs.pro/bin/msfontextract ../../../../..//unxlngs.pro/obj/system.o ..
/../../../..//unxlngs.pro/obj/cabd.o ../../../../..//unxlngs.pro/obj/lzxd.o ../../.
./../..//unxlngs.pro/obj/ministub.o ../../../../..//unxlngs.pro/obj/msfontextract.o
 \
-Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive -ldl -lpthread -lm
/home/jim/112/solver/645/unxlngs.pro/lib/libsalcpprt.a(operators_new_delete.o)(.tex
t+0x18): In function `default_handler()':
: undefined reference to `__cxa_allocate_exception'
/home/jim/112/solver/645/unxlngs.pro/lib/libsalcpprt.a(operators_new_delete.o)(.tex
t+0x20): In function `default_handler()':
: undefined reference to `vtable for std::bad_alloc'
/home/jim/112/solver/645/unxlngs.pro/lib/libsalcpprt.a(operators_new_delete.o)(.tex
t+0x24): In function `default_handler()':
: undefined reference to `vtable for std::bad_alloc'
/home/jim/112/solver/645/unxlngs.pro/lib/libsalcpprt.a(operators_new_delete.o)(.tex
t+0x40): In function `default_handler()':
: undefined reference to `std::bad_alloc::~bad_alloc [in-charge]()'
/home/jim/112/solver/645/unxlngs.pro/lib/libsalcpprt.a(operators_new_delete.o)(.tex
t+0x44): In function `default_handler()':
: undefined reference to `std::bad_alloc::~bad_alloc [in-charge]()'
/home/jim/112/solver/645/unxlngs.pro/lib/libsalcpprt.a(operators_new_delete.o)(.tex
t+0x48): In function `default_handler()':
: undefined reference to `__cxa_throw'
/home/jim/112/solver/645/unxlngs.pro/lib/libsalcpprt.a(operators_new_delete.o)(.tex
/home/jim/112/solver/645/unxlngs.pro/lib/libsalcpprt.a(operators_new_delete.o)(.tex
t+0x98): In function `allocate(unsigned, (anonymous namespace)::AllocatorTraits con
st&)':
<snip> i will attach the full output in case needed

Created attachment 14531 [details]
build log

jim@sun:~/112/solenv/inc$  echo "_ZTVSt9bad_alloc" | c++filt
vtable for std::bad_alloc

Hi, 
 
Why is thi s in your build.  It is c++ code right? 
 
-Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive  
 
It is forcing the entire salcpprt lib to be linked into the executable for no reason. 
 
What do you want to bet that the missing symbol comes from libsalcpprt? 
 
Can you use nm to check that? 
 
Is there some way to disable that piece of the compile command since it appears specific to your 
platform? 
 
Kevin 
 

Hi, 
 
So salcpprt is the problem?  That is port specific?  PPC Linux has no such beastie. 
 
What is it used for and why is it needed?   Is this added in someplace in your solenv/inc/unx*.mk 
file? 
 
Can you temporarily disable the addition of stdcpprt and try rebuilding msfontextract.  It should 
build easily with no problems. 
 
Kevin 
  

Since the beginning of time for linux sparc this was in unxlngs.mk,
LIBSALCPPRT*=-Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive
So i will try without that

Hi, 
 
I see that other unixes define their own new/delete operators and them store them in 
LIBSALCPPRT (libsalcpprt.a) but this is straight C code and so this C++ code should NOT be 
included in any way. 
 
The solenv/inc target code should be fixed (IMHO) 
 
So it looks like we somehow need to unset LIBSALCPPRT to get this to build properly for 
everyone else. 
 
Let me take a look at it and see if I can figure something out. 
 
Kevin 
 

Commented that line out from unxlngs.mk

The module builds cleanly with no complaints now. thanks for the help Kevin. I
am sorry i have to go to sleep now but I hope that will be enough to fix it. I
will report results tomorrow night. I need rebuild the whole thing now to see if
any side effects emerge. I will take this issue now.

crosssed in the mail - have it back :)

jim@sun:~/112/sal/unxlngs.pro/lib$ nm libsalcpprt.a | grep bad
00000000 V DW.ref._ZTISt9bad_alloc
         U _ZNSt9bad_allocD1Ev
00000000 V _ZTISt9bad_alloc
00000000 V _ZTSSt9bad_alloc
         U _ZTVSt9bad_alloc

Hi, 
 
Okay I changed the msfontextract to now set LIBSALCPPRT= which prevents the inclusion of 
libsalcpprt (C++ code ) into the straight C command line utility.  This change just effects 
msfontextract. 
 
Please CVS update and do a clean rebuild and all should now work. 
 
Kevin 
  

Hi, 
 
Please leave your definition of LIBSALCPPRT as it was originally (don't change it) in your 
unxln*.mk file.  It is needed for consistentcy (you are using your own new/delete).  It just didn't 
belong in a straight C command line program. 
 
So I modified the makefile.mk and the patch in msfontextract and now after a CVS update this 
should all work. 
 
This explains why Volker needed to add sal to the dependencies in build.lst. 
 
That should no longer be needed by any platform. 
 
We should be good to go. 
 
I am resolving this as fixed. 
 
Please cvs update in msfontextract and confirm. 
 
Thanks, 
 
Kevin 
 

OK this works fine in 112fix1.

btw the product asked me to upgrade to 1.2.2 which works nicely. I wonder should
it be 1.3 already? I will get a fresh cvs update and make separate issue if this
is not cleared up.

sparcmoz-->khendricks: please see issue 27912, the FontOOo version 1.3 is
installed but it asks for upgrade and returns version 1.2.2.

set target milestone