diff mbox

libtool.m4: remove (incorrect) handling of FreeBSD 1.x

Message ID 20110120184626.GD21455@gmx.de
State New
Headers show

Commit Message

Ralf Wildenhues Jan. 20, 2011, 6:46 p.m. UTC 
Hi Gerald,

* Gerald Pfeifer wrote on Thu, Jan 20, 2011 at 12:01:58AM CET:
> FreeBSD has been dead for way over a decade (FreeBSD 2.0 was released
> in 1994) and without support for dynamic linking and shared libraries
> I doubt there's a lot of software that would build at all.
> 
> In anycase, libtool's handling code to handle it is buggy and will soon 
> also match FreeBSD 10.0 and later which do support dynamic linking.

Good point.

> I think it's best to simplify libtool.m4 per the patch below.
> 
> I do not have libtool write access, so appreciate help.

I am committing it in your name to Libtool git master, as below,
including a NEWS update, and adding you to THANKS.  Note that you also
need to send a patch for toplevel config.rpath to upstream bug-gnulib.

> Let me know how to handle this for GCC, where this should go to HEAD,
> 4.5 and 4.4 at least.

If you are willing to do this, so I don't have to, that would be great!

After you change toplevel libtool.m4 in GCC (and src), you need to
ensure all affected configure scripts are rebuilt; running autoconf
in each directory containing a configure should suffice.  If you do
a full build of all languages and --enable-maintainer-mode, then an
incremental build should do as well, but the former is much faster
and more reliable.

With the 4.4 branch, I'm not totally sure whether all aclocal.m4 files
were already correct in m4_include'ing libtool.m4 instead of containing
copies of the libtool.m4 code; a quick check shows that not to be the
case, so above strategy should be safe.

You might need to look at libjava/{classpath,libltdl} separately.
Unless you send a patch to classpath, their next update might undo the
change (I'm not sure about this).

Hope that helps.

Cheers,
Ralf

2011-01-20  Gerald Pfeifer  <gerald@pfeifer.com>  (tiny change)

	Remove support for FreeBSD 1.x.
	* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)
	(_LT_SYS_DYNAMIC_LINKER): Remove handling of freebsd1* which
	soon would incorrectly match FreeBSD 10.0.
	* NEWS, THANKS: Update.
diff mbox

Patch

diff --git a/NEWS b/NEWS
index 39eb771..dbad2ae 100644
--- a/NEWS
+++ b/NEWS
@@ -28,6 +28,7 @@  New in 2.4.2 2011-??-??: git version 2.4.1a, Libtool team:
 * Changes in supported systems or compilers:
 
   - Fixes for gfortran on Darwin, XL Fortran on GNU/Linux.
+  - Support for FreeBSD 1.x (outdated since 1994) has been removed.
 
 New in 2.4 2010-09-22: git version 2.2.11a, Libtool team:
 
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index ba2d5e4..033c9a0 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2455,10 +2455,6 @@  dgux*)
   shlibpath_var=LD_LIBRARY_PATH
   ;;
 
-freebsd1*)
-  dynamic_linker=no
-  ;;
-
 freebsd* | dragonfly*)
   # DragonFly does not have aout.  When/if they implement a new
   # versioning mechanism, adjust this.
@@ -5178,10 +5174,6 @@  _LT_EOF
       _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
       ;;
 
-    freebsd1*)
-      _LT_TAGVAR(ld_shlibs, $1)=no
-      ;;
-
     # FreeBSD 2.2.[012] allows us to include c++rt0.o to get C++ constructor
     # support.  Future versions do this automatically, but an explicit c++rt0.o
     # does not break anything, and helps significantly (at the cost of a little