different build failure on 6.1-STABLE i386

[NAKATA Maho]

Hi,

In Message-ID: <20060826024739.421383f6.nork at FreeBSD.org> 
Norikatsu Shigemura <nork at FreeBSD.org> wrote:

> > Any ideas?
> 
> 	I'm testing following way:
> 
> /etc/libmap.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> libc_r.so.6	libpthread.so.2
> /etc/libmap.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 
> 	libmozabdrv2.so was linked libc_r.so.6.  I'm researching
> 	why libc_r.so.6 linkage.

Hm, this is quite simular to NAKAJI's comment in
http://www.freebsd.org/cgi/query-pr.cgi?pr=99284
or
http://lists.freebsd.org/pipermail/freebsd-openoffice/2006-July/002512.html
------------------------------------------
What I did is,

1. updated to the latest ports-current with csup
2. removed /usr/lib/libc_r.*
3. used older gcc-ooo than the base system

I had reported my success story in ports/99284, in which the situation
is a little different.

1'. updated to the latest ports-current with csup
2'. removed /usr/lib/libc_r.*
3'. used *reinstalled gcc-ooo after the update of base system*

Now I'm trying the reinstall of gcc-ooo on my FreeBSD/pc98 box.
------------------------------------------

g++-ooo -Wl,-z,combreloc -Wl,-rpath,'$ORIGIN' -shared -Wl,-O1 -Wl,--version-script ../../../unxfbsdi.pro/misc/mozabdrv_mozabdrv2.map -L../../../unxfbsdi.pro/lib -L../lib -L/home/ports/editors/openoffice.org-2.0-devel/work/solenv/unxfbsdi/lib -L/home/ports/editors/openoffice.org-2.0-devel/work/solver/680/unxfbsdi.pro/lib -L/home/ports/editors/openoffice.org-2.0-devel/work/solenv/unxfbsdi/lib -L/usr/local/jdk1.5.0/lib -L/usr/local/jdk1.5.0/jre/lib/i386 -L/usr/local/jdk1.5.0/jre/lib/i386/client -L/usr/local/jdk1.5.0/jre/lib/i386/native_threads -L/usr/X11R6/lib ../../../unxfbsdi.pro/slo/MConfigAccess.o ../../../unxfbsdi.pro/slo/MCatalog.o ../../../unxfbsdi.pro/slo/MColumns.o ../../../unxfbsdi.pro/slo/MTable.o ../../../unxfbsdi.pro/slo/MTables.o ../../../unxfbsdi.pro/slo/MColumnAlias.o ../../../unxfbsdi.pro/slo/MPreparedStatement.o ../../../unxfbsdi.pro/slo/MStatement.o ../../../unxfbsdi.pro/slo/MResultSetMetaData.o ../../../unxfbsdi.pro/slo/MResultSet.o ../../../unxfbsdi.pro/slo!
 /MData!
 baseMetaData.o ../../../unxfbsdi.pro/slo/MConnection.o ../../../unxfbsdi.pro/slo/MNSInit.o ../../../unxfbsdi.pro/slo/MQueryHelper.o ../../../unxfbsdi.pro/slo/MDatabaseMetaDataHelper.o ../../../unxfbsdi.pro/slo/MQuery.o ../../../unxfbsdi.pro/slo/MTypeConverter.o ../../../unxfbsdi.pro/slo/MNameMapper.o ../../../unxfbsdi.pro/slo/MNSMozabProxy.o ../../../unxfbsdi.pro/slo/MNSTerminateListener.o ../../../unxfbsdi.pro/slo/MMozillaBootstrap.o ../../../unxfbsdi.pro/slo/MNSFolders.o ../../../unxfbsdi.pro/slo/MNSProfileDiscover.o ../../../unxfbsdi.pro/slo/MNSProfileManager.o ../../../unxfbsdi.pro/slo/MNSINIParser.o ../../../unxfbsdi.pro/slo/MNSRunnable.o ../../../unxfbsdi.pro/slo/MNSProfile.o ../../../unxfbsdi.pro/slo/MNSProfileDirServiceProvider.o ../../../unxfbsdi.pro/slo/mozabdrv2_version.o ../../../unxfbsdi.pro/slo/mozabdrv2_description.o -o ../../../unxfbsdi.pro/lib/libmozabdrv2.so -luno_cppu -luno_cppuhelpergcc3 -lvos3gcc3 -luno_sal -ldbtools680fi -lcomphelp4gcc3 -L/home/ports/e!
 ditors!
 /openoffice.org-2.0-devel/work/solver/680/unxfbsdi.pro/lib
 -lembed_base_s -lnspr4 -lmozreg_s -lxpcom -pthread -lm -Wl,-Bdynamic -lstlport_gcc
rm -f ../../../unxfbsdi.pro/lib/check_libmozabdrv2.so 
----------------------------------------------------------------
IMHO, libmozabdrv2.so is innocent and I suspect that libc_r is now obsoleted by
MFC or something...since symptom is very simular to 7-CURRENT. 
According to build log of mine,

making libmozabdrv2.so is using -pthread,
and no explict link against libc_r in build log.

thanks,
-- NAKATA, Maho (maho at FreeBSD.org)