Issue 74401 - FreeBSD porting : OOF680_m7 build fails at basctl
FreeBSD porting : OOF680_m7 build fails at basctl
Status: CLOSED FIXED
Product: porting
Classification: Code
Component: code
OOo 2.1
All FreeBSD
: P2 trivial (vote)
: OOo 2.2
Assigned To: maho.nakata
issues@porting
:
: 74419 (view as issue list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-10 12:14 UTC by maho.nakata
Modified: 2007-02-19 03:41 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation on: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description maho.nakata 2007-02-10 12:14:14 UTC
FreeBSD 6.2-RELEASE/amd64+OOF680_m7 build fails at basctl.
ccache g++41 -Wl,-z,combreloc -Wl,-rpath,'$ORIGIN' -shared -Wl,-O1
-Wl,--version-script ../unxfbsdx.pro/mis
c/basctl_basctl680fx.map -L../unxfbsdx.pro/lib -L../lib
-L/work/ports/editors/openoffice.org-2-RC/work/OOF6
80_m7/solenv/unxfbsdx/lib
-L/work/ports/editors/openoffice.org-2-RC/work/OOF680_m7/solver/680/unxfbsdx.pro/
lib -L/work/ports/editors/openoffice.org-2-RC/work/OOF680_m7/solenv/unxfbsdx/lib
-L/usr/local/diablo-jdk1.5
.0/lib -L/usr/local/diablo-jdk1.5.0/jre/lib/amd64
-L/usr/local/diablo-jdk1.5.0/jre/lib/amd64/server -L/usr/
local/diablo-jdk1.5.0/jre/lib/amd64/native_threads -L/usr/X11R6/lib
../unxfbsdx.pro/slo/basctl_dflt_version
.o ../unxfbsdx.pro/slo/basctl_description.o -o
../unxfbsdx.pro/lib/libbasctl680fx.so ../unxfbsdx.pro/slo/ba
sdoc.o ../unxfbsdx.pro/slo/basicbox.o ../unxfbsdx.pro/slo/basidesh.o
../unxfbsdx.pro/slo/basides1.o ../unxf
bsdx.pro/slo/basides2.o ../unxfbsdx.pro/slo/basides3.o
../unxfbsdx.pro/slo/baside2.o ../unxfbsdx.pro/slo/ba
side2b.o ../unxfbsdx.pro/slo/baside3.o ../unxfbsdx.pro/slo/basobj.o
../unxfbsdx.pro/slo/basobj2.o ../unxfbs
dx.pro/slo/basobj3.o ../unxfbsdx.pro/slo/bastypes.o
../unxfbsdx.pro/slo/bastype2.o ../unxfbsdx.pro/slo/bast
ype3.o ../unxfbsdx.pro/slo/brkdlg.o ../unxfbsdx.pro/slo/iderdll.o
../unxfbsdx.pro/slo/macrodlg.o ../unxfbsd
x.pro/slo/moptions.o ../unxfbsdx.pro/slo/moduldlg.o
../unxfbsdx.pro/slo/moduldl2.o ../unxfbsdx.pro/slo/objd
lg.o ../unxfbsdx.pro/slo/unomodel.o ../unxfbsdx.pro/slo/register.o
../unxfbsdx.pro/slo/tbxctl.o ../unxfbsdx
.pro/slo/basidectrlr.o ../unxfbsdx.pro/slo/localizationmgr.o
../unxfbsdx.pro/slo/dlged.o ../unxfbsdx.pro/sl
o/dlgedfunc.o ../unxfbsdx.pro/slo/dlgedfac.o ../unxfbsdx.pro/slo/dlgedmod.o
../unxfbsdx.pro/slo/dlgedpage.o
 ../unxfbsdx.pro/slo/dlgedview.o ../unxfbsdx.pro/slo/dlgedobj.o
../unxfbsdx.pro/slo/dlgedlist.o ../unxfbsdx
.pro/slo/dlgedclip.o ../unxfbsdx.pro/slo/propbrw.o
../unxfbsdx.pro/slo/managelang.o ../unxfbsdx.pro/slo/acc
essibledialogwindow.o ../unxfbsdx.pro/slo/accessibledialogcontrolshape.o
-lsvx680fx -lsfx680fx -lsb680fx -l
svt680fx -ltk680fx -lvcl680fx -lsvl680fx -lsot680fx -lutl680fx -ltl680fx
-lxcr680fx -lcomphelp4gcc3 -luno_c
ppuhelpergcc3 -lucbhelper3gcc3 -luno_cppu -luno_sal -pthread -lm -Wl,-Bdynamic
-lstlport_gcc
rm -f ../unxfbsdx.pro/lib/check_libbasctl680fx.so
mv ../unxfbsdx.pro/lib/libbasctl680fx.so ../unxfbsdx.pro/lib/check_libbasctl680fx.so
/work/ports/editors/openoffice.org-2-RC/work/OOF680_m7/solenv/bin/checkdll.sh
-L../unxfbsdx.pro/lib -L../li
b -L/work/ports/editors/openoffice.org-2-RC/work/OOF680_m7/solenv/unxfbsdx/lib
-L/work/ports/editors/openof
fice.org-2-RC/work/OOF680_m7/solver/680/unxfbsdx.pro/lib
-L/work/ports/editors/openoffice.org-2-RC/work/OOF
680_m7/solenv/unxfbsdx/lib -L/usr/local/diablo-jdk1.5.0/lib
-L/usr/local/diablo-jdk1.5.0/jre/lib/amd64 -L/u
sr/local/diablo-jdk1.5.0/jre/lib/amd64/server
-L/usr/local/diablo-jdk1.5.0/jre/lib/amd64/native_threads -L/
usr/X11R6/lib ../unxfbsdx.pro/lib/check_libbasctl680fx.so
Checking DLL ../unxfbsdx.pro/lib/check_libbasctl680fx.so ...: ERROR:
../unxfbsdx.pro/lib/check_libbasctl680
fx.so: Undefined symbol "_ZN5boost15throw_exceptionERKSt9exception"
dmake:  Error code 1, while making '../unxfbsdx.pro/lib/libbasctl680fx.so'
'---* tg_merge.mk *---'
Comment 1 maho.nakata 2007-02-10 12:24:54 UTC
% nm basctl/unxfbsdx.pro/slo/dlgedobj.o | grep
_ZN5boost15throw_exceptionERKSt9exception
                 U _ZN5boost15throw_exceptionERKSt9exception

cws basexc introduced the change, and this cws is suspicious.
Comment 2 maho.nakata 2007-02-10 12:58:52 UTC
This symbol doesn't exist for SRC680_m203...
% grep -R _ZN5boost15throw_exceptionERKSt9exception work/*
%
Comment 3 pavel 2007-02-10 18:15:29 UTC
maho: you can get better answer if you ask basexc authors directly.
You can get basexc them via EIS.
Comment 4 maho.nakata 2007-02-11 21:30:15 UTC
pjanik: thanks for your advise.

FreeBSD 6.2/i386+OOF680_m7 was build without problems.
and no symbols like_ZN5boost15throw_exceptionERKSt9exception
% nm basctl/unxfbsdi.pro/slo/dlgedobj.o | grep
_ZN5boost15throw_exceptionERKSt9exception
.
fs: could you please comment on this issue. For FreeBSD/amd64, we use
external boost (boost-1.33.1_2)
.
Comment 5 ht990332 2007-02-11 22:40:18 UTC
*** Issue 74419 has been marked as a duplicate of this issue. ***
Comment 6 Frank Schönheit 2007-02-12 07:25:14 UTC
Uhm ...

I suppose the need for the new symbol (btw: how does it look when demangled?)
comes from the usage of boost::optional. However, I where this symbol would be
found - does boost come with some libs to link to, which just need to be added
to some .mk file?

Also, I couldn't find a difference between this project and others which use
this class from boost, e.g. dbaccess.

No, sorry, I don't have an idea here ...
Comment 7 pavel 2007-02-12 07:32:21 UTC
The symbol is

boost::throw_exception(std::exception const&)

sb: do you have an idea?
Comment 8 Stephan Bergmann 2007-02-12 08:23:53 UTC
I do not really have an idea.  The standard unxlngi6.pro OOF680m7 works fine
without mentioning symbol boost::throw_exception(std::exception const&) in
dlgedobj.o.  Then again, that build uses boost from the OOo code base.  Anyway,
that boost defines boost::throw_exception in the boost/throw_exception.hpp
header, suspiciously conditionalized on BOOST_NO_EXCEPTIONS.  Maybe related is
that basctl/source/dlged/makefile.mk:1.7 does not list dlgedobj in
EXCEPTIONSFILES; a wild guess, but you could try whether that would help.
Comment 9 b.osi.ooo 2007-02-12 08:35:36 UTC
.
Comment 10 maho.nakata 2007-02-13 02:13:18 UTC
sb:
Boost of FreeBSD(from ports), definition of BOOST_NO_EXCEPTIONS is
conditional. I inserted 
#if !defined BOOST_NO_EXCEPTIONS
#error "BOOST_NO_EXCEPTIONS not defined"
#endif
or
#if defined BOOST_NO_EXCEPTIONS
#error "BOOST_NO_EXCEPTIONS defined"
#endif

in source/inc/dlgedobj.hxx, both build have failed.

BTW: following patch helped me.

Index: basctl/source/dlged/makefile.mk
===================================================================
RCS file: /cvs/script/basctl/source/dlged/makefile.mk,v
retrieving revision 1.7
diff -u -r1.7 makefile.mk
--- basctl/source/dlged/makefile.mk     2 Jan 2007 15:51:33 -0000       1.7
+++ basctl/source/dlged/makefile.mk     13 Feb 2007 00:06:27 -0000
@@ -59,6 +59,7 @@
                        $(SLO)$/managelang.obj
 
 EXCEPTIONSFILES=$(SLO)$/dlged.obj      \
+               $(SLO)$/dlgedobj.obj \
                                $(SLO)$/dlgedfac.obj    \
                                $(SLO)$/dlgedlist.obj   \
                                $(SLO)$/dlgedclip.obj   \

thanks,
Comment 11 Stephan Bergmann 2007-02-13 08:09:18 UTC
@maho:  So while it remains a mystery exactly how makefile.mk EXCEPTIONSFILES
and boost/throw_exception.hpp interact, your patch to the makefile.mk is the
right fix anyway.
Comment 12 maho.nakata 2007-02-14 02:10:24 UTC
ht990332:
does this patch help for you?

starting.
Comment 13 ht990332 2007-02-14 08:39:40 UTC
Yes, it does fix it. Thank you maho.
Comment 14 pavel 2007-02-14 08:54:18 UTC
Hmm, this bug affects some newer compilers even on unxlngi6.pro.

Is it safe enough to be done as masterfix on OOF680 as well?
Comment 15 rt 2007-02-14 08:56:11 UTC
I just wanted to ask for a target for this issue ...
Comment 16 pavel 2007-02-14 09:10:55 UTC
Thank everyone for identifying this issue.

I approve the fix for OOF680_m8.
Comment 17 rt 2007-02-14 09:28:17 UTC
Maho's patch has been committed to mws_oof680 branch, will be in milestone m8.
Comment 18 rt 2007-02-14 09:30:49 UTC
Committed to HEAD, too. Will get in next SRC680 milestone.

Issue back to submitter for verification & close.
Comment 19 maho.nakata 2007-02-15 05:44:20 UTC
verified in mws_oof680.
Comment 20 maho.nakata 2007-02-19 03:41:07 UTC
seen on OOF680_m8.
closing.