Re: Updating libtool in GCC and srctree

2007-03-09 Thread Albert Chin 
On Fri, Mar 09, 2007 at 03:58:40PM -0800, Steve Ellcey wrote:
> I am having more trouble with the GCC tree.  I put the new libtool in
> the toplevel directory, just like I did in the binutils src tree and
> then I went to the boehm-gc (and libffi) directories to try and rerun
> autoconf.  If I just run autoconf I get errors because I am not
> including the new ltoptions.m4, ltsugar.m4, and ltversion.m4 files.  Now
> in the binutils tree the acinclude.m4 files had explicit includes of
> libtool.m4 and I added includes of ltoptions.m4, ltsugar.m4, and
> ltversion.m4.  But boehm-gc has no acinclude.m4 file and while libffi
> has an acinclude.m4 file, it doesn't have an include of libtool.m4.  So
> my question is, how is the include of libtool.m4 getting into
> aclocal.m4?  Is it by running aclocal?  I tried to run aclocal but I get
> errors when I run it:
> 
> $ aclocal
> autom4te: unknown language: Autoconf-without-aclocal-m4
> aclocal: autom4te failed with exit status: 1
> 
> This is aclocal 1.9.6.  Any idea on what I need to do here to fix this
> error?  Why do some acinclude.m4 files have explicit includes for
> libtool files (libgfortran, libgomp, etc) but other's don't (libffi,
> gcc).

I just pulled HEAD and if you look at the tail end of
boehm-gc/aclocal.m4, you'll find:
  m4_include([../config/acx.m4])
  m4_include([../config/depstand.m4])
  m4_include([../config/lead-dot.m4])
  m4_include([../config/multi.m4])
  m4_include([../config/no-executables.m4])
  m4_include([../libtool.m4])

So, you need to run aclocal with:
  $ aclocal -I ../config -I ..

-- 
albert chin ([EMAIL PROTECTED])

4.0.2 bootstrap comparison failure on AIX 5.3

2005-10-10 Thread Albert Chin 
I've built gcc-4.0.2 as follows on AIX 5.3 and am receiving a
bootstrap comparison failure:
  $ cd /opt/build
  $ bzip2 -dc gcc-4.0.2.tar.bz2 | tar xf -
  $ mkdir gcc
  $ cd gcc
  $ CC=/usr/vac/bin/cc CONFIG_SHELL=/opt/fsw/bin/bash \
  /opt/fsw/bin/bash /opt/build/gcc-4.0.2/configure \
  --with-included-gettext --enable-shared --enable-threads \
  --enable-languages="c,c++" --disable-multilib
  ...
  $ gmake bootstrap
  ...
  Bootstrap comparison failure!
  ./fold-const.o differs
  gmake[1]: *** [slowcompare] Error 1
  gmake[1]: Leaving directory `/opt/build/gcc/gcc'
  gmake: *** [bootstrap] Error 2

The AIX 5.3 system:
  $ oslevel -r
  5300-02
  $ lslpp -L vac.C
  vac.C  7.0.0.3A FIBM XL C Compiler

I don't see anything on
http://gcc.gnu.org/install/specific.html#x-ibm-aix specific to AIX
5.3. I have also built on AIX 5.1 with the same result.

-- 
albert chin ([EMAIL PROTECTED])

Anyone build 4.0.2 on IRIX 6.5?

2005-10-12 Thread Albert Chin 
I'm getting a SGI linker bug building 4.0.2 on IRIX 6.5.23m and
6.5.26m:
  $ cd /opt/build
  $ bzip2 -dc /opt/src/devel/gcc-4.0.2/src/gcc-4.0.2.tar.bz2 | tar xf -
  $ mkdir gcc
  $ cd gcc
  $ CC=cc /opt/build/gcc-4.0.2/configure --enable-shared \
  --with-gnu-as --with-as="/opt/TWWfsw/gcc402/mips-sgi-irix6.5/bin/as" \
  --enable-languages="c,c++" 
  $ gmake bootstrap
  ...
  /opt/fsw/bin/bash ../libtool --tag CXX --mode=link
/opt/build/gcc/gcc/xgcc -shared-libgcc ... -B/opt/build/gcc/gcc/
-nostdinc++ -L/opt/build/gcc/mips-sgi-irix6.5/libstdc++-v3/src
-L/opt/build/gcc/mips-sgi-irix6.5/libstdc++-v3/src/.libs
-B/usr/local/mips-sgi-irix6.5/bin/ -B/usr/local/mips-sgi-irix6.5/lib/
-isystem /usr/local/mips-sgi-irix6.5/include -isystem
/usr/local/mips-sgi-irix6.5/sys-include   -fno-implicit-templates
-Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once  -ffunction-sections -fdata-sections
-o libstdc++.la -rpath /usr/local/lib/../lib32 -version-info 6:6:0
-lm  bitmap_allocator.lo ...
  ...
  ld32: FATAL   2  : Internal: at ../../ld/section_type.c In load_info() 
unknown section type
  collect2: ld returned 1 exit status
  gmake[4]: *** [libstdc++.la] Error 1
  gmake[4]: Leaving directory `/opt/build/gcc/mips-sgi-irix6.5/libstdc++-v3/src'
  gmake[3]: *** [all-recursive] Error 1

