Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li

Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li

[Bruno Haible]

The following reply was made to PR java/7169; it has been noted by GNATS.

From: Bruno Haible <bruno@clisp.org>
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: tromey@redhat.com, dave.anglin@nrc.ca, gcc-gnats@gcc.gnu.org
Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li
Date: Tue, 2 Jul 2002 21:48:09 +0200 (CEST)

 John David Anglin writes:
 
 > If I specify --prefix=/opt/gnu and --with-libiconv-prefix=/opt/gnu, then
 > the libiconv configure test for libiconv fails:
 > 
 > configure:4457: checking for iconv
 > configure:4475: cc -o conftest -g  -I/opt/gnu/include  conftest.c  1>&5
 > (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C pro
 > duct; ignored.
 > (Bundled) cc: "/opt/gnu/include/iconv.h", line 72: warning 5: "const" will becom
 > e a keyword.
 > (Bundled) cc: "/opt/gnu/include/iconv.h", line 72: error 1000: Unexpected symbol
 > : "char".
 
 That's a different thing; you built and installed libiconv with an
 ANSI C compiler, and now you go back to a non-ANSI C compiler. Why
 don't you use "cc -Ae" instead of "cc" to bootstrap gcc? Why doesn't
 gcc by itself add the "-Ae" when it sees an HP-UX compiler?
 
 Bruno

Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li

[Bruno Haible]

The following reply was made to PR java/7169; it has been noted by GNATS.

From: Bruno Haible <bruno@clisp.org>
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: tromey@redhat.com, dave.anglin@nrc.ca, gcc-gnats@gcc.gnu.org
Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li
Date: Wed, 3 Jul 2002 15:35:44 +0200 (CEST)

 John David Anglin writes:
 
 > > libiconv installs its header in $prefix/include and its library in
 > > $prefix/lib. If gcc now looks in one of these directories but not the
 > > other, you get the link error that you saw.
 > 
 > If I add "-liconv" to the link command for jc1, the link is successful.
 
 Good. That excludes my prior hypothesis.
 
 > The reason that there isn't a library specification in the command is
 > that the HP iconv routines are in libc and those were the ones found
 > by configure.
 
 Which means that the aclocal.m4 macros are outdated and ought to be
 upgraded to gettext 0.11.2.
 
 Bruno

Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li

[Bruno Haible]

The following reply was made to PR java/7169; it has been noted by GNATS.

From: Bruno Haible <bruno@clisp.org>
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: tromey@redhat.com, dave.anglin@nrc.ca, gcc-gnats@gcc.gnu.org
Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li
Date: Wed, 3 Jul 2002 15:34:17 +0200 (CEST)

 John David Anglin writes:
 > > That's a different thing; you built and installed libiconv with an
 > > ANSI C compiler, and now you go back to a non-ANSI C compiler. Why
 > > don't you use "cc -Ae" instead of "cc" to bootstrap gcc? Why doesn't
 > > gcc by itself add the "-Ae" when it sees an HP-UX compiler?
 > 
 > The "-Ae" option requires purchase of the optional HP ANSI C
 > compiler.
 
 I see.
 
 > Are you saying, that if I build libiconv with a traditional
 > compiler, it will install a header file that is compatible with a
 > traditional compiler?
 
 No, I am saying that libiconv is only buildable with an ANSI C
 compiler, and its installed header file works only with an ANSI C or
 C++ compiler.
 
 So if you insist on using a K&R C compiler, you have to hide
 libiconv's installed file from it - either by doing "make uninstall"
 in libiconv's builddir, or by choosing a different --prefix for gcc.
 
 > If this were fixed, then ...
 
 I won't "fix" this. ANSI C is the standard now. Until you have an ANSI
 C compiler, I'd recommend to not install libiconv. Then, when you have
 bootstrapped gcc once, you can install libiconv, gettext and then
 rebuild gcc with --enable-nls.
 
 Bruno

Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li

[John David Anglin]

The following reply was made to PR java/7169; it has been noted by GNATS.

From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: tromey@redhat.com
Cc: dave.anglin@nrc.ca, gcc-gnats@gcc.gnu.org, bruno@clisp.org
Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li
Date: Tue, 2 Jul 2002 18:58:14 -0400 (EDT)

 > Maybe the problem here is simply a lack of documentation on telling
 > configure about libiconv?  I could write a doc patch...?  You can use
 > --with-libiconv-prefix=/prefix to tell configure where to find libiconv.
 > Does doing this cure the problem?
 
 Summary:
 
 1) The GNU and HP versions of iconv.h are incompatible.  If the GNU
    version is visible to gcc, then using --with-libiconv-prefix=/prefix
    where /prefix is the prefix of GNU libiconv works when building
    with cc.  However, libiconv is not used for the build because
    the GNU header is incompatible with the traditional compiler
    being used.  There could be a small update to the documentation
    for the --with-libiconv-prefix option.  However, I'm going to
    close the PR since most users will not encounter this problem.
 
 2) Fastjar doesn't build when starting with the HP bundled compiler.
    Since this uses the stage1 compiler, could building fastjar
    be disabled if the stage1 compiler doesn't define __STDC__?  Another
    way could be a --disable-fastjar option.
 
 Dave
 -- 
 J. David Anglin                                  dave.anglin@nrc.ca
 National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li

