Patchwork PATCH RFA: build machinery: Add Go support to libtool

login
register
mail settings
Submitter Ian Taylor
Date Nov. 3, 2010, 8:31 p.m.
Message ID <mcrtyjyjgio.fsf@google.com>
Download mbox | patch
Permalink /patch/70069/
State New
Headers show

Comments

Ian Taylor - Nov. 3, 2010, 8:31 p.m.
This patch, similar to the one I just sent for config/go.m4, adds Go
support to libtool.  This is not used by anything at present, but will
be used by libgo when it is committed.  I have proposed a similar patch
to the libtool maintainers.  When gcc includes a version of libtool with
support for Go, this patch can go away.

Bootstrapped on x86_64-unknown-linux-gnu.  OK for mainline?

Ian
Ralf Wildenhues - Nov. 11, 2010, 6:41 a.m.
* Ian Lance Taylor wrote on Wed, Nov 03, 2010 at 09:31:27PM CET:
> This patch, similar to the one I just sent for config/go.m4, adds Go
> support to libtool.  This is not used by anything at present, but will
> be used by libgo when it is committed.  I have proposed a similar patch
> to the libtool maintainers.  When gcc includes a version of libtool with
> support for Go, this patch can go away.
> 
> Bootstrapped on x86_64-unknown-linux-gnu.  OK for mainline?

This patch is lacking a ChangeLog entry.

Did you ensure that none of the configure scripts (nor aclocal.m4 files)
in mainline change when the patch is applied (even when
--enable-maintainer-mode is used)?

This patch makes Libtool machinery go out of sync with upstream, which
is against the GCC commit rules.  I'm basically just waiting for
Autoconf to commit before pushing the Libtool patch, however.

This also means that when we update Libtool in GCC, we'd need to switch
to a git version again then.  But probably that's unavoidable anyway due
to fixes needed for --with-sysroot support in Libtool (Paolo?).

Thanks,
Ralf

> Index: libtool.m4
> ===================================================================
> --- libtool.m4	(revision 166249)
> +++ libtool.m4	(working copy)
> @@ -799,6 +799,7 @@ AC_DEFUN([LT_LANG],
>  m4_case([$1],
>    [C],			[_LT_LANG(C)],
>    [C++],		[_LT_LANG(CXX)],
> +  [Go],			[_LT_LANG(GO)],
>    [Java],		[_LT_LANG(GCJ)],
>    [Fortran 77],		[_LT_LANG(F77)],
>    [Fortran],		[_LT_LANG(FC)],
[...]
Paolo Bonzini - Nov. 11, 2010, 8:30 a.m.
On 11/11/2010 07:41 AM, Ralf Wildenhues wrote:
> This patch makes Libtool machinery go out of sync with upstream, which
> is against the GCC commit rules.  I'm basically just waiting for
> Autoconf to commit before pushing the Libtool patch, however.

That's okay.

> This also means that when we update Libtool in GCC, we'd need to switch
> to a git version again then.  But probably that's unavoidable anyway due
> to fixes needed for --with-sysroot support in Libtool (Paolo?).

Yes.

Paolo
Ralf Wildenhues - Nov. 11, 2010, 8:02 p.m.
* Ian Lance Taylor wrote on Wed, Nov 03, 2010 at 09:31:27PM CET:
> This patch, similar to the one I just sent for config/go.m4, adds Go
> support to libtool.  This is not used by anything at present, but will
> be used by libgo when it is committed.  I have proposed a similar patch
> to the libtool maintainers.  When gcc includes a version of libtool with
> support for Go, this patch can go away.
> 
> Bootstrapped on x86_64-unknown-linux-gnu.  OK for mainline?

Hmm, I found an issue with this now:

> --- libtool.m4	(revision 166249)
> +++ libtool.m4	(working copy)

> @@ -850,6 +851,10 @@ AC_PROVIDE_IFELSE([AC_PROG_GCJ],
>         m4_ifdef([LT_PROG_GCJ],
>  	[m4_define([LT_PROG_GCJ], defn([LT_PROG_GCJ])[LT_LANG(GCJ)])])])])])
>  
> +AC_PROVIDE_IFELSE([AC_PROG_GO],
> +  [LT_LANG(GO)],
> +  [m4_define([AC_PROG_GO], defn([AC_PROG_GO])[LT_LANG(GO)])])
> +

The AC_PROVIDE_IFELSE call should be wrapped in
  m4_ifdef([AC_PROG_GO],
  [ ...
  ])

so that autoconf won't complain about undefined AC_PROG_GO in cases
where the configure.ac won't call AC_PROG_GO and thus aclocal won't pull
in go.m4.  This is needed for old Autoconf versions only.