I'm building with GNU as because of:
  http://gcc.gnu.org/ml/gcc-help/2005-10/msg00048.html

Has anyone managed to build 4.0.2 on IRIX 6.5?

-- 
albert chin ([EMAIL PROTECTED])

Re: 4.0.2 bootstrap comparison failure on AIX 5.3

2005-10-12 Thread Albert Chin 
On Mon, Oct 10, 2005 at 11:58:04PM -0400, David Edelsohn wrote:
> >>>>> Albert Chin writes:
> 
> Albert> I've built gcc-4.0.2 as follows on AIX 5.3 and am receiving a
> Albert> bootstrap comparison failure:
> Albert> $ CC=/usr/vac/bin/cc CONFIG_SHELL=/opt/fsw/bin/bash \
> 
> Albert> I don't see anything on
> Albert> http://gcc.gnu.org/install/specific.html#x-ibm-aix specific to AIX
> Albert> 5.3. I have also built on AIX 5.1 with the same result.
> 
>   I have bootstrapped on AIX 5.1 and AIX 5.2 using GCC without
> problem. 

Just tried this and bootstrapping with GCC works. Guess there's a bug
in the IBM compiler. I tried AIX 4.3.3 and 5.2 as well and encounter
the same bug. The version of the IBM compiler on our 5.x machines is
the same but on 4.3.3 it's the 6.0 compiler. So, looks like an old bug
is being tickled.

-- 
albert chin ([EMAIL PROTECTED])

Re: Anyone build 4.0.2 on IRIX 6.5?

2005-10-12 Thread Albert Chin 
On Wed, Oct 12, 2005 at 05:09:20PM +0200, Rainer Orth wrote:
> Albert Chin <[EMAIL PROTECTED]> writes:
> 
> >   ld32: FATAL   2  : Internal: at ../../ld/section_type.c In load_info() 
> > unknown section type
> >   collect2: ld returned 1 exit status
> >   gmake[4]: *** [libstdc++.la] Error 1
> 
> Which version of ld do you use?  I'm having problems with MIPSpro 7.4.3m ld
> on IRIX 6.5.26f which fails to link cc1 in stage2 due to a GOT overflow.
> MIPSpro 7.3 ld on IRIX 6.5.10m is ok, though.

MIPSpro 7.4.3m ld.

> I tried to report this (a regression from the 3.4 branch where both
> versions of ld work ok), but failed since gccbug on the new gcc.gnu.org
> didn't work at the time.

I'll report a bug for my problem though it seems like a ld(1) bug.

-- 
albert chin ([EMAIL PROTECTED])

Re: Successfull build of gcc-4.0.2 on mips-sgi-irix6.5

2005-10-14 Thread Albert Chin 
On Wed, Oct 12, 2005 at 02:29:56PM +0200, Rainer Emrich wrote:
> Compiler version: 4.0.2
> Platform: mips-sgi-irix6.5
> configure flags:
> - - --prefix=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install
> - - --with-gnu-as
> - - --with-as=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/as
> - - --with-gnu-ld
> - - --with-ld=/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/bin/ld
> - - --disable-shared --enable-threads=posix --enable-haifa --disable-nls
> - - --disable-libmudflap --with-gmp=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5
> - - --with-mpfr=/appl/shared/gnu/IRIX64/mips-sgi-irix6.5
> - - --enable-languages=c,ada,c++,f95,objc

Can the resulting GCC build Emacs _and_ XEmacs?

-- 
albert chin ([EMAIL PROTECTED])

Special bugzilla query for fixed PRs

2005-10-28 Thread Albert Chin 
For a list of PRs fixed for 4.0.2:
  
http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.0.2

Is it possible to have the full summary field displayed? I'd really
prefer just:
  BUG-ID  SUMMARY

to make it easy to generate a changelog of fixed PRs.

-- 
albert chin ([EMAIL PROTECTED])

Re: Special bugzilla query for fixed PRs

2005-10-28 Thread Albert Chin 
On Fri, Oct 28, 2005 at 12:54:38PM -0400, Andrew Pinski wrote:
> > 
> > For a list of PRs fixed for 4.0.2:
> >   
> > http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.0.2
> > 
> > Is it possible to have the full summary field displayed? I'd really
> > prefer just:
> >   BUG-ID  SUMMARY
> > 
> > to make it easy to generate a changelog of fixed PRs.
> 
> You can change the web page any which way you like.
> 
> Use the "Change Columns" link to do that.

Ah, cool. Thanks.

-- 
albert chin ([EMAIL PROTECTED])

Re: Build using --with-gmp and shared libraries

