Re: [PATCH] Add Bitrig support

2013-01-02 Thread Brad Smith
On Wed, Jan 02, 2013 at 01:31:15AM +0700, Gary V. Vaughan wrote:
> Hi Brad,
> 
> On 29 Dec 2012, at 08:50, Brad Smith  wrote:
> > On Tue, Aug 21, 2012 at 11:50:21PM -0400, Brad Smith wrote:
> >> The following diff adds support for Bitrig, which is a
> >> fork of OpenBSD.
> > 
> > ping.
> 
> Thanks for the patch, and sorry for the delay in reviewing it.
> 
> The patch content looks innocuous enough to me, and I'd like to commit
> it to master... but first, would you mind regenerating agaist current
> git master (ltmain.m4sh does not exist any more!), and also writing a
> commit log entry suitable for inclusion in the generated ChangeLog
> file at release time?

How about the following?


2013-01-02  Brad Smith  

* NEWS, build-aux/ltmain.in, m4/libtool.m4, m4/ltdl.m4,
tests/deplibs-ident.at [bitrig]: Add support for Bitrig.


diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 7201f6c..573dfbe 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -5031,7 +5031,7 @@ func_mode_link ()
# These systems don't actually have a C library (as such)
test X-lc = "X$arg" && continue
;;
- *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*)
+ *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-bitrig*)
# Do not include libc due to us having libc/libc_r.
test X-lc = "X$arg" && continue
;;
@@ -7061,7 +7061,7 @@ func_mode_link ()
  *-*-netbsd*)
# Don't link with libc until the a.out ld.so is fixed.
;;
- *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*)
+ *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-bitrig*)
# Do not include libc due to us having libc/libc_r.
;;
  *-*-sco3.2v5* | *-*-sco5v6*)
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 7255906..60f56d8 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1472,7 +1472,7 @@ old_postuninstall_cmds=
 
 if test -n "$RANLIB"; then
   case $host_os in
-  openbsd*)
+  openbsd* | bitrig*)
 old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$tool_oldlib"
 ;;
   *)
@@ -1640,7 +1640,7 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [dnl
 lt_cv_sys_max_cmd_len=8192;
 ;;
 
-  netbsd* | freebsd* | openbsd* | darwin* | dragonfly*)
+  netbsd* | freebsd* | openbsd* | darwin* | dragonfly* | bitrig*)
 # This has been around since 386BSD, at least.  Likely further.
 if test -x /sbin/sysctl; then
   lt_cv_sys_max_cmd_len=`/sbin/sysctl -n kern.argmax`
@@ -2713,7 +2713,7 @@ newsos6)
   dynamic_linker='ldqnx.so'
   ;;
 
-openbsd*)
+openbsd* | bitrig*)
   version_type=sunos
   sys_lib_dlsearch_path_spec=/usr/lib
   need_lib_prefix=no
@@ -3283,7 +3283,7 @@ newos6*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
-openbsd*)
+openbsd* | bitrig*)
   if test -z "`echo __ELF__ | $CC -E - | $GREP __ELF__`"; then
 lt_cv_deplibs_check_method='match_pattern 
/lib[[^/]]+(\.so\.[[0-9]]+\.[[0-9]]+|\.so|_pic\.a)$'
   else
@@ -4666,7 +4666,7 @@ dnl Note also adjust exclude_expsyms for C++ above.
 # we just hope/assume this is gcc and not c89 (= MSVC++)
 with_gnu_ld=yes
 ;;
-  openbsd*)
+  openbsd* | bitrig*)
 with_gnu_ld=no
 ;;
   esac
@@ -5395,7 +5395,7 @@ _LT_EOF
 *nto* | *qnx*)
   ;;
 
-openbsd*)
+openbsd* | bitrig*)
   if test -f /usr/libexec/ld.so; then
_LT_TAGVAR(hardcode_direct, $1)=yes
_LT_TAGVAR(hardcode_shlibpath_var, $1)=no
@@ -6587,7 +6587,7 @@ if test yes != "$_lt_caught_CXX_error"; then
 _LT_TAGVAR(ld_shlibs, $1)=yes
;;
 
