| Message ID | mcrtyjyjgio.fsf@google.com |
|---|---|
| State | New |
| Headers | show |
* 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)], [...]
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
* 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
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
* 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
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
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 ;;