2005-11-04 Thread Albert Chin 
On Fri, Nov 04, 2005 at 10:10:14AM +0100, FranXois-Xavier_Coudert wrote:
> Here is a patch to fix PR libfortran/21547: when building with
> --with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
> $(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
> correctly when using the freshly built gfortran to build libgfortran.
> The same thing happens for the gfortran testsuite, and the fix is also
> included in this patch.

Why wouldn't mpfr have the same problem?

-- 
albert chin ([EMAIL PROTECTED])

Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?

2005-11-06 Thread Albert Chin 
I've built gcc-3.4.3 for HP-UX 11.23/IA-64 and used the pre-compiled
gcc-3.4.4 binary from the http://www.hp.com/go/gcc site. Both exhibit
the same problem. While trying to build Perl 5.8.6:
  $ gmake
  ...
  gcc -v -o libperl.so -shared -fPIC perl.o  gv.o toke.o perly.o op.o
pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o
sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o
taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o
numeric.o locale.o pp_pack.o pp_sort.o  -lcl -lnsl -lnm -ldl -ldld -lm
-lsec -lpthread -lc
  ...
 /opt/TWWfsw/gcc343/libexec/gcc/ia64-hp-hpux11.23/3.4.3/collect2
+Accept TypeMismatch -b -o libperl.so -L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/../../.. perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc -lgcc
^^^

Notice the "-lgcc -lgcc" at the end of the collect2 command-line,
_not_ "-lgcc_s -lgcc_s".

On HP-UX 11.23/PA-RISC, I get:
  /opt/TWWfsw/gcc343/libexec/gcc/hppa2.0-hp-hpux11.23/3.4.3/collect2
-z -b -o libperl.sl -L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343r/lib
-L/opt/TWWfsw/gcc343/lib/gcc/hppa2.0-hp-hpux11.23/3.4.3 -L/usr/ccs/bin
-L/usr/ccs/lib -L/opt/langtools/lib -L/opt/TWWfsw/gcc343/lib perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -lmalloc -ldld -lm -lcrypt -lsec -lpthread -lc -lgcc_s -lgcc_s

Using the HP pre-compiled binary of gcc-4.0.2, I get:
 /opt/hp-gcc/4.0.2/bin/../libexec/gcc/ia64-hp-hpux11.23/4.0.2/collect2
-z +Accept TypeMismatch -b -o libperl.so
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc
-L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/opt/hp-gcc/4.0.2/bin/../lib/gcc/ia64-hp-hpux11.23/4.0.2/../../..
-L/opt/hp-gcc/4.0.2//lib/gcc/ia64-hp-hpux11.23/4.0.2/../../.. perl.o
gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o
hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o
doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o
perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o -lcl -lnsl
-lnm -ldl -ldld -lm -lsec -lpthread -lc -lgcc_s -lunwind -lgcc_s
-lunwind

The "*libgcc" line from the 3.4.3/3.4.4 specs file:
  *libgcc:
  %{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64} 
%{static|static-libgcc:-lgcc -lgcc_eh 
-lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh 
-lunwind}%{shared-libgcc:-lgcc_s%M -lunwind -lgcc}}%{shared:-lgcc_s%M 
-lunwind%{!shared-libgcc:-lgcc}

The "*libgcc" line from the 4.0.2 specs file (via -dumpspecs):
  *libgcc:
  %{static|static-libgcc:-lgcc -lgcc_eh 
-lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh 
-lunwind}%{shared-libgcc:-lgcc_s -lunwind -lgcc}}%{shared:-lgcc_s -lunwind}}}

Is the problem in the "*libgcc" entry? It seems !shared-libgcc is
true, though I don't know why.
  $ /opt/TWWfsw/gcc343/bin/gcc -v
  Reading specs from
  /opt/TWWfsw/gcc343/lib/gcc/ia64-hp-hpux11.23/3.4.3/specs
  Configured with: /opt/build/gcc-3.4.3/configure --with-gnu-as
  --with-as=/opt/TWWfsw/gcc343/ia64-hp-hpux11.23/bin/as
  --with-included-gettext --enable-shared
  --datadir=/opt/TWWfsw/gcc343/share --enable-languages=c,c++,f77
  --with-local-prefix=/opt/TWWfsw/gcc343 --prefix=/opt/TWWfsw/gcc343
  Thread model: single
  gcc version 3.4.3 (TWW)

-- 
albert chin ([EMAIL PROTECTED])

Re: Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?

