Created attachment 13140 [details]
a patch for salhelper to include libstdc++

mh->pavel: can you confirm/take care of this ?

yes.

Maho,

I do not need it when building on

pavel@leda:~> uname -a
FreeBSD leda.fi.muni.cz 4.9-STABLE FreeBSD 4.9-STABLE #0: Mon Jan 12 14:38:33
CET 2004     xbezdek@leda.fi.muni.cz:/usr/obj/usr/src/sys/LEDA  i386

with
pavel@leda:~> /usr/local/gcc-3.2.3/bin/gcc -v
Reading specs from
/usr/local/gcc-3.2.3/bin/../lib/gcc-lib/i386-portbld-freebsd4.9/3.2.3/specs
Configured with: ./..//gcc-3.2.3/configure --disable-nls
--with-gxx-include-dir=/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.2.3/include/g++-v3
--with-system-zlib
--includedir=/usr/local/lib/gcc-lib/i386-portbld-freebsd4.9/3.2.3/include/Java
--enable-shared --enable-threads --enable-threads=posix --prefix=/usr/local
i386-portbld-freebsd4.9
Thread model: posix
gcc version 3.2.3

Is this something new in new FreeBSD or compiler?

Hi, pavel
my gcc -v output is following (default installation of lang/gcc32):
% gcc32  -v
Reading specs from /usr/local/lib/gcc-lib/i386-portbld-freebsd5.2/3.2.3/specs
Configured with: ./..//gcc-3.2.3/configure --disable-nls
--with-gxx-include-dir=/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2/3.2.3/include/g++-v3
--with-system-zlib
--includedir=/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2/3.2.3/include/Java
--disable-shared --prefix=/usr/local i386-portbld-freebsd5.2
Thread model: posix
gcc version 3.2.3

as you notice, compiled with --disable-shared
http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/gcc32/Makefile
> .if defined(WANT_SHAREDLIBS)
> CONFIGURE_ARGS+=	--enable-shared
> INSTALLS_SHLIB=		yes
> LDCONFIG_DIRS=	%%PREFIX%%/lib ${TARGLIB}
> EXTRA_SHLIB=	libgcc_s
> .else
> CONFIGURE_ARGS+=	--disable-shared
> .endif

the reason why FreeBSD choose --disable-shared as default is that:
o gcc from FSF installes shared libs not came with default OS's gcc.
  compare --enable-shared and --disable-shared by
--enable-shared
% ls /usr/local/lib/gcc-lib/i386-portbld-freebsd5.2/3.2.3/
cc1*            crtend.o        libg2c.a        libgcj.a        libstdc++.a
cc1obj*         crtendS.o       libg2c.so@      libgcj.so@      libstdc++.so@
cc1plus*        f771*           libg2c.so.0*    libgcj.so.3*    libstdc++.so.5*
collect2*       include/        libgcc.a        libgcj.spec     libsupc++.a
cpp0*           jc1*            libgcc_eh.a     libobjc.a       specs
crtbegin.o      jvgenmain*      libgcc_s.so@    libobjc.so@     tradcpp0*
crtbeginS.o     libfrtbegin.a   libgcc_s.so.1   libobjc.so.1*

--disable-shared
% ls /usr/local/lib/gcc-lib/i386-portbld-freebsd5.2/3.2.3/
cc1*            crtbegin.o      include/        libgcc.a        libsupc++.a
cc1obj*         crtbeginS.o     jc1*            libgcj.a        specs
cc1plus*        crtend.o        jvgenmain*      libgcj.spec     tradcpp0*
collect2*       crtendS.o       libfrtbegin.a   libobjc.a
cpp0*           f771*           libg2c.a        libstdc++.a

Notable difference is that libgcc_s.{so,a}, libgcc_eh.{so,a} are not
included.

o Compiled binary using gcc from FSF (i.e. from ports) dosn't work
  other FreeBSD box.
  namely all the binaries from C++ links against libgcc_s.so, which is not the
  part of usual FreeBSD's distribution.
e.g.
% cat test.cc ; g++32 test.cc ; ldd ./a.out 
#include <iostream>
using namespace std;
main()
{
cout << "test\n" ;
}
./a.out:
        libstdc++.so.5 =>
/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2/3.2.3/libstdc++.so.5 (0x28074000)
        libm.so.2 => /lib/libm.so.2 (0x2811d000)
        libgcc_s.so.1 =>
/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2/3.2.3/libgcc_s.so.1 (0x28136000)
        libc.so.5 => /lib/libc.so.5 (0x2813d000)

% locate libgcc_s
/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2/3.2.3/libgcc_s.so
/usr/local/lib/gcc-lib/i386-portbld-freebsd5.2/3.2.3/libgcc_s.so.1

o so --disable-shared might be a good choice.
o libsalhelpergcc.3.so.3.1.0 requres symbols came with
libstdc++.{a|.so}, namely _ZdlPvRKSt9nothrow_t via checkdll.
% nm /usr/local/lib/gcc-lib/i386-portbld-freebsd5.2/3.2.3/libstdc++.so.5 | grep
_ZdlPvRKSt9nothrow_t
yes exactly, but not included:
% nm stlport/unxfbsd.pro/lib/libstlport_gcc.so | grep _ZdlPvRKSt9nothrow_t
%
% nm sal/unxfbsd.pro/lib/libsal.so | grep _ZdlPvRKSt9nothrow_t
%
no.

o Unfortunately, with gcc configured with --disable-shared,
  this symbol is not included while linking stlport
  (% ldd unxfbsd.pro/lib/check_libsalhelpergcc3.so.3.1.0
unxfbsd.pro/lib/check_libsalhelpergcc3.so.3.1.0:
        libsal.so.3 =>
/work/FreeBSD/openoffice-1.1.1b/work/oo_1.1.1_src/solver/645/unxfbsd.pro/lib/libsal.so.3
(0x28154000)
        libc_r.so.5 => /usr/lib/libc_r.so.5 (0x28303000)
        libm.so.2 => /lib/libm.so.2 (0x28327000)
        libstlport_gcc.so =>
/work/FreeBSD/openoffice-1.1.1b/work/oo_1.1.1_src/solver/645/unxfbsd.pro/lib/libstlport_gcc.so
(0x2833f000)
  since it is not needed.)
  however, in your case, dynamic linker notices that libstdc++.so has
  _ZdlPvRKSt9nothrow_t, so this is not the problem.

Brief summary of my patch:
o gcc-3.2 with --enable-shared produces non-working binary for vanilla FreeBSD.
  So for safty, --disable-shared is appropreate.
o dllcheck at salhelper, it checks symbol came with libstdc++ which is not
  included libsal.so, libstlport_gcc.so, so my problem occurs.
o at stlport project, libstdc++.a is linked *STATICALLY* against stlport.
  and unfortunately not linked with _ZdlPvRKSt9nothrow_t.
o Fortunately in your environmet, gcc is configured as --enable-shared,
  libstdc++ is linked as dynamic lib, so checkdll notices the symbol not
  linked at stlport. problem doesn't occur.

So my conclusoin doesn't change.

Created attachment 13756 [details]
Add $(STDLIBCPP) for solenv/inc/unxfbsdi.mk

Maho: thanks for the patch, I'll take care of it for 1.1.2.

maybe safest way to add LIBSTDCPP, just
as Linux do...

I have just reached the same with gcc 3.3.4. Second change fixes that issue.
;-)

Fixed in cws_srx645_ooo112fix1.

Verified, closing.