>  AC_PROVIDE_IFELSE([LT_PROG_RC],
>    [LT_LANG(RC)],
>    [m4_define([LT_PROG_RC], defn([LT_PROG_RC])[LT_LANG(RC)])])

With that, things seem to work.

Cheers,
Ralf
Ian Taylor - Nov. 12, 2010, 12:26 a.m.
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

> * Ian Lance Taylor wrote on Wed, Nov 03, 2010 at 09:31:27PM CET:
>> This patch, similar to the one I just sent for config/go.m4, adds Go
>> support to libtool.  This is not used by anything at present, but will
>> be used by libgo when it is committed.  I have proposed a similar patch
>> to the libtool maintainers.  When gcc includes a version of libtool with
>> support for Go, this patch can go away.
>> 
>> Bootstrapped on x86_64-unknown-linux-gnu.  OK for mainline?
>
> This patch is lacking a ChangeLog entry.
>
> Did you ensure that none of the configure scripts (nor aclocal.m4 files)
> in mainline change when the patch is applied (even when
> --enable-maintainer-mode is used)?

Good point.  It does change them.  It adds

m4_include([../config/go.m4])

to acinclude.m4 and adds the corresponding code to configure.

This makes me think that I am on the wrong path here.  I think I will
try to move this change and go.m4 into libgo itself, and then just fix
up libgo when gcc moves to sufficiently new versions of autoconf and
libtool.  That will confine the version skew issues to a single
directory.

Ian
Ralf Wildenhues - Nov. 12, 2010, 6:42 p.m.
* Ian Lance Taylor wrote on Fri, Nov 12, 2010 at 01:26:45AM CET:
> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> > * Ian Lance Taylor wrote on Wed, Nov 03, 2010 at 09:31:27PM CET:
> >> This patch, similar to the one I just sent for config/go.m4, adds Go
> >> support to libtool.  This is not used by anything at present, but will
> >> be used by libgo when it is committed.  I have proposed a similar patch
> >> to the libtool maintainers.  When gcc includes a version of libtool with
> >> support for Go, this patch can go away.
> >> 
> >> Bootstrapped on x86_64-unknown-linux-gnu.  OK for mainline?
> >
> > This patch is lacking a ChangeLog entry.
> >
> > Did you ensure that none of the configure scripts (nor aclocal.m4 files)
> > in mainline change when the patch is applied (even when
> > --enable-maintainer-mode is used)?
> 
> Good point.  It does change them.  It adds
> 
> m4_include([../config/go.m4])
> 
> to acinclude.m4 and adds the corresponding code to configure.

Hmm.  Running aclocal with the right options plus --verbose can help
spot which code dragged in the go.m4 file.  You can use 'autoreconf -v
-v' to get the right flags.

> This makes me think that I am on the wrong path here.  I think I will
> try to move this change and go.m4 into libgo itself, and then just fix
> up libgo when gcc moves to sufficiently new versions of autoconf and
> libtool.  That will confine the version skew issues to a single
> directory.

That is a viable alternative, of course.

Cheers,
Ralf
Ian Taylor - Nov. 12, 2010, 9:02 p.m.
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

> * Ian Lance Taylor wrote on Fri, Nov 12, 2010 at 01:26:45AM CET:
>> This makes me think that I am on the wrong path here.  I think I will
>> try to move this change and go.m4 into libgo itself, and then just fix
>> up libgo when gcc moves to sufficiently new versions of autoconf and
>> libtool.  That will confine the version skew issues to a single
>> directory.
>
> That is a viable alternative, of course.

I've decided to go that way, so I'm withdrawing this patch.  Thanks for
looking at it.

Ian

Patch

Index: libtool.m4
===================================================================
--- libtool.m4	(revision 166249)
+++ libtool.m4	(working copy)
@@ -799,6 +799,7 @@  AC_DEFUN([LT_LANG],
 m4_case([$1],
   [C],			[_LT_LANG(C)],
   [C++],		[_LT_LANG(CXX)],
+  [Go],			[_LT_LANG(GO)],
   [Java],		[_LT_LANG(GCJ)],
   [Fortran 77],		[_LT_LANG(F77)],
   [Fortran],		[_LT_LANG(FC)],
@@ -850,6 +851,10 @@  AC_PROVIDE_IFELSE([AC_PROG_GCJ],
        m4_ifdef([LT_PROG_GCJ],
 	[m4_define([LT_PROG_GCJ], defn([LT_PROG_GCJ])[LT_LANG(GCJ)])])])])])
 