2005-11-07 Thread Albert Chin 
On Mon, Nov 07, 2005 at 03:13:24PM -0800, Jim Wilson wrote:
> Albert Chin wrote:
> >The "*libgcc" line from the 3.4.3/3.4.4 specs file:
> >  *libgcc:
> >  %{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64} 
> >  %{static|static-libgcc:-lgcc -lgcc_eh 
> >  -lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc 
> >  -lgcc_eh -lunwind}%{shared-libgcc:-lgcc_s%M -lunwind 
> >  -lgcc}}%{shared:-lgcc_s%M -lunwind%{!shared-libgcc:-lgcc}
> 
> It looks like there is a close-brace '}' missing after the
> -lgcc_s_hpux64.  This will terminate the shared-libgcc rule before
> the static rule starts.  Then delete one of the 4 close braces after
> the -lunwind.  There are one too many braces here.

I set ':set showmatch' in vim and all the braces match up.

> I don't see this problem in the FSF gcc tree.  I'm guessing this is
> a mistake in the HP gcc sources that you are using.

The above is from gcc-3.4.3 + some patches. However, the HP 3.4.4
binary has the same "*libgcc" line. Do you have a GCC 3.4.x binary on
HP/IA-64 which works correctly with -shared?

-- 
albert chin ([EMAIL PROTECTED])

Re: Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?

2005-11-07 Thread Albert Chin 
On Mon, Nov 07, 2005 at 06:27:40PM -0800, Jim Wilson wrote:
> Albert Chin wrote:
> >I set ':set showmatch' in vim and all the braces match up.
> 
> Yes, the braces match up.  You wouldn't have been able to build gcc if 
> they didn't.
> 
> However, they are still wrong.  One of the braces is in the wrong place, 
> and has to be moved.  It looks like someone tried to modify the libgcc 
> specs, got a build error, then added a brace to fix it, but mistakenly 
> added the brace in the wrong place.
> 
> As mentioned before, there is a brace missing after the gcc_s_hpux64. 
> This brace is needed to close off the shared-libgcc rule before the 
> static-libgcc rule starts.  You then must delete a brace from the end of 
> the !static rule which has one too many.

Yes, doing so gives the correct 'gcc -shared' output.

> The libgcc spec in the FSF gcc sources do not match the one you have 
> given, so this appears to be a bug in patches that you or HP have added 
> to gcc.

I just built gcc-3.4.4 with one patch to fix a sco_math fixinc bug on
this platform:
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00985.html

The build of gcc-3.4.4 exhibits the same problem. I've filed PR24718
on this issue.

Thanks for your help.

-- 
albert chin ([EMAIL PROTECTED])

Re: Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?

2005-11-08 Thread Albert Chin 
On Tue, Nov 08, 2005 at 04:00:42PM -0800, Jim Wilson wrote:
> The only part I don't understand is where these specs came from, as
> this doesn't match anything in the FSF tree.  I'm guessing that HP
> is distributing a modified gcc with patches added to it, and these
> patches are buggy.  I went to the HP web site, and I see that the
> gcc sources there are in a depot file.  Can I do anything with a
> depot file even though I don't have HPUX?  I haven't tried
> downloading the file to check.

A .depot file is a tar file so just untar it.

-- 
albert chin ([EMAIL PROTECTED])

r227907 and AIX 5.[23]

2018-07-25 Thread Albert Chin 
r227907 had the following change:
Index: aix61.h
===
--- aix61.h (revision 227906)
+++ aix61.h (revision 227907)
@@ -167,7 +167,7 @@
%{!maix64:\
  %{pthread:%{pg:gcrt0_r%O%s}%{!pg:%{p:mcrt0_r%O%s}%{!p:crt0_r%O%s}}}\
  %{!pthread:%{pg:gcrt0%O%s}%{!pg:%{p:mcrt0%O%s}%{!p:crt0%O%s}\
-   %{shared:crtcxa_s%O%s;:crtcxa%O%s}"
+   %{shared:crtcxa_s%O%s;:crtcxa%O%s} crtdbase%O%s"
 
 /* AIX V5 typedefs ptrdiff_t as "long" while earlier releases used "int".  */

In trying to build gcc-8.1.0 on AIX 5.3 (cf. PR86553), I looked at how
libgcc_s.a was built and, on AIX 6 and 7, crtdbase was linked in,
providing __gcc_unwind_dbase (and crtcxa_s for __dso_handle). However,
on AIX 5.3, this file is never included because
gcc/config/rs6000/aix53.h has:
  #undef STARTFILE_SPEC
  #define STARTFILE_SPEC "%{!shared:\
 %{maix64:%{pg:gcrt0_64%O%s}%{!pg:%{p:mcrt0_64%O%s}%{!p:crt0_64%O%s}}}\
 %{!maix64:\
   %{pthread:%{pg:gcrt0_r%O%s}%{!pg:%{p:mcrt0_r%O%s}%{!p:crt0_r%O%s}}}\
   %{!pthread:%{pg:gcrt0%O%s}%{!pg:%{p:mcrt0%O%s}%{!p:crt0%O%s}"

A patch similar to the above must also be made to aix53.h for 8.1.0 to
build successfully on AIX 5.3. At the moment, GCC 5+ doesn't build on
AIX 5.3 because of the above.

-- 
albert chin (ch...@thewrittenword.com)

Re: r227907 and AIX 5.[23]

2018-07-25 Thread Albert Chin 
On Wed, Jul 25, 2018 at 01:15:44PM -0400, David Edelsohn wrote:
> AIX 5.3 no longer is under supported or maintained.

Ok. Well, we can now build 8.1 with this change so we'll update the
PR and leave it to someone else to decide if the patch should be
merged.

-- 
albert chin (ch...@thewrittenword.com)

Help with fixinclude fix for PR86599

2018-08-15 Thread Albert Chin 
Hi. I've come up with a fixincl fix for PR86599 but "make check" in
the fixincludes directory does not work and I do not know why. I know
just enough fixincl-fu to produce a patch for this issue. I am trying
to convert a chunk of code in stdlib on HP-UX 11.31/PA:

#  ifndef _LONG_DOUBLE
#define _LONG_DOUBLE
#  if !defined(__ia64) || !defined(_PROTOTYPES) || defined(_LONG_DOUBLE_STRUCT)
typedef struct {
uint32_t word1, word2, word3, word4;
} long_double;
extern long_double strtold __((const char * __restrict, char ** __restrict));
#  else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
#ifdef _INCLUDE_HPUX_SOURCE
typedef long double long_double;
#endif /* _INCLUDE_HPUX_SOURCE */
extern long double strtold __((const char * __restrict, char ** __restrict));
#  endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
#endif /* _LONG_DOUBLE */

to:

extern long double strtold(const char *, char **);

I am doing this by fixing hpux_long_double_2 so it now looks like:
fix = {
hackname  = hpux_long_double_2;
mach  = "hppa*-*-hpux11.3*";
files = stdlib.h;
select= "extern[ \t]long_double[ \t]strtold";
bypass= "long_double_t";
sed   = "/^#[ \t]*ifndef _LONG_DOUBLE/,"
"/\\/\\* _LONG_DOUBLE \\*\\//c\\\n"
"extern long double strtold(const char *, char **);\n";
sed   = "s/long_double/long double/g";

test_text = "#  ifndef _LONG_DOUBLE\n"
"#define _LONG_DOUBLE\n"
" typedef struct {\n"
"   unsigned int word1, word2, word3, word4;\n"
" } long_double;\n"
"extern long_double strtold(const char *, char **);\n"
"#  endif /* _LONG_DOUBLE */\n";
};

This works but "make check" returns:

stdlib.h /opt/build/gcc-8.2.0/fixincludes/tests/base/stdlib.h differ: char 
1475, line 59
*** stdlib.hWed Aug 15 19:38:37 2018
--- /opt/build/gcc-8.2.0/fixincludes/tests/base/stdlib.hThu Feb 22 
16:12:26 2018
***
*** 56,61 
--- 56,62 
  
  
  #if defined( HPUX_LONG_DOUBLE_2_CHECK )
+ #  if !defined(__ia64) || !defined(_PROTOTYPES) || 
defined(_LONG_DOUBLE_STRUCT)
  
  #endif  /* HPUX_LONG_DOUBLE_2_CHECK */

There were fixinclude test FAILURES

Any ideas?

-- 
albert chin (ch...@thewrittenword.com)

Re: Help with fixinclude fix for PR86599

2018-08-15 Thread Albert Chin 
On Wed, Aug 15, 2018 at 03:52:33PM -0400, David Edelsohn wrote:
> You must manually insert the additional test lines into the appropriate
> file in fixincludes/tests/base and then retest.
> 
> Please see step (6) in fixincludes/README

Ok, thanks. fixincludes/tests/res/stdlib.h has:
  #if defined( HPUX_LONG_DOUBLE_CHECK )
  extern long double strtold(const char *, char **);

  #endif  /* HPUX_LONG_DOUBLE_CHECK */

  #if defined( HPUX_LONG_DOUBLE_2_CHECK )
  #  if !defined(__ia64) || !defined(_PROTOTYPES) || 
defined(_LONG_DOUBLE_STRUCT)
 
  #endif  /* HPUX_LONG_DOUBLE_2_CHECK */

The body of HPUX_LONG_DOUBLE_2_CHECK is no longer valid with my fix.
I'm thinking it should look like HPUX_LONG_DOUBLE_CHECK so I modified
HPUX_LONG_DOUBLE_2_CHECK to look like HPUX_LONG_DOUBLE_CHECK.

However, when I run "make check", fixincludes/tests/res/stdlib.h has:
  #if defined( HPUX_LONG_DOUBLE_2_CHECK )

  #endif  /* HPUX_LONG_DOUBLE_2_CHECK */

So, I modified test_text to the following:
test_text = "#  ifndef _LONG_DOUBLE\n"
"#define _LONG_DOUBLE\n"
" typedef struct {\n"
"   unsigned int word1, word2, word3, word4;\n"
" } long_double;\n"
"#  endif /* _LONG_DOUBLE */\n"
"extern long_double strtold(const char *, char **);\n";
rather than:
test_text = "#  ifndef _LONG_DOUBLE\n"
"#define _LONG_DOUBLE\n"
" typedef struct {\n"
"   unsigned int word1, word2, word3, word4;\n"
" } long_double;\n"
"extern long_double strtold(const char *, char **);\n"
"#  endif /* _LONG_DOUBLE */\n";

and modified fixincludes/tests/base/stdlib.h to:
  #if defined( HPUX_LONG_DOUBLE_CHECK )
  extern long double strtold(const char *, char **);

  #endif  /* HPUX_LONG_DOUBLE_CHECK */


  #if defined( HPUX_LONG_DOUBLE_2_CHECK )
  extern long double strtold(const char *, char **);

  #endif  /* HPUX_LONG_DOUBLE_2_CHECK */

I don't know why the change to test_text causes "make check" to
succeed though.

> Thanks, David
> 
> 
> 
> 
> On Wed, Aug 15, 2018 at 3:46 PM Albert Chin 
> wrote:
> 
> > Hi. I've come up with a fixincl fix for PR86599 but "make check" in
> > the fixincludes directory does not work and I do not know why. I know
> > just enough fixincl-fu to produce a patch for this issue. I am trying
> > to convert a chunk of code in stdlib on HP-UX 11.31/PA:
> >
> > #  ifndef _LONG_DOUBLE
> > #define _LONG_DOUBLE
> > #  if !defined(__ia64) || !defined(_PROTOTYPES) ||
> > defined(_LONG_DOUBLE_STRUCT)
> > typedef struct {
> > uint32_t word1, word2, word3, word4;
> > } long_double;
> > extern long_double strtold __((const char * __restrict, char **
> > __restrict));
> > #  else /* !__ia64 || !_PROTOTYPES || _LONG_DOUBLE_STRUCT */
> > #ifdef _INCLUDE_HPUX_SOURCE
> > typedef long double long_double;
> > #endif /* _INCLUDE_HPUX_SOURCE */
> > extern long double strtold __((const char * __restrict, char **
> > __restrict));
> > #  endif /* !__ia64 ||!_PROTOTYPES ||_LONG_DOUBLE_STRUCT */
> > #endif /* _LONG_DOUBLE */
> >
> > to:
> >
> > extern long double strtold(const char *, char **);
> >
> > I am doing this by fixing hpux_long_double_2 so it now looks like:
> > fix = {
> > hackname  = hpux_long_double_2;
> > mach  = "hppa*-*-hpux11.3*";
> > files = stdlib.h;
> > select= "extern[ \t]long_double[ \t]strtold";
> > bypass= "long_double_t";
> > sed   = "/^#[ \t]*ifndef _LONG_DOUBLE/,"
> > "/\\/\\* _LONG_DOUBLE \\*\\//c\\\n"
> > "extern long double strtold(const char *, char **);\n";
> > sed   = "s/long_double/long double/g";
> >
> > test_text = "#  ifndef _LONG_DOUBLE\n"
> > "#define _LONG_DOUBLE\n"
> > " typedef struct {\n"
> > "   unsigned int word1, word2, word3, word4;\n"
> > " } long_double;\n"
> > "extern long_double strtold(const char *, char **);\n"
> > "#  endif /* _LONG_DOUBLE */\n";
> > };
> >
> > This works but "make check" returns:
> >
> > stdlib.h /opt/build/gcc-8.2.0/fixincludes/tests/base/stdlib.h differ: char
> > 1475, line 59
> > *** stdlib.hWed Aug 15 19:38:37 2018
> > --- /opt/build/gcc-8.2.0/fixincludes/tests/base/stdlib.hThu Feb 22
> > 16:12:26 2018
> > ***
> > *** 56,61 
> > --- 56,62 
> >
> >
> >   #if defined( HPUX_LONG_DOUBLE_2_CHECK )
> > + #  if !defined(__ia64) || !defined(_PROTOTYPES) ||
> > defined(_LONG_DOUBLE_STRUCT)
> >
> >   #endif  /* HPUX_LONG_DOUBLE_2_CHECK */
> >
> > There were fixinclude test FAILURES
> >
> > Any ideas?
> >
> > --
> > albert chin (ch...@thewrittenword.com)
> >

-- 
albert chin (ch...@thewrittenword.com)

Name mangling issue with HP, Sun, Tru64 UNIX C++ but not GCC

2006-02-01 Thread Albert Chin 
We ran into a problem building KDE on HP-UX 11.23/IA with the HP C++
compiler. The compiler mangled a function name in a .cpp file though
it was declared extern "C" in the .h file. After a post to the HP C++
developers list, we were told this behavior is correct. GCC 4.0.2 does
not do this so I'd like to get your opinion.

$ cat mangle-1.cc
typedef enum {
  XSLDBG_MSG_THREAD_NOTUSED,
  XSLDBG_MSG_THREAD_INIT
} XsldbgMessageEnum;

extern "C" {
  void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
 const void *data));
}

static int (*notifyXsldbgAppFuncPtr) (XsldbgMessageEnum type,
  const void *data) = 0;

void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
   const void *data))
{
  notifyXsldbgAppFuncPtr = notifyXsldbgAppFunc;
}

$ g++ --version
g++ (GCC) 4.0.2 (TWW)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$ g++ -c mangle-1.cc
$ nm mangle-1.o | grep -i xsldbg
 b notifyXsldbgAppFuncPtr
 T xsldbgSetAppFunc

So, GCC isn't mangling it. Now for the HP C++ compiler:
  [HP-UX 11.23/IA]
  $ aCC -AA -c mangle-1.cc
  # nm mangle-1.o | grep -i xsldbg
  [9]  |0|  48|FUNC |GLOB |0|   
.text|_Z16xsldbgSetAppFuncPFi17XsldbgMessageEnumPKvE

Let's try some other compilers:
  [Solaris 8]
  $ CC -V
  CC: Sun C++ 5.5 Patch 113817-15 2005/10/25
  $ CC -c mangle-1.cc
  "mangle-1.cc", line 15: Warning: function void(int(*)(XsldbgMessageEnum,const 
void*)) overloads extern "C" void(extern "C" int(*)(XsldbgMessageEnum,const 
void*)) because of different language linkages.
  1 Warning(s) detected.
  $ nm mangle-1.o | grep -i xsldbg
  [4] |16|  36|FUNC |GLOB |0|2 
|__1cQxsldbgSetAppFunc6FpFnRXsldbgMessageEnum_pkv_i_v_
  [3] | 0|   4|OBJT |LOCL |0|3 |notifyXsldbgAppFuncPtr

  [IRIX 6.5]
  $ CC -version
  MIPSpro Compilers: Version 7.4.4m
  $ CC -c mangle-1.cc
  $ nm mangle-1.o | grep -i xsldbg
  [3] | 0|  40|FUNC |GLOB |DEFAULT  |5 |xsldbgSetAppFunc
  [16]| 0|   0|STAT |LOCL |DEFAULT 
|MIPS_DATA|notifyXsldbgAppFuncPtr

  [AIX 5.3]
  $ xlC -c mangle-1.cc
  $ nm mangle-1.o | grep -i xsldbg
  .xsldbgSetAppFuncT   0
  xsldbgSetAppFunc D  88  12
  xsldbgSetAppFunc d  80   4

  [Tru64 UNIX 5.1]
  $ cxx -version V7.1-006 -V
  Compaq C++ V7.1-006 for Compaq Tru64 UNIX V5.1 (Rev. 732)
  Compiler Driver V7.1-006 (cxx) cxx Driver
  $ cxx -version V7.1-006 -c mangle-1.cc
  $ nm mangle-1.o | grep -i xsldbg  
  xsldbgSetAppFunc(int (*)(XsldbgMessageEnum, const void*)) |  
| T | 0008

So, it looks like the HP-UX/IA, Sun, and Tru64 UNIX C++ compilers
mangle but the AIX, SGI, and GNU C++ compilers do not.

Fixing mangle-1.c for HP, Sun, and Tru64 UNIX is easy (after the HP
developer told me how to do it):
  $ cat mangle-2.cc
  typedef enum {
XSLDBG_MSG_THREAD_NOTUSED,
XSLDBG_MSG_THREAD_INIT
  } XsldbgMessageEnum;

  typedef int (*notifyXsldbgAppFuncType) (XsldbgMessageEnum type,
  const void *data);

  extern "C" {
void xsldbgSetAppFunc (notifyXsldbgAppFuncType notifyXsldbgAppFunc);
  }

  static notifyXsldbgAppFuncType notifyXsldbgAppFuncPtr = 0;

  void xsldbgSetAppFunc (notifyXsldbgAppFuncType notifyXsldbgAppFunc) {
notifyXsldbgAppFuncPtr = notifyXsldbgAppFunc;
  }

According to the HP developer:
 >This is a subtle one that we see fairly often.  The problem is that
 >there are two functions xsldbgSetAppFunc with different types.  The
 >first (the declaration) has a parameter of type
 >
 >*notifyXsldbgAppFunc) (XsldbgMessageEnum type, const void *data)
 >
 >and that parameter has C linkage.  The second (the definition, which
 >ends up being mangled) has a parameter of type:
 >
 >*notifyXsldbgAppFunc) (XsldbgMessageEnum type, const void *data)
 >
 >but that parameter has C++ linkage.  Since this is recognized as a
 >different function because of the difference in parameter, and is not
 >itself enclosed in an extern "C" block, it is mangled.
 >
 >To get these to match, you need to define a type for the parameter
 >which has C linkage and use it in both places, or place the entire
 >definition in an extern "C" block, if that will fork for your actual
 >situation.

 >The linkage of a parameter that is a function is considered in its type.   
 >One has C linkage, the other C++ linkage.  It is subtle.

Who is right?

-- 
albert chin ([EMAIL PROTECTED])

Re: Name mangling issue with HP, Sun, Tru64 UNIX C++ but not GCC

2006-02-20 Thread Albert Chin 
On Wed, Feb 01, 2006 at 01:21:03PM -0500, Andrew Pinski wrote:
> > 
> > We ran into a problem building KDE on HP-UX 11.23/IA with the HP C++
> > compiler. The compiler mangled a function name in a .cpp file though
> > it was declared extern "C" in the .h file. After a post to the HP C++
> > developers list, we were told this behavior is correct. GCC 4.0.2 does
> > not do this so I'd like to get your opinion.
> > 
> > $ cat mangle-1.cc
> > typedef enum {
> >   XSLDBG_MSG_THREAD_NOTUSED,
> >   XSLDBG_MSG_THREAD_INIT
> > } XsldbgMessageEnum;
> > 
> > extern "C" {
> >   void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
> >  const void *data));
> > }
> > 
> > static int (*notifyXsldbgAppFuncPtr) (XsldbgMessageEnum type,
> >   const void *data) = 0;
> > 
> > void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
> >const void *data))
> > {
> >   notifyXsldbgAppFuncPtr = notifyXsldbgAppFunc;
> > }
> 
> This is most likely very related to PR 2316 where GCC does not use language
> as the overloaded part.  