-  openbsd*)
+  openbsd* | bitrig*)
if test -f /usr/libexec/ld.so; then
  _LT_TAGVAR(hardcode_direct, $1)=yes
  _LT_TAGVAR(hardcode_shlibpath_var, $1)=no
diff --git a/m4/ltdl.m4 b/m4/ltdl.m4
index 5750f15..a22e032 100644
--- a/m4/ltdl.m4
+++ b/m4/ltdl.m4
@@ -496,7 +496,7 @@ AC_CACHE_CHECK([whether deplibs are loaded by dlopen],
   netbsd*)
 lt_cv_sys_dlopen_deplibs=yes
 ;;
-  openbsd*)
+  openbsd* | bitrig*)
 lt_cv_sys_dlopen_deplibs=yes
 ;;
   osf[[1234]]*)
diff --git a/tests/deplibs-ident.at b/tests/deplibs-ident.at
index fc1ff0c..8c49551 100644
--- a/tests/deplibs-ident.at
+++ b/tests/deplibs-ident.at
@@ -68,7 +68,7 @@ int main() { return a1() + a2() + a3() + c(); }
   [0],[stdout],[ignore])
   AT_CHECK([$EGREP 'cee.*cee' stdout], 1, [ignore], [ignore])
   AT_XFAIL_IF([case $host in
- *-*-aix*|hppa*-*-hpux*|*-*-interix*|*-*-openbsd*) false;;
+ *-*-aix*|hppa*-*-hpux*|*-*-interix*|*-*-openbsd*|*-*-bitrig*) 
false;;
  *):;;
esac])
   dnl This is currently broken in libtool
diff --git a/NEWS b/NEWS
index 8e4278e..adda1d4 100644
--- a/NEWS
+++ b/NEWS
@@ -34,6 +34,10 @@ NEWS - list of user-visible changes between releases of GNU 
Libtool
 
 make check-local TESTSUITEFLAGS='-k "!expensive"'
 
+* Changes in supported systems or compilers:
+
+  - Support for Bitrig.
+

Re: [PATCH] Add Bitrig support

2013-01-02 Thread Gary V. Vaughan
Hi Brad,

On 2 Jan 2013, at 15:17, Brad Smith  wrote:
> On Wed, Jan 02, 2013 at 01:31:15AM +0700, Gary V. Vaughan wrote:
>> The patch content looks innocuous enough to me, and I'd like to commit
>> it to master... but first, would you mind regenerating agaist current
>> git master (ltmain.m4sh does not exist any more!), and also writing a
>> commit log entry suitable for inclusion in the generated ChangeLog
>> file at release time?
> 
> How about the following?
> [[patch content snipped]]

Thanks, yes that's much easier to apply.

I took the liberty of editing the patched code very lightly to maintain
alphabetical ordering where possible, and your tweaking your NEWS and
ChangeLog entries to match existing style.  The git commit hook will post
that version to libtool-com...@gnu.org presently so you can compare.

Please let me know if I broke anything during editing.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)



Re: [PATCH] Add Bitrig support

2013-01-02 Thread Brad Smith
On Thu, Jan 03, 2013 at 02:31:25PM +0700, Gary V. Vaughan wrote:
> Hi Brad,
> 
> On 2 Jan 2013, at 15:17, Brad Smith  wrote:
> > On Wed, Jan 02, 2013 at 01:31:15AM +0700, Gary V. Vaughan wrote:
> >> The patch content looks innocuous enough to me, and I'd like to commit
> >> it to master... but first, would you mind regenerating agaist current
> >> git master (ltmain.m4sh does not exist any more!), and also writing a
> >> commit log entry suitable for inclusion in the generated ChangeLog
> >> file at release time?
> > 
> > How about the following?
> > [[patch content snipped]]
> 
> Thanks, yes that's much easier to apply.
> 
> I took the liberty of editing the patched code very lightly to maintain
> alphabetical ordering where possible, and your tweaking your NEWS and
> ChangeLog entries to match existing style.  The git commit hook will post
> that version to libtool-com...@gnu.org presently so you can compare.
> 
> Please let me know if I broke anything during editing.

Ok, I will do. Thanks.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.