Re: [PING, Makefile] improve libsubdir variable transmission to sub-makes (for Windows)

Hi Oliver, On 09/11/2017 04:30 PM, Olivier Hainque wrote: > Hello, > > Ping for https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00017.html > >> Makefile.in: >> ... >> export libsubdir >> >> This is not working well on cygwin environments where environment >> variable names are translated to

Re: [PATCH] Real fix for AIX exception handling

able referenced when it was bound by collect2 > and the application uses the one created when the executable is > created -- the libgcc_eh.a solution doesn't work. Again, the question > is why this apparently functioned correctly for GCC.4.8. > > There was a change to constructo

[PATCH] Real fix for AIX exception handling

AIX) ld, rather than leaving this to each build system? Thanks! /haubi/ >From 32ca0e6f7bf8d096cc653ac455d66c270b75fdf0 Mon Sep 17 00:00:00 2001 From: Michael Haubenwallner Date: Wed, 2 Mar 2016 15:06:48 +0100 Subject: [PATCH 1/4] AIX: Stop exporting more _GLOBAL__ symbols. * m4/libtool.m4 (_LT_

Re: libgcc: On AIX, increase chances to find landing pads for exceptions

Hi David, On 02/10/2016 10:52 AM, Michael Haubenwallner wrote: >> There are two remaining issues: >> >> 1) FDEs with overlapping ranges causing problems with exceptions. I'm >> not sure of the best way to work around this. Your patch is one >> possible soluti

Re: libgcc: On AIX, increase chances to find landing pads for exceptions

On 02/10/2016 02:27 PM, David Edelsohn wrote: > On Wed, Feb 10, 2016 at 1:52 AM, Michael Haubenwallner > wrote: >> >> On 02/08/2016 02:59 PM, David Edelsohn wrote: >>> Runtime linking is disabled by default on AIX, and I disabled it for >>> libstdc++.

Re: libgcc: On AIX, increase chances to find landing pads for exceptions

cit -bexport:file only to the AIX linker? /haubi/ > > Thanks, David > > > On Mon, Feb 8, 2016 at 7:14 AM, Michael Haubenwallner > wrote: >> Hi David, >> >> still experiencing exception-not-caught problems with gcc-4.2.4 on AIX >> leads me to some patch pr

libgcc: On AIX, increase chances to find landing pads for exceptions

ppen. Thoughts? Thanks! /haubi/ 2016-02-08 Michael Haubenwallner On AIX, increase chances to find landing pads for exceptions. * unwind-dw2-fde.c (_Unwind_Find_FDE): Stop assuming registered object's address ranges to not overlap. --- libgcc/unwind-dw2-fde.c +++ libgcc/unwind-

Re: [PATCH, committed] libstdc++-v3/fragment.am (AM_CPPFLAGS): Add CPPFLAGS

On 07/07/2015 04:48 PM, Michael Haubenwallner wrote: > Hi build machinery maintainers, > > when the host system does not have the iconv-devel package installed, > but the target-prefix does contain iconv.h, in libstdc++/include the > creation of the precompiled headers fails w

[PATCH] libstdc++-v3/fragment.am (AM_CPPFLAGS): Add CPPFLAGS

I$target_prefix/include" and adds this to CPPFLAGS, the Makefiles do not transfer CPPFLAGS to the compiler commandline. Attached patch adds CPPFLAGS to AM_CPPFLAGS in libstdc++/fragment.am. Thanks! /haubi/ 2015-07-07 Michael Haubenwallner * fragment.am (AM_CPPFLAGS): Add CPPFLAGS. * Mak

Re: [PATCH] top-level for libvtv: use normal (not raw_cxx) target exports

On 06/30/2015 02:54 PM, Jonathan Wakely wrote: > On 29/06/15 18:57 +0200, Michael Haubenwallner wrote: >> Actually, an unexpected libstdc++-v3/configure change is introduced by some >> inconsistency in >> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=223

Re: [PATCH] top-level for libvtv: use normal (not raw_cxx) target exports

On 06/25/2015 09:15 PM, Jeff Law wrote: > On 06/09/2015 08:22 AM, Michael Haubenwallner wrote: >> Hi build machinery maintainers, >> >> since we always build the C++ compiler now, I fail to see the need to still >> use RAW_CXX_TARGET_EXPORTS for libvtv. > But why i

Re: [PATCH] top-level for libvtv: use normal (not raw_cxx) target exports

