Patchwork libtool update for powerpc64le-linux

login
register
mail settings
Submitter Alan Modra
Date Aug. 23, 2013, 12:35 a.m.
Message ID <20130823003554.GX3430@bubble.grove.modra.org>
Download mbox | patch
Permalink /patch/269238/
State New
Headers show

Comments

Alan Modra - Aug. 23, 2013, 12:35 a.m.
On Fri, Aug 16, 2013 at 06:18:05PM +0930, Alan Modra wrote:
> I'd like to apply the following patch to the gcc repository (well,
> excluding the libgo part which I'm hoping someone will apply for me to
> the master go repository).  I know the normal procedure for autotools
> is to submit upstream then update when the patch is in the upstream
> autotools repository, but this simple libtool patch has been awaiting
> review for over two months.

The libtool.m4 patch has finally been reviewed and accepted upstream.

I'd like to import upstream libtool into gcc to support powerpc64le,
and please, can someone do the same for upstream libgo?  The reason we
need this patch is that on a powerpc64le linux host where the compiler
defaulted to producing 64-bit objects (which is how we generally build
compilers nowadays) libtool added -m elf64ppc to $LD.  Being the
option for 64-bit big-endian, that caused complete failure for
64-bit little-endian.

libjava is using a rather old version of libtool.  Importing doesn't
seem an option there, so for libjava patch acinclude.m4.  Please don't
ask me to modify libjava configure and makefiles to use current
libtool.  I tried, and failed.

 	* libtool.m4: Import upstream version.
libgo/
 	* config/libtool.m4: Import upstream version.
 	* libgo/configure: Regenerate.
libjava/libltdl/
 	* acinclude.m4 (_LT_ENABLE_LOCK <ld -m flags>): Remove non-canonical
	ppc host match.  Support little-endian powerpc linux hosts.
 	* configure: Regenerate.
gcc/
	* configure: Regenerate.
libobjc/
	* configure: Regenerate.
libgfortran/
	* configure: Regenerate.
libffi/
	* configure: Regenerate.
libssp/
	* configure: Regenerate.
libitm/
	* configure: Regenerate.
libgomp/
	* configure: Regenerate.
libquadmath/
	* configure: Regenerate.
libsanitizer/
	* configure: Regenerate.
zlib/
	* configure: Regenerate.
libstdc++-v3/
	* configure: Regenerate.
libmudflap/
	* configure: Regenerate.
boehm-gc/
	* configure: Regenerate.
lto-plugin/
	* configure: Regenerate.
libatomic/
	* configure: Regenerate.
libbacktrace/
	* configure: Regenerate.
libjava/
	* configure: Regenerate.
libjava/classpath/
	* configure: Regenerate.
Ian Lance Taylor - Aug. 23, 2013, 1:09 a.m.
On Thu, Aug 22, 2013 at 5:35 PM, Alan Modra <amodra@gmail.com> wrote:
> On Fri, Aug 16, 2013 at 06:18:05PM +0930, Alan Modra wrote:
>> I'd like to apply the following patch to the gcc repository (well,
>> excluding the libgo part which I'm hoping someone will apply for me to
>> the master go repository).  I know the normal procedure for autotools
>> is to submit upstream then update when the patch is in the upstream
>> autotools repository, but this simple libtool patch has been awaiting
>> review for over two months.
>
> The libtool.m4 patch has finally been reviewed and accepted upstream.
>
> I'd like to import upstream libtool into gcc to support powerpc64le,
> and please, can someone do the same for upstream libgo?  The reason we
> need this patch is that on a powerpc64le linux host where the compiler
> defaulted to producing 64-bit objects (which is how we generally build
> compilers nowadays) libtool added -m elf64ppc to $LD.  Being the
> option for 64-bit big-endian, that caused complete failure for
> 64-bit little-endian.

I've updated libgo/config/libtool.m4 and libgo/configure on mainline.