Is there some place in the C++ standard I can look up to determine
what the correct behavior for the above code should be?

-- 
albert chin ([EMAIL PROTECTED])

Re: changing the SPARC default

2006-03-17 Thread Albert Chin 
On Wed, Mar 15, 2006 at 08:10:41PM -0800, Alexey Starovoytov wrote:
> 2nd:
>  - change the default for Solaris 7+ and linux

Why not 2.6+? Because 7+ does 64-bit?

-- 
albert chin ([EMAIL PROTECTED])

Re: why is libgcc_s.so.1 not executable?

2006-04-07 Thread Albert Chin 
On Fri, Apr 07, 2006 at 11:03:26AM +0200, [EMAIL PROTECTED] wrote:
> I just realized that the installation of libgcc_s.so.1 in "make install"
> is done like this
> (builfing gcc-4.0.3 on Solaris 8 / Sparc):
> 
> /bin/sh ../../gcc-4.0.3/gcc/../mkinstalldirs /tmp2/gcc_4.0/lib/sparcv9;
> ginstall -c -m 644 sparcv9/libgcc_s.so.1
> /tmp2/gcc_4.0/lib/sparcv9/libgcc_s.so.1; rm -f
> /tmp2/gcc_4.0/lib/sparcv9/libgcc_s.so; ln -s libgcc_s.so.1
> /tmp2/gcc_4.0/lib/sparcv9/libgcc_s.so
> 
> There is explicitely mode 644 used - in contrast to all other libs
> (libstdc++.so*, libgfortran.so*),