[John David Anglin]

The following reply was made to PR java/7169; it has been noted by GNATS.

From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: bruno@clisp.org (Bruno Haible)
Cc: tromey@redhat.com, dave.anglin@nrc.ca, gcc-gnats@gcc.gnu.org
Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li
Date: Tue, 2 Jul 2002 17:21:03 -0400 (EDT)

 > Dave Anglin writes:
 > 
 > > I think what is happening is that the GNU version of
 > > libiconv installed in /opt/gnu is not found
 > > ...
 > > ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared
 > --disable-nls --prefix=/opt/gnu
 > 
 > It is generally a bad idea to configure and install *any* program or
 > library with the same --prefix as you use for configuring gcc. The
 > reason is that many gcc versions/installations are broken in the sense
 > that they will look for include files in $prefix/include but not look
 > for libraries in $prefix/lib - or vice versa.
 
 I haven't found this to be a problem.  You just have to realize that
 include directories and libraries are located relative to the installation
 location for cc1.  For example, gcc adds the following
 
   -L/opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.11/3.1.1/../../..)
 
 when linking.  As long as you ensure that the above is equivalent to
 
   -L/opt/gnu/lib
 
 then everything seems to work fine.
 
 There are issues about installing multiple versions of gcc and how
 best to do that.  I have come to the conclusion that it's best to
 put the default version of gcc at the same prefix as used for other
 GNU packages (every version of linux that I have seen installs gcc
 with the prefix /usr) and install test versions elsewhere.  I
 believe that there are problems using transform names with ada
 so I don't think they are a workable option.
 
 > libiconv installs its header in $prefix/include and its library in
 > $prefix/lib. If gcc now looks in one of these directories but not the
 > other, you get the link error that you saw.
 
 If I add "-liconv" to the link command for jc1, the link is successful.
 The reason that there isn't a library specification in the command is
 that the HP iconv routines are in libc and those were the ones found
 by configure.
 
 Dave
 -- 
 J. David Anglin                                  dave.anglin@nrc.ca
 National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li

[John David Anglin]

The following reply was made to PR java/7169; it has been noted by GNATS.