Ian
Alan Modra - Aug. 23, 2013, 10:15 a.m.
On Thu, Aug 22, 2013 at 06:09:40PM -0700, Ian Lance Taylor wrote:
> On Thu, Aug 22, 2013 at 5:35 PM, Alan Modra <amodra@gmail.com> wrote:
> > On Fri, Aug 16, 2013 at 06:18:05PM +0930, Alan Modra wrote:
> >> I'd like to apply the following patch to the gcc repository (well,
> >> excluding the libgo part which I'm hoping someone will apply for me to
> >> the master go repository).  I know the normal procedure for autotools
> >> is to submit upstream then update when the patch is in the upstream
> >> autotools repository, but this simple libtool patch has been awaiting
> >> review for over two months.
> >
> > The libtool.m4 patch has finally been reviewed and accepted upstream.
> >
> > I'd like to import upstream libtool into gcc to support powerpc64le,
> > and please, can someone do the same for upstream libgo?  The reason we
> > need this patch is that on a powerpc64le linux host where the compiler
> > defaulted to producing 64-bit objects (which is how we generally build
> > compilers nowadays) libtool added -m elf64ppc to $LD.  Being the
> > option for 64-bit big-endian, that caused complete failure for
> > 64-bit little-endian.
> 
> I've updated libgo/config/libtool.m4 and libgo/configure on mainline.

Thanks Ian, and I'm glad to see you patched libtool.m4 rather than
importing upstream.  Testing showed that importing libtool.m4 from
upstream isn't such a great idea.  For starters, we need to also import
a new ltmain.sh, and then I ran into build problems in libsanitizer.

libtool: compile: unable to infer tagged configuration
libtool:   error: specify a tag with '--tag'
make[4]: *** [tsan_rtl_amd64.lo] Error 1

After rather a lot of time digging into libtool, I think this is due
to a bad IFS init.  The function that emits the error, func_infer_tag
tries to see whether libtool is using $CC and fails because $CC has
trailing spaces and a calculated $CC_expanded has tabs between the
words of $CC.
Joseph S. Myers - Aug. 23, 2013, 10:08 p.m.
On Fri, 23 Aug 2013, Alan Modra wrote:

> I'd like to import upstream libtool into gcc to support powerpc64le,

Has the sysroot semantics issue been resolved in upstream libtool, or do 
you mean "import with 3334f7ed5851ef1e96b052f2984c4acdbf39e20c reverted"?
Alan Modra - Aug. 26, 2013, 3:45 a.m.
On Fri, Aug 23, 2013 at 10:08:29PM +0000, Joseph S. Myers wrote:
> On Fri, 23 Aug 2013, Alan Modra wrote:
> 
> > I'd like to import upstream libtool into gcc to support powerpc64le,
> 
> Has the sysroot semantics issue been resolved in upstream libtool, or do 
> you mean "import with 3334f7ed5851ef1e96b052f2984c4acdbf39e20c reverted"?

As far as I can tell, upstream libtool hasn't changed its sysroot
support since that patch went in.  I wasn't even aware of the issue..

How did the gcc project get to the place where we aren't following our
own rules http://gcc.gnu.org/codingconventions.html regarding libtool?
We're supposed to get a patch reviewed upstream, applied, then import
the whole lot.  From the top-level ChangeLog, that hasn't happened
since 2009-12-05!  It must be a little disheartening to be a libtool
maintainer, when a major GNU project like gcc treats your work like
this.

Patch

Index: libjava/libltdl/acinclude.m4
===================================================================
--- libjava/libltdl/acinclude.m4	(revision 200501)
+++ libjava/libltdl/acinclude.m4	(working copy)
@@ -519,7 +519,7 @@ 
   rm -rf conftest*
   ;;
 
-x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
+x86_64-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
   # Find out which ABI we are using.
   echo 'int i;' > conftest.$ac_ext
   if AC_TRY_EVAL(ac_compile); then
@@ -529,7 +529,10 @@ 
         x86_64-*linux*)
           LD="${LD-ld} -m elf_i386"
           ;;
-        ppc64-*linux*|powerpc64-*linux*)
+        powerpc64le-*linux*)
+          LD="${LD-ld} -m elf32lppclinux"
+          ;;
+        powerpc64-*linux*)
           LD="${LD-ld} -m elf32ppclinux"
           ;;
         s390x-*linux*)
@@ -545,7 +548,10 @@ 
         x86_64-*linux*)
           LD="${LD-ld} -m elf_x86_64"
           ;;
-        ppc*-*linux*|powerpc*-*linux*)
+        powerpcle-*linux*)
+          LD="${LD-ld} -m elf64lppc"
+          ;;
+        powerpc-*linux*)
           LD="${LD-ld} -m elf64ppc"
           ;;
         s390*-*linux*)