The other libs are libtool libs and are installed differently from
libgcc_s.so. Look at gcc/mklibgcc.in in the source directory and
gcc/libgcc.mk in the build directory.

> which are installed with 755 permissions. As a consequence, executables
> that are linked with
> libgcc_s.so.1 are not able to load it, even if the RUNPATH
> (-R/path/to/libgcc) or 
> LD_LIBRARY_PATH are defined correctly.

Are you _sure_? We don't have a problem on a Solaris 8 system with
libgcc_s.so, mode 644, with either GCC 3.4.3 or 4.0.2. What error are
you getting?

-- 
albert chin ([EMAIL PROTECTED])

Re: Question concerning shared libraries in non-standard locations

2006-06-25 Thread Albert Chin 
On Sun, Jun 25, 2006 at 07:47:52PM -0400, Paul Hilfinger wrote:
> 
> I have a situation (on Linux or Solaris, at least), in which I
> install versions of GCC in non-standard directories (specifically,
> directories not owned & operated by root).  With such an
> installation, when a GCC link finds a definition of an external
> reference in a shared library that is part of the .../lib
> subdirectory used by this installation, it treats the shared library
> as if it were also installed in one of the standard locations known
> to the dynamic linker, and does NOT store the path to the directory
> in which that library is found.  The result is that to run the
> linked executable, one must either 