+AC_PROVIDE_IFELSE([AC_PROG_GO],
+  [LT_LANG(GO)],
+  [m4_define([AC_PROG_GO], defn([AC_PROG_GO])[LT_LANG(GO)])])
+
 AC_PROVIDE_IFELSE([LT_PROG_RC],
   [LT_LANG(RC)],
   [m4_define([LT_PROG_RC], defn([LT_PROG_RC])[LT_LANG(RC)])])
@@ -6495,6 +6500,10 @@  public class foo {
   }
 };
 _LT_EOF
+], [$1], [GO], [cat > conftest.$ac_ext <<_LT_EOF
+package foo
+func foo() { }
+_LT_EOF
 ])
 dnl Parse the compiler output and extract the necessary
 dnl objects, libraries and library flags.
@@ -6988,6 +6997,71 @@  GCC=$lt_save_GCC
 CC="$lt_save_CC"
 ])# _LT_LANG_GCJ_CONFIG
 
+# _LT_LANG_GO_CONFIG([TAG])
+# --------------------------
+# Ensure that the configuration variables for the GNU Go compiler
+# are suitably defined.  These variables are subsequently used by _LT_CONFIG
+# to write the compiler configuration to `libtool'.
+m4_defun([_LT_LANG_GO_CONFIG],
+[AC_REQUIRE([LT_PROG_GO])dnl
+AC_LANG_SAVE
+
+# Source file extension for Go test sources.
+ac_ext=go
+
+# Object file extension for compiled Go test sources.
+objext=o
+_LT_TAGVAR(objext, $1)=$objext
+
+# Code to be used in simple compile tests
+lt_simple_compile_test_code="package main; func main() { }"
+
+# Code to be used in simple link tests
+lt_simple_link_test_code='package main; func main() { }'
+
+# ltmain only uses $CC for tagged configurations so make sure $CC is set.
+_LT_TAG_COMPILER
+
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE
+_LT_LINKER_BOILERPLATE
+
+# Allow CC to be a program name with arguments.
+lt_save_CC="$CC"
+lt_save_GCC="$GCC"
+GCC=yes
+CC=${GOC-"gccgo"}
+compiler=$CC
+_LT_TAGVAR(compiler, $1)=$CC
+_LT_TAGVAR(LD, $1)="$LD"
+_LT_CC_BASENAME([$compiler])
+
+# Go did not exist at the time GCC didn't implicitly link libc in.
+_LT_TAGVAR(archive_cmds_need_lc, $1)=no
+
+_LT_TAGVAR(old_archive_cmds, $1)=$old_archive_cmds
+
+## CAVEAT EMPTOR:
+## There is no encapsulation within the following macros, do not change
+## the running order or otherwise move them around unless you know exactly
+## what you are doing...
+if test -n "$compiler"; then
+  _LT_COMPILER_NO_RTTI($1)
+  _LT_COMPILER_PIC($1)
+  _LT_COMPILER_C_O($1)
+  _LT_COMPILER_FILE_LOCKS($1)
+  _LT_LINKER_SHLIBS($1)
+  _LT_LINKER_HARDCODE_LIBPATH($1)
+
+  _LT_CONFIG($1)
+fi
+
+AC_LANG_RESTORE
+
+GCC=$lt_save_GCC
+CC="$lt_save_CC"
+])# _LT_LANG_GO_CONFIG
+
 
 # _LT_LANG_RC_CONFIG([TAG])
 # -------------------------
@@ -7054,6 +7128,11 @@  AU_ALIAS([LT_AC_PROG_GCJ], [LT_PROG_GCJ]
 dnl aclocal-1.4 backwards compatibility:
 dnl AC_DEFUN([LT_AC_PROG_GCJ], [])
 
+# LT_PROG_GO
+# -----------
+AC_DEFUN([LT_PROG_GO],
+[AC_CHECK_TOOL(GOC, gccgo,)
+])
 
 # LT_PROG_RC
 # ----------
Index: ltmain.sh
===================================================================
--- ltmain.sh	(revision 166249)
+++ ltmain.sh	(working copy)
@@ -1390,7 +1390,7 @@  func_mode_compile ()
     *.[cCFSifmso] | \
     *.ada | *.adb | *.ads | *.asm | \
     *.c++ | *.cc | *.ii | *.class | *.cpp | *.cxx | \
-    *.[fF][09]? | *.for | *.java | *.obj | *.sx | *.cu | *.cup)
+    *.[fF][09]? | *.for | *.java | *.go | *.obj | *.sx | *.cu | *.cup)
       func_xform "$libobj"
       libobj=$func_xform_result
       ;;