| Message ID | 20130823003554.GX3430@bubble.grove.modra.org |
|---|---|
| State | New |
| Headers | show |
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
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.
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"?
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.
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*)