So you simply want the RPATH entry in the executable created by "gcc
-o foo foo.c" to contain an entry to locate libgcc.so and
libstdc++.so?

You can modify the specs file to _automatically_ add the -R/-Wl,-rpath
when linking. Below is a possible patch for the GCC 4.0.2 specs file
to accomplish it for Solaris. Linux is handled in a similar way.

-- 
albert chin ([EMAIL PROTECTED])

-- snip snip
--- specs.orig  Sun Jun 25 23:30:01 2006
+++ specs   Fri Oct 21 00:05:58 2005
@@ -173,6 +173,12 @@
 *link_arch:
 %{m32:%(link_arch32)} %{m64:%(link_arch64)} 
%{!m32:%{!m64:%(link_arch_default)}} 
 
+*rpath:
+-R[gcc library path]
+
+*rpath64:
+-R[gcc library path]/sparcv9
+
 *link_command:
-%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %{pie:} %X %{o*} 
%{A} %{d} %{e*} %{m} %{N} %{n} %{r}%{s} %{t} %{u*} %{x} %{z} %{Z} 
%{!A:%{!nostdlib:%{!nostartfiles:%S}}}%{static:} %{L*} %(mfwrap) 
%(link_libgcc) %o %(mflib)%{fprofile-arcs|fprofile-generate:-lgcov}
%{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}}
%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}
+%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %{pie:} %X %{o*} 
%{A} %{d} %{e*} %{m} %{N} %{n} %{r}%{s} %{t} %{u*} %{x} %{z} %{Z} 
%{!A:%{!nostdlib:%{!nostartfiles:%S}}}%{static:} %{L*} %(mfwrap) 
%(link_libgcc) %o %(mflib)%{fprofile-arcs|fprofile-generate:-lgcov}
%{!nostdlib:%{!nodefaultlibs:%{!m64:%(rpath)} %{m64:%(rpath64)} 
%(link_gcc_c_sequence)}}%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}

Re: Question concerning shared libraries in non-standard locations

2006-06-27 Thread Albert Chin 
On Tue, Jun 27, 2006 at 03:48:30AM -0400, Paul Hilfinger wrote:
> 
> I guess that I'm simply suggesting that it might be nice if the sort
> of modification suggested by Albert Chin's response to my question
> could be installed automatically under control of a configuration
> option (e.g.), or as a result of the configuration script's detecting
> a non-standard prefix.  (Well, actually, I think his patch has to
> modified for recent versions; doesn't 4.x compile them into the source
> files?).

I think newer GCC releases (dunno when it started) do not install a
specs file. However, there is a "gcc -dumpspecs" option to print the
specs file so you can save it to the default location GCC would read
it from if the specs file existed.

However, the solution I posted will only work on some platforms. It
won't work on HP-UX/IA, Tru64, nor AIX. Why? Because, on these
systems, the runtime path option (+b, -rpath, -blibpath) is not
additive (i.e. you cannot use these options more than once on the
command-line).

-- 
albert chin ([EMAIL PROTECTED])