From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: bruno@clisp.org (Bruno Haible)
Cc: tromey@redhat.com, dave.anglin@nrc.ca, gcc-gnats@gcc.gnu.org
Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li
Date: Tue, 2 Jul 2002 16:48:51 -0400 (EDT)

 > That's a different thing; you built and installed libiconv with an
 > ANSI C compiler, and now you go back to a non-ANSI C compiler. Why
 > don't you use "cc -Ae" instead of "cc" to bootstrap gcc? Why doesn't
 > gcc by itself add the "-Ae" when it sees an HP-UX compiler?
 
 Because, I am testing the bootstrap process with the traditional
 HP compiler to ensure that it works.  Currently, I am focusing
 on 3.1.1 (see <http://gcc.gnu.org/ml/gcc/2002-06/msg00871.html> and 
 <http://gcc.gnu.org/ml/gcc/2002-06/msg01660.html>).
 
 The "-Ae" option requires purchase of the optional HP ANSI C
 compiler.
 
 Are you saying, that if I build libiconv with a traditional
 compiler, it will install a header file that is compatible with a
 traditional compiler?  I looked at this.  It appears that the only
 configuration option in libiconv-1.7 is @ICONV_CONST@ and that
 the declarations in the header still wouldn't be compatible with
 a traditional compiler.
 
 If this were fixed, then it seems as if I could specify the
 installation location for the GNU libiconv with --with-libiconv-prefix,
 and things would work.
 
 Dave
 -- 
 J. David Anglin                                  dave.anglin@nrc.ca
 National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li

[John David Anglin]

The following reply was made to PR java/7169; it has been noted by GNATS.

From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: tromey@redhat.com
Cc: dave.anglin@nrc.ca, gcc-gnats@gcc.gnu.org, bruno@clisp.org
Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li
Date: Tue, 2 Jul 2002 14:45:43 -0400 (EDT)

 > >>>>> "Dave" == dave anglin <dave.anglin@nrc.ca> writes:
 > 
 > Dave> I think what is happening is that the GNU version of
 > Dave> libiconv installed in /opt/gnu is not found because
 > Dave> the GNU iconv.h has "const" in the prototype for
 > Dave> iconv_open:
 > 
 > You can check this theory by looking in config.log.
 > What does it say?  Any of the entries related to iconv would be
 > interesting.
 
 On closer inspection today, I realize that I was somewhat confused about
 the above.  The above only happens when --with-libiconv-prefix is
 specified as /opt/gnu.  Without --with-libiconv-prefix, the config.log is
 
 configure:4457: checking for iconv
 configure:4475: cc -o conftest -g   conftest.c  1>&5
 (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C pro
 duct; ignored.
 configure:4518: checking for iconv declaration
 configure:4543: cc -c -g  conftest.c 1>&5
 (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C pro
 duct; ignored.
 
 and the result is
 
 checking for iconv... yes
 checking for iconv declaration... 
          extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
 
 So, the use of iconv is enabled by the system version of iconv.  The system
 iconv.h header is in /usr/include and the routines in libc.  This is the
 situation where the build failure occurs.
 
 > Dave> However, gcc uses the GNU iconv.h header in the build.
 
 If configure determines that the system has the iconv function,
 Gcc will use the GNU iconv.h header in the build if it is installed
 in $(includedir) or $(local_includedir), the directory for site-specific
 includes.  
 
 The GNU iconv.h redefines iconv, iconv_open, iconv_close except when
 LIBICONV_PLUG is defined.  If the GNU header is used, then "-liconv"
 needs to be added to the link command to link with the GNU library.
 This works without a problem in builds starting with gcc if the
 directory $(libsubdir) exists.
 
 > 
 > Maybe the problem here is simply a lack of documentation on telling
 > configure about libiconv?  I could write a doc patch...?  You can use
 > --with-libiconv-prefix=/prefix to tell configure where to find libiconv.
 > Does doing this cure the problem?
 
 If I specify --prefix=/opt/gnu and --with-libiconv-prefix=/opt/gnu, then
 the libiconv configure test for libiconv fails:
 
 configure:4457: checking for iconv
 configure:4475: cc -o conftest -g  -I/opt/gnu/include  conftest.c  1>&5
 (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C pro
 duct; ignored.
 (Bundled) cc: "/opt/gnu/include/iconv.h", line 72: warning 5: "const" will becom
 e a keyword.
 (Bundled) cc: "/opt/gnu/include/iconv.h", line 72: error 1000: Unexpected symbol
 : "char".
 (Bundled) cc: "/opt/gnu/include/iconv.h", line 72: warning 5: "const" will becom
 e a keyword.
 (Bundled) cc: "/opt/gnu/include/iconv.h", line 72: error 1000: Unexpected symbol
 : "char".
 (Bundled) cc: "/opt/gnu/include/iconv.h", line 72: error 1705: Function prototyp
 es are an ANSI feature.
 (Bundled) cc: "/opt/gnu/include/iconv.h", line 82: error 1000: Unexpected symbol
 : "libiconv".
 
 and we have
 
 /* Define if you have the iconv() function. */
 /* #undef HAVE_ICONV */
 
 /* Define as const if the declaration of iconv() needs const. */
 /* #undef ICONV_CONST */
 
 As a result, I believe that the build will be successful (it's past the
 previous failure point).
 
 Dave
 -- 
 J. David Anglin                                  dave.anglin@nrc.ca
 National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li

[John David Anglin]

The following reply was made to PR java/7169; it has been noted by GNATS.

From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: dave@hiauly1.hia.nrc.ca (John David Anglin)
Cc: tromey@redhat.com, dave.anglin@NRC.CA, gcc-gnats@gcc.gnu.org,
   bruno@clisp.org
Subject: Re: java/7169: /usr/ccs/bin/ld: Unsatisfied symbols: libiconv, li
Date: Tue, 2 Jul 2002 14:58:34 -0400 (EDT)

 > As a result, I believe that the build will be successful (it's past the
 > previous failure point).
 
 I spoke too soon:
 
 make[2]: Entering directory `/xxx/gnu/gcc-3.2/objdir/fastjar'
 cc -DHAVE_CONFIG_H -I. -I../../gcc/fastjar -I. -I. -I../../gcc/fastjar -I../../g
 cc/fastjar/../zlib -I../../gcc/fastjar/../include    -g -c ../../gcc/fastjar/jar
 tool.c
 (Bundled) cc: warning 480: The -g option is available only with the C/ANSI C pro
 duct; ignored.
 (Bundled) cc: "../../gcc/fastjar/dostime.h", line 20: error 1705: Function proto
 types are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/dostime.h", line 21: error 1705: Function proto
 types are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/dostime.h", line 22: error 1000: Unexpected sym
 bol: "*".
 (Bundled) cc: "../../gcc/fastjar/dostime.h", line 22: error 1506: Parameters all
 owed in function definition only.
 (Bundled) cc: "../../gcc/fastjar/pushback.h", line 22: error 1000: Unexpected sy
 mbol: "ub1".
 (Bundled) cc: "../../gcc/fastjar/pushback.h", line 22: error 1573: Type of "pb_b
 uff" is undefined due to an illegal declaration.
 (Bundled) cc: "../../gcc/fastjar/pushback.h", line 22: error 1578: Size of struc
 t or union member is unknown.
 (Bundled) cc: "../../gcc/fastjar/pushback.h", line 30: error 1000: Unexpected sy
 mbol: "*".
 (Bundled) cc: "../../gcc/fastjar/pushback.h", line 30: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/pushback.h", line 30: error 1573: Type of "<<<N
 ULL_SYMBOL>>>" is undefined due to an illegal declaration.
 (Bundled) cc: "../../gcc/fastjar/pushback.h", line 31: error 1000: Unexpected sy
 mbol: "*".
 (Bundled) cc: "../../gcc/fastjar/pushback.h", line 31: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/pushback.h", line 31: error 1573: Type of "<<<N
 ULL_SYMBOL>>>" is undefined due to an illegal declaration.
 (Bundled) cc: "../../gcc/fastjar/pushback.h", line 32: error 1000: Unexpected sy
 mbol: "*".
 (Bundled) cc: "../../gcc/fastjar/pushback.h", line 32: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/pushback.h", line 32: error 1573: Type of "<<<N
 ULL_SYMBOL>>>" is undefined due to an illegal declaration.
 (Bundled) cc: "../../gcc/fastjar/compress.h", line 74: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/compress.h", line 77: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/compress.h", line 80: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/compress.h", line 82: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/compress.h", line 83: error 1000: Unexpected sy
 mbol: "*".
 (Bundled) cc: "../../gcc/fastjar/compress.h", line 83: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/compress.h", line 83: error 1573: Type of "<<<N
 ULL_SYMBOL>>>" is undefined due to an illegal declaration.
 (Bundled) cc: "../../gcc/fastjar/compress.h", line 84: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/compress.h", line 85: error 1000: Unexpected sy
 mbol: "*".
 (Bundled) cc: "../../gcc/fastjar/compress.h", line 85: error 1000: Unexpected sy
 mbol: "*".
 (Bundled) cc: "../../gcc/fastjar/compress.h", line 85: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/compress.h", line 85: error 1573: Type of "<<<N
 ULL_SYMBOL>>>" is undefined due to an illegal declaration.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 261: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 262: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 263: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 264: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 265: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 267: error 1000: Unexpected sy
 mbol: "*".
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 267: error 1506: Parameters al
 lowed in function definition only.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 268: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 269: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 270: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 271: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 272: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 273: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 274: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 275: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 276: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 277: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 316: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 666: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 679: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 812: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 967: error 1705: Function prot
 otypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1113: error 1705: Function pro
 totypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1253: error 1705: Function pro
 totypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1276: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1286: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1300: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1312: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1358: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1472: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1486: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1513: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1546: error 1705: Function pro
 totypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1704: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1709: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1724: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1738: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1787: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1804: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1841: error 1000: Unexpected s
 ymbol: "*".
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1841: error 1705: Function pro
 totypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1841: error 1573: Type of "pbf
 " is undefined due to an illegal declaration.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1851: warning 563: Argument #1
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1851: warning 563: Argument #2
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1851: warning 527: Integral va
 lue implicitly converted to pointer in assignment.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1851: warning 563: Argument #3
  is not the correct type.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1865: error 1705: Function pro
 totypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1881: error 1705: Function pro
 totypes are an ANSI feature.
 (Bundled) cc: "../../gcc/fastjar/jartool.c", line 1936: error 1705: Function pro
 totypes are an ANSI feature.
 
 Dave
 -- 
 J. David Anglin                                  dave.anglin@nrc.ca
 National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)