Reapply patch lost during recent "blind import" of libtool

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

[This message contains a patch (actually one that has been in the gcc
 source tree for many months), but it is going to the gcc mailing list
 with the listed CCs instead of gcc-patches at Gerald Pfeifer's
 request since it discusses SOP.]

Back around 2000-11-22, the following patch was submitted to
libtool-patches and gcc-patches before being applied to the gcc source
tree.  It was approved by multiple gcc maintainers and, at least in
principle, our libtool liaison (as I was led to believe was the proper
method yet it was never applied to the libtool source tree):

	http://gcc.gnu.org/ml/libstdc++/2000-11/msg00225.html
	http://gcc.gnu.org/ml/libstdc++/2000-11/msg00340.html

During the recent libtool merge (2001-03-22), which was done using the
"blind import" method allowed by GCC steering committee SOP, it was lost.

The reapplication of this trivial patch to the gcc source tree has
been pre-approved by Gerald Pfeifer.  I will resubmit it to
libtool-patches under separate cover.  It was tested on both mainline
and 3.0 (it is a clear regression from 2.95.X) and is confined to
configure code which only affects *-*-freebsd*.

I want to be completely clear: I do not blame Alexandre Oliva, the
person that updated our copy of libtool, for this situation.  I may
not have stressed in my postings to libtool-patches that this patch
was approved for use in the gcc tree and that it should go in the
official libtool source tree.

However, I do blame our policy of allowing "blind imports" of external
tools to our CVS tree.  At the very least, we should be using CVS
vendor tags to properly roll in external updates.  This would at least
allow the importer to easily produce a report of local patches that
accumulated in the gcc tree that were just blown away by the upgrade.
And it would force people to reconsider how/why they were dropped from
the official distribution of the tool which gcc depends upon.  As it
stands, it took me a while to even understand that my port developed a
problem (I randomly noticed that libstdc++.so was no longer being
built and installed and that an old installed version was being used).

Regards,
Loren

2001-04-10  Loren J. Rittle  <ljrittle@acm.org>

	* ltcf-cxx.sh: Support creation of C++ shared libraries on
	recent versions of FreeBSD (release 3 or later).
	* ltconfig: On FreeBSD, -lc must not be provided when building
	a shared library or else the standard -pthread gcc option is
	rendered worthless to later users of the built library.

Index: ltconfig
===================================================================
RCS file: /cvs/gcc/egcs/ltconfig,v
retrieving revision 1.16
diff -c -r1.16 ltconfig
*** ltconfig	2001/03/22 06:48:31	1.16
--- ltconfig	2001/04/11 03:40:43
***************
*** 1108,1113 ****
--- 1108,1114 ----
      freebsd-elf*)
        library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so $libname.so'
        need_version=no
+       need_lc=no
        need_lib_prefix=no
        ;;
      freebsd-*)
Index: ltcf-cxx.sh
===================================================================
RCS file: /cvs/gcc/egcs/ltcf-cxx.sh,v
retrieving revision 1.14
diff -c -r1.14 ltcf-cxx.sh
*** ltcf-cxx.sh	2001/03/22 18:13:39	1.14
--- ltcf-cxx.sh	2001/04/11 03:40:43
***************
*** 233,242 ****
          ;;
      esac
      ;;
!   freebsd*)
!     # FreeBSD uses GNU C++ and GNU ld
!     # FIXME: insert proper C++ library support
      ld_shlibs=no
      ;;
    hpux*)
      hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
--- 233,246 ----
          ;;
      esac
      ;;
!   freebsd[12]*)
!     # C++ shared libraries reported to be fairly broken before switch to ELF
      ld_shlibs=no
+     ;;
+   freebsd*)
+     # FreeBSD 3 and later use GNU C++ and GNU ld with standard ELF
+     # conventions
+     ld_shlibs=yes
      ;;
    hpux*)
      hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'