On 06/19/2015 11:36 AM, Paolo Bonzini wrote: > On 09/06/2015 16:22, Michael Haubenwallner wrote: >> Hi build machinery maintainers, >> >> since we always build the C++ compiler now, I fail to see the need to still >> use RAW_CXX_TARGET_EXPORTS for libvtv. >> >&

[PATCH] top-level for libvtv: use normal (not raw_cxx) target exports

all: * --enable-multilib: Without this, the "user friendly check" is breaking, since https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=205975 * --with-system-zlib: Without this, --enable-multilib tries to build a 32-bit zlib with "CC=/build/32/./prev-gcc/xgcc" Th

Re: [patch 0/27] RFC: Use automake-1.11.6 across the tree

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? > When installing automake-1.11.6 into some dedicated location, there's one regression compared to 1.11.1: $ ./configure --prefix=/prefix/of/a

Re: [patch 26/29] libstdc++-v3: Use automake-1.11.6 (across the tree)

On 05/13/2015 12:27 PM, Jonathan Wakely wrote: > On 06/05/15 12:21 +0200, Michael Haubenwallner wrote: >> Patch for libstdc++-v3. > > The libstd++ parts are OK. > > N.B. libstdc++ patches should be sent to the libstdc++ list (which > saves you CCing individual maint

[committed] [patch 0/27] Use automake-1.11.6 across the tree

On 05/05/2015 06:03 PM, Michael Haubenwallner wrote: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 08:42 PM, Jan-Benedict

Re: [patch 1/28] top-level: Use automake-1.11.6

On 05/12/2015 10:45 AM, Michael Haubenwallner wrote: > On 05/11/2015 07:55 PM, Joseph Myers wrote: >> On Sat, 9 May 2015, Bernd Edlinger wrote: >> >>> But maybe you would like it better if we update, for instance, to: >>> automake-1.14 _and_ autoconf-2.69 ? &

Re: [patch 1/28] top-level: Use automake-1.11.6

On 05/11/2015 07:55 PM, Joseph Myers wrote: > On Sat, 9 May 2015, Bernd Edlinger wrote: > >> But maybe you would like it better if we update, for instance, to: >> automake-1.14 _and_ autoconf-2.69 ? > > Updating to current automake and autoconf release versions (but still > using git versions

Re: [patch 0/27] RFC: Use automake-1.11.6 across the tree

On 05/08/2015 01:22 PM, Bernd Edlinger wrote: > On Thu, 7 May 2015 18:52:52, Michael Haubenwallner wrote: >> On 05/06/2015 03:01 PM, Bernd Edlinger wrote: >>> On Tue, 5 May 2015 18:03:15, Michael Haubenwallner wrote: >>>> >>>> Now that gcc-5 is out, what

Re: [patch 3/28] fixincludes: Use automake-1.11.6 (across the tree)

On 05/08/2015 12:10 AM, Bruce Korb wrote: > On 05/06/15 01:58, Michael Haubenwallner wrote: >> Trivial patch for fixincludes. > > A) sufficiently trivial that explicit permission ought not be required Agreed for the actual code change - more important is to notify the automake

Re: [patch 0/27] RFC: Use automake-1.11.6 across the tree

Hi Bernd, On 05/06/2015 03:01 PM, Bernd Edlinger wrote: > On Tue, 5 May 2015 18:03:15, Michael Haubenwallner wrote: >> >> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? >> >> BTW, the actual commands I use to re-run automake for everything (I

Re: [patch 0/29] RFC: Use automake-1.11.6 across the tree

On 05/06/2015 04:09 PM, Jeff Law wrote: > On 05/05/2015 10:03 AM, Michael Haubenwallner wrote: >> Hello build machinery maintainers, >> >> following up >> http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 >> http://thread.gmane.org/gmane.comp.g

Re: [patch 0/29] RFC: Use automake-1.11.6 across the tree

On 05/06/2015 03:01 PM, Bernd Edlinger wrote: > Hi, > > On Tue, 5 May 2015 18:03:15, Michael Haubenwallner wrote: >> >> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? >> >> BTW, the actual commands I use to re-run automake for everyth

Re: [patch 22/29] liboffloadmic: Use automake-1.11.6

of course I forgot one to attach... Am 2015-05-06 um 12:13 schrieb Michael Haubenwallner: > > Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: >> Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? > > Patch for liboffloadmic. > 2015-05-06

[patch 29/29] zlib: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for zlib. 2015-05-06 Michael Haubenwallner * Makefile.in: Regenerated with automake-1.11.6. * aclocal.m4: Likewise. * configure: Likewise. Index: z

[patch 28/29] lto-plugin: Use automake-1.11.6 (across the tree)

Patch for lto-plugin. Removing "by automake version number" from Makefile.am to avoid false positives when hunting for "by automake 1.11.[^6]". Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following

[patch 27/29] libvtv: Use automake-1.11.6 (across the tree)

Patch for libvtv, also recreated (apparently) unused testsuite/other-tests/Makefile.in Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://t

[patch 26/29] libstdc++-v3: Use automake-1.11.6 (across the tree)

Patch for libstdc++-v3. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/

[patch 25/29] libssp: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libssp. 2015-05-06 Michael Haubenwallner * Makefile.in: Regenerated with automake-1.11.6. * aclocal.m4: Likewise. * configure: Likewise. Index: lib

[patch 24/29] libsanitizer: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libsanitizer. 2015-05-06 Michael Haubenwallner * Makefile.in: Regenerated with automake-1.11.6. * aclocal.m4: Likewise. * asan/Makefile.in: Likew

[patch 23/29] libquadmath: Use automake-1.11.6 (across the tree)

Patch for libquadmath. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/

[patch 18/29] libltdl Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libjava/libltdl, need to gzip for recipients gcc.gnu.org. libjava.libltdl.patch.gz Description: application/gzip

[patch 22/29] liboffloadmic: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for liboffloadmic.

[patch 21/29] libobjc: Use automake-1.11.6 (across the tree)

Patch for libobjc. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 0

[patch 20/29] libmpx: Use automake-1.11.6 (across the tree)

Patch for libmpx. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 0

[patch 19/29] libjava: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libjava, without classpath and libltdl. 2015-05-06 Michael Haubenwallner * Makefile.in: Regenerated with automake-1.11.6. * aclocal.m4: Likew

[patch 16/28] libitm: Use automake-1.11.6 (across the tree)

Patch for libitm. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 0

[patch 15/28] libgo: Use automake-1.11.6 (across the tree)

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libgo. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. aclocal.m4: Recreate. configure: Recreate. testsuite/Makefile

[patch 14/28] libgomp: Use automake-1.11.6 (across the tree)

Patch for libgomp. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 0

[patch 13/28] libgfortran: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libgfortran. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. Index: libgfortran/Makefile

[patch 12/28] libffi: Use automake-1.11.6 (across the tree)

Patch for libffi. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 0

[patch 11/28] libdecnumber: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Trivial patch for libdecnumber. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. aclocal.m4: Recreate. Index: libdecnumber/aclocal

[patch 10/28] libcpp: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Trivial patch for libcpp. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. aclocal.m4: Recreate. Index: libcpp/aclocal

[patch 9/28] libcilkrts: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libcilkrts. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. aclocal.m4: Recreate. configure: Recreate. Index: libcilk

[patch 8/28] libcc1: Use automake-1.11.6 (across the tree)

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libcc1. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. aclocal.m4: Recreate. configure: Recreate. Index: lib

[patch 7/28] libbacktrace: Use automake-1.11.6 (across the tree)

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libbacktrace. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. aclocal.m4: Recreate. configure: Recreate. In

[patch 6/28] libatomic: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for libatomic. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. Index: libatomic/Makefile

Re: [patch 0/27] RFC: Use automake-1.11.6 across the tree

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Trivial patch for intl. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. aclocal.m4: Recreate. Index: intl/aclocal

[patch 4/28] gotools: Use automake-1.11.6 (across the tree)

Patch for gotools. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/25/2015 0

[patch 3/28] fixincludes: Use automake-1.11.6 (across the tree)

Trivial patch for fixincludes. Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Hello build machinery maintainers, > > following up > http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 > http://thread.gmane.org/gmane.comp.gcc.patches/332160 > > On 01/

[patch 2/28] boehm-gc: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for boehm-gc. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. Makefile.in: Recreate. aclocal.m4: Recreate. configure: Recreate. include/Makefile

[patch 1/28] top-level: Use automake-1.11.6

Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner: > Now that gcc-5 is out, what about an automake-1.11.6 update for gcc-6? Patch for top-level files. 2015-05-06 Michael Haubenwallner Use automake-1.11.6. compile: Recreate. config.guess: Recreate. config.sub: Recreate. depc

[patch 0/27] RFC: Use automake-1.11.6 across the tree

Hello build machinery maintainers, following up http://thread.gmane.org/gmane.comp.gcc.patches/331902/focus=334462 http://thread.gmane.org/gmane.comp.gcc.patches/332160 On 01/25/2015 08:42 PM, Jan-Benedict Glaw wrote: > On Sun, 2015-01-04 20:20:40 +0100, Michael Haubenwallner >

Re: [PATCH PR target/65058] AIX: missing extern decorations "[DS]" for functions and "[RW]" for variables

Am 2015-02-13 um 23:02 schrieb Michael Haubenwallner: > Hi David, > > this is the patch I'm currently testing with gcc-4.8.4 for > http://gcc.gnu.org/PR65058 There's one unused variable now - obvious patch committed. /haubi/ >From bfea87e3e9e84c995a3b678a4c234cd0187

Re: [PATCH PR target/65058] AIX: missing extern decorations "[DS]" for functions and "[RW]" for variables

Am 2015-02-17 um 16:00 schrieb David Edelsohn: > On Tue, Feb 17, 2015 at 2:33 AM, Michael Haubenwallner > wrote: >> One more thought: How is that dollar_inside thing seen in >> ASM_OUTPUT_EXTERNAL supposed to work/be used? > > AIX XCOFF does not allow $ in label names.

Re: [PATCH] support --without-multilib --with-specs=-pthread on AIX

Am 2015-02-17 um 15:57 schrieb David Edelsohn: > On Tue, Feb 17, 2015 at 3:03 AM, Michael Haubenwallner > wrote: >> Hi David, >> >> according to LIB_SPEC found in config/rs6000/aix*.h, pthread linking was >> done with >> "-lpthreads -lc_r libc.a"

[PATCH] support --without-multilib --with-specs=-pthread on AIX

thout-multilib --with-specs=-pthread Thanks! /haubi/ >From cee852b7e80f15474187673926c4e0a96d454cac Mon Sep 17 00:00:00 2001 From: Michael Haubenwallner Date: Tue, 3 Feb 2015 12:56:53 +0100 Subject: [PATCH] support --without-multilib --with-specs=-pthread on AIX 2015-02-17 Michael Haubenwallner * config/rs6000/t-sli

Re: [PATCH PR target/65058] AIX: missing extern decorations "[DS]" for functions and "[RW]" for variables

Hi David, Am 2015-02-14 um 22:05 schrieb David Edelsohn: > Hi, Michael > > Thanks for noticing this. This patch generally seems to be on the > right track. The original ASM_OUTPUT_EXTERNAL code was not completely > correct in the pedantic sense. It should use [UA] mapping class > instead of [R

[PATCH PR target/65058] AIX: missing extern decorations "[DS]" for functions and "[RW]" for variables

Hi David, this is the patch I'm currently testing with gcc-4.8.4 for http://gcc.gnu.org/PR65058 Thanks! /haubi/ >From 0f5003fb25608cdae53445777e6a13fec3fbfffc Mon Sep 17 00:00:00 2001 From: Michael Haubenwallner Date: Fri, 13 Feb 2015 19:26:27 +0100 Subject: [PATCH 1/5] Fix de

Re: [build] libatomic, libgfortran: Use automake-1.11.1 to sync with the rest

ping As trunk is in stage 4, is there some accepted custom to re-run all the third party generators, to avoid different versions of generated code across the final release? Thanks! /haubi/ On 01/04/2015 08:20 PM, Michael Haubenwallner wrote: > (CC'ing build machinery maintainers,

Re: [build] libatomic, libgfortran: Use automake-1.11.1 to sync with the rest

(CC'ing build machinery maintainers, maybe I should have done this initially) Am 2014-12-31 um 11:45 schrieb Janne Blomqvist: > On Fri, Dec 19, 2014 at 2:56 PM, Michael Haubenwallner > wrote: >> On the way to prepare some (aix) libtool patch for toplevel libtool.m4 >&g

[build] libatomic, libgfortran: Use automake-1.11.1 to sync with the rest

Log: 2014-12-19 Michael Haubenwallner * Makefile.in: Regenerate with automake-1.11.1. * aclocal.m4: Likewise. * configure: Likewise. * testsuite/Makefile.in: Likewise. libgfortran/ChangeLog: 2014-12-19 Michael Haubenwallner * Makefile.in: Regenerate

fix aix build error with math.h in gcc/sreal.c

Recent commit 218765 adding sreal::to_double() breaks on AIX due to math.h being included before _LARGE_FILES and __STDC_FORMAT_MACROS being defined later in config.h and system.h, respectively. 2014-12-16 Michael Haubenwallner Both config.h and system.h define ABI/API macros for

Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s

On 11/25/2014 02:53 PM, David Edelsohn wrote: > > Now that things have calmed down with respect to breakage on AIX, the > patch for building libgcc_s is okay. FYI: libtool-2.4.4 does support "--with-aix-soname=aix|both|svr4" now too, http://thread.gmane.org/gmane.comp.gnu.libtool.patches/11789/

Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s

s as clear as possible though. Thanks! /haubi/ > > Thanks, David > > > On Mon, Nov 10, 2014 at 12:41 PM, Michael Haubenwallner > wrote: >> >> >> Am 2014-11-10 17:06, schrieb David Edelsohn: >>> On Mon, Nov 10, 2014 at 4:59 AM, Michael Haubenwalln

Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s

Am 2014-11-10 17:06, schrieb David Edelsohn: > On Mon, Nov 10, 2014 at 4:59 AM, Michael Haubenwallner > wrote: >> >> Am 2014-11-07 20:52, schrieb David Edelsohn: >>> First, please explicitly copy me on AIX or PowerPC patches sent to >>> gcc-patches. >>

Re: [PATCH] AIX: Filename-based shared library versioning for libgcc_s

l AIX shared objects at all, but static only lib.a archives whenever --enable-static is true - which is the "--with-aix-soname=svr4" use case. Slightly modified the patch to not create the libgcc_s.a symlink with aix-soname=svr4 now. And the Makefile target also has to be libgcc_s.so (via

[PATCH] AIX: Filename-based shared library versioning for libgcc_s

use yet, I'd love to see the gcc-5 release start introducing 'aix-soname' - allowing for "more Linux with AIX" ;) Thoughts? Thank you! /haubi/ >From 9f6fd44eddf3b0c43f0472c172d6420b8b91b7db Mon Sep 17 00:00:00 2001 From: Michael Haubenwallner Date: Fri, 16 Mar 2012 14

Re: [PATCH, committed] AIX libstdc++ configure.host LD_FLAGS

On 10/30/2014 03:19 PM, David Edelsohn wrote: > AIX has been unable to bootstrap since the match-and-simplify merge. > Richard Biener and I tracked this back to a bad interaction between a > GCC optimization and the AIX linker -G option to allow for SVR4-style > runtime linking. As the -G linker o

Re: [PATCH] collect2 should accept more AIX linker flags to change shared library search order

On 02/04/2013 10:33 PM, David Edelsohn wrote: > 2013-02-04 Michael Haubenwallner > > Accept all flags that enable aix runtime linking to change the > library search order. Also there is a disabling flag. > This patch is okay, and I agree that it should use strncmp.

[PATCH] collect2 should accept more AIX linker flags to change shared library search order

o, so the subsequent link step fails resolving these symbols. Thank you! /haubi/ 2013-02-04 Michael Haubenwallner Accept all flags that enable aix runtime linking to change the library search order. Also there is a disabling flag. * collect2.c (aixrtl_flag): Enabled by -G and -bsvr4 too. Disa

Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld

On 01/30/2013 04:56 PM, David Edelsohn wrote: > On Wed, Jan 30, 2013 at 10:44 AM, Michael Haubenwallner > wrote: >> >> On 01/30/2013 03:16 PM, David Edelsohn wrote: >>> wrote: >>>> 4: Also, LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ whil

Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld

On 01/30/2013 03:16 PM, David Edelsohn wrote: > wrote: >> 4: Also, LD_LIBRARY_PATH points to ppc64/libstdc++-v3/.libs/ while using >>32bit gcc/xgcc to build libatomic.a. >> => This is the one that /does/ break, as that 64bit libstdc++.a is there now. > Originally, I was using --boot-ld-flags

Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld

On 01/28/13 16:07, David Edelsohn wrote: > On Mon, Jan 28, 2013 at 4:07 AM, Michael Haubenwallner > wrote: > >> But still curious if you've been able to reproduce the problem, >> and why you didn't encounter this problem beforehand. > > As I mentioned bef

Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld

On 01/27/2013 03:16 AM, David Edelsohn wrote: > On Fri, Jan 25, 2013 at 8:55 AM, Michael Haubenwallner > wrote: > >> Same here, building everything out-of-source. The prerequisites used are: >> * CONFIG_SHELL=/usr/local/bin/bash 4.1.7 from bullfreeware (symlinks to

Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld

On 01/24/2013 06:45 PM, David Edelsohn wrote: >> Since switching to C++ inside gcc, it isn't possible to get working gcc/g++ >> binaries installed using native ld on AIX without this patch, as these need >> dynamic libstdc++.a from builddir(!). Even after successful build with the >> workaround fr

Re: [PATCH, regression?] Support --static-libstdc++ with native AIX ld

Thank you! /haubi/ 2014-01-23 Michael Haubenwallner AIX ld does support -bstatic/-bdynamic instead of -Bstatic/-Bdynamic. * configure.ac (gcc_cv_ld_static_dynamic): Define for AIX native ld. * configure: Regenerate. diff --git a/gcc/configure b/gcc/configure index 10ff5ae..f153294 100755

[PATCH, regression?] Support --static-libstdc++ with native AIX ld

=LD_LIBRARY_PATH on AIX. Thank you! /haubi/ 2013-01-23 Michael Haubenwallner AIX ld does support -bstatic/-bdynamic instead of -Bstatic/-Bdynamic. * gcc/configure.ac (gcc_cv_ld_static_dynamic): Define for AIX native ld. * gcc/configure: Regenerate. diff --git a/gcc/configure b/gcc

[PATCH] Unset M4 environment variable for flex

it is more robust to unset M4 environment variable before running $(FLEX) than expecting users to also set M4 when gcc actually tells missing flex only. Thank you! /haubi/ 2013-01-18 Michael Haubenwallner Flex gives M4 environment variable precedence over builtin path to m4. * gcc/Makefil

Re: [patch][RFC] Filename based shared library versioning on AIX

On 11/05/2012 07:31 PM, David Edelsohn wrote: > On Mon, Nov 5, 2012 at 1:10 PM, Michael Haubenwallner > wrote: > >> Well, as long as the old sharedlibs were not created as standalone shared >> objects (lib.so), this is similar to a normal "soname"-bump on AIX,

Re: [patch][RFC] Filename based shared library versioning on AIX

e documented, but > otherwise they are a good feature to add. Here's the updated patch. Thank you! /haubi/ >From 3c9141f9df666ad972688b31e1cfecfbfd6ef6b6 Mon Sep 17 00:00:00 2001 From: Michael Haubenwallner Date: Fri, 16 Mar 2012 14:49:20 +0100 Subject: [PATCH] AIX: Filename-based shlib v

[patch][RFC] Filename based shared library versioning on AIX

b50f5b17296ae3bc8a06326dc7596565439 Mon Sep 17 00:00:00 2001 From: Michael Haubenwallner Date: Fri, 16 Mar 2012 14:49:20 +0100 Subject: [PATCH] AIX: Filename-based shlib versioning for libgcc_s 2012-10-30 Michael Haubenwallner (libgcc_s) Optional filename-based shared library versioning on A

Re: [PATCH, libstdc++] Make empty std::string storage readonly

On 08/30/2012 11:45 AM, Jonathan Wakely wrote: > On 29 August 2012 13:25, Michael Haubenwallner wrote: >> On 08/28/2012 08:12 PM, Jonathan Wakely wrote: >>> On 28 August 2012 18:27, Michael Haubenwallner wrote: >>>>> >>>>> Does it actuall

Re: [PATCH, libstdc++] Make empty std::string storage readonly

On 08/28/2012 08:12 PM, Jonathan Wakely wrote: > On 28 August 2012 18:27, Michael Haubenwallner wrote: >>> >>> Does it actually produce a segfault? I suppose it might on some >>> platforms, but not all, so I'm not sure it's worth changing. >> >>

Re: [PATCH, libstdc++] Make empty std::string storage readonly

On 08/28/2012 06:46 PM, Jonathan Wakely wrote: > On 28 August 2012 16:15, Michael Haubenwallner wrote: >> Hi, >> >> in some old, large, originally C-written application (using gcc-4.2.4 still) >> I did have to find a bug that boils down to something like this: >>

[PATCH, libstdc++] Make empty std::string storage readonly

there still reasons not to make it readonly, like in attached patch? [1] http://gcc.gnu.org/PR40518 Thank you! /haubi/ >From d16c5d0cabbe9b308f852534be0a209b5b2c5cfd Mon Sep 17 00:00:00 2001 From: Michael Haubenwallner Date: Tue, 28 Aug 2012 17:05:48 +0200 Subject: [PATCH] Make default string storag