[Bug target/46655] New: AIX6.1 native assembler requires '.line' numbers greater than zero

[Bug target/46655] New: AIX6.1 native assembler requires '.line' numbers greater than zero

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

           Summary: AIX6.1 native assembler requires '.line' numbers
                    greater than zero
           Product: gcc
           Version: 4.5.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: michael.haubenwallner@salomon.at


Bootstrapping gcc-4.5.1 on AIX6.1 with recent native assembler fails with:

/build/gcc/./gcc/xgcc -B/build/gcc/./gcc/
-B/install/powerpc-ibm-aix6.1.0.0/bin/ -B/install/powerpc-ibm-aix6.1.0.0/lib/
-isystem /install/powerpc-ibm-aix6.1.0.0/include -isystem
/install/powerpc-ibm-aix6.1.0.0/sys-include    -g -O2 -pthread -O2  -g -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include 
-mlong-double-128 -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
 -I. -I. -I../../.././gcc -I/source/gcc-4.5.1/libgcc
-I/source/gcc-4.5.1/libgcc/. -I/source/gcc-4.5.1/libgcc/../gcc
-I/source/gcc-4.5.1/libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o _mul_sf.o
-MT _mul_sf.o -MD -MP -MF _mul_sf.dep -DFINE_GRAINED_LIBRARIES -DL_mul_sf -c
../../.././gcc/fp-bit.c  
Assembler:
/tmp//ccI8aKR8.s: line 160: 1252-040 The specified expression is not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.
gmake[5]: *** [_mul_sf.o] Error 1
gmake[5]: Leaving directory `/build/gcc/powerpc-ibm-aix6.1.0.0/pthread/libgcc'
gmake[4]: *** [multi-do] Error 1
gmake[4]: Leaving directory `/build/gcc/powerpc-ibm-aix6.1.0.0/libgcc'
gmake[3]: *** [all-multi] Error 2
gmake[3]: Leaving directory `/build/gcc/powerpc-ibm-aix6.1.0.0/libgcc'
gmake[2]: *** [all-stage1-target-libgcc] Error 2
gmake[2]: Leaving directory `/build/gcc'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/build/gcc'
gmake: *** [bootstrap] Error 2

Running that xgcc command with "-save-temps -v" tells:
 /build/gcc/./gcc/as -u -mppc -o _mul_sf.o fp-bit.s
Assembler:
fp-bit.s: line 160: 1252-040 The specified expression is not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.

The line 160 in fp-bit.s is:
160    .line   0

Although this was accepted before installing AIX patch SP6100-04-07-1036, it is
questionable what a line-number zero is for. Also I've found this old message:
http://gcc.gnu.org/ml/gcc-bugs/1999-12/msg00088.html

[Bug target/46655] AIX6.1 native assembler requires '.line' numbers greater than zero

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

Michael Haubenwallner <michael.haubenwallner at salomon dot at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |powerpc-ibm-aix6.1.0.0
               Host|                            |powerpc-ibm-aix6.1.0.0
      Known to fail|                            |4.2.4
              Build|                            |powerpc-ibm-aix6.1.0.0

--- Comment #1 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2010-11-25 10:17:31 UTC ---
The configure arguments used were:
$ /source/gcc-4.5.1.pr46655/configure --{prefix,with-{gmp,mpfr,mpc}}=/install

As the bootstrap compiler gcc-4.2.0 from "AIX Toolbox for Linux Applications"
has the same problem, and this is debug-info only, '-O' was used as workaround:
$ gmake bootstrap STAGE1_CFLAGS=-O

[Bug target/46655] invalid '.line 0' directive emitted with -g

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.11.25 11:15:26
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org, hainque at gcc dot
                   |                            |gnu.org
            Summary|AIX6.1 native assembler     |invalid '.line 0' directive
                   |requires '.line' numbers    |emitted with -g
                   |greater than zero           |
     Ever Confirmed|0                           |1

--- Comment #2 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-25 11:15:26 UTC ---
BFD also complains about this.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #3 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2010-11-25 12:30:37 UTC ---
Huh - AIX-as also doesn't accept line numbers >=65536 any more since
SP6100-04-07-1036 it seems, as I get an error on ".line 118674" from
insn-automata.c later in bootstrap of gcc-4.5.1, after modifying gcc/xcoffout.c
to emit line numbers >0 only.

For reference:
$ cat test.s
        .line   1
        .line   -1      # invalid: ok
        .line   0       # invalid: ok
        .line   65536   # invalid: huh?
        .line   65535
$ /usr/bin/as -u -mppc test.s
Assembler:
test.s: line 2: 1252-040 The specified expression is not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.
test.s: line 3: 1252-040 The specified expression is not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.
test.s: line 4: 1252-040 The specified expression is not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.

While line numbers <=0 is this one gcc bug, IMO not accepting line numbers
>=64k is an AIX-as bug.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #4 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2010-11-26 13:54:41 UTC ---
Created attachment 22538
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22538
Workaround to emit .line values >0 and <64k only

For now, I'm using this patch to get the debug-info working good enough for me.
However, I don't believe this is the proper fix.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #5 from David Edelsohn <dje at gcc dot gnu.org> 2010-11-29 00:17:54 UTC ---
Has anyone reported this AIX assembler behavior to IBM?  It would be much more
effective coming from an external customer than from me.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #6 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2010-11-29 09:05:53 UTC ---
I'm in contact with IBM vi a customer's support channel - initially for another
problem, and have added this 64k-line-limit recently.
Although no reply yet, I'll add updates here when available.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-29 09:09:21 UTC ---
The compiler needs to be prevented from emitting .line 0 in any case since BFD
also chokes on that.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[hainque at adacore dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #8 from hainque at adacore dot com <hainque at adacore dot com> 2010-11-29 09:17:03 UTC ---
dje at gcc dot gnu.org wrote:

> Has anyone reported this AIX assembler behavior to IBM?  It would be
> much more effective coming from an external customer than from me.

 We haven't done that on our side. We haven't observed the 64K limit.

 We had observed the 0 case and thought it was legitimate to
 consider this invalid, so came up with a change close to what was
 suggested upthread, with comments on their possible origin after
 investgation. (attached)

 I can provide a testcase that triggered on 4.5 at least.

 Olivier

[Bug target/46655] invalid '.line 0' directive emitted with -g

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #9 from David Edelsohn <dje at gcc dot gnu.org> 2010-11-29 22:28:20 UTC ---
If I understand correctly, the line 0 error occurs in both AIX and BFD, so it
is not a bug.  Did something change in GCC that now generates line 0 debug
information?

Is the 64K limit really new?  Is this really a change in AIX as or did
something else change and start generating files referencing line numbers
larger than 64K?

I believe the line number field in XCOFF is defined in /usr/include/linenum.h. 
According to that file, in 32 bit mode, line numbers are represented by an
unsigned short, whose maximum value is 65535.  In 64 bit mode, line numbers are
represented by unsigned int.

I have not seen this error while bootstrapping GCC on AIX.  The error looks
correct.  What else changed?

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #10 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2010-11-30 12:22:43 UTC ---
(In reply to comment #9)
> I believe the line number field in XCOFF is defined in /usr/include/linenum.h. 
> According to that file, in 32 bit mode, line numbers are represented by an
> unsigned short, whose maximum value is 65535.  In 64 bit mode, line numbers are
> represented by unsigned int.

Ohw, indeed.

> Is the 64K limit really new?  Is this really a change in AIX as or did
> something else change and start generating files referencing line numbers
> larger than 64K?

AFAICS, AIX as changed somewhere around SP6100-04-07-1036 so that it actually
does check the 64k limit (as well as the zero limit) now. On AIX5.3, linenum.h
also declares l_lnno as unsigned short in 32bit, but the assembler does not
choke on any line in test.s from comment#3 there. 

> I have not seen this error while bootstrapping GCC on AIX.  The error looks
> correct.  What else changed?

Before installing SP6100-04-07-1036 I've also been able to bootstrap gcc-4.2.4
without any problems using AIX as/ld. But this is broken since
SP6100-04-07-1036 is installed.

However - as a side note, applying attachment#22583 to gcc-4.2.4 breaks
bootstrapping gcc-4.2.4 even on AIX 5.3 (which doesn't choke on .line <=0 or
>=64k) both with and without STAGE1_CFLAGS=-O (to not trigger this problem in
the gcc used to bootstrap) with 'Bootstrap comparison failure' due to different
.line numbers in stage 2 and 3.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

Michael Haubenwallner <michael.haubenwallner at salomon dot at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #22538|0                           |1
        is obsolete|                            |

--- Comment #11 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2010-11-30 15:22:36 UTC ---
Created attachment 22580
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22580
emit unsigned .line values >0, and <64k in 32bit mode

Based on comment#9 this patch now emits the line number:
* as unsigned int ("%u"),
* when >0,
* when <64k (<=USHRT_MAX) in 32bit mode.

However, I still do think filtering for line>0 here is a workaround, as invalid
line numbers shouldn't reach the emit-function at all.

(In reply to comment #10)
> applying attachment#22583 to gcc-4.2.4 breaks bootstrapping gcc-4.2.4

This was because variable 'line' got hidden in that patch.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #12 from David Edelsohn <dje at gcc dot gnu.org> 2010-11-30 15:43:15 UTC ---
I assume that SP6100-04-07-1036 added a bounds error check for the line number
in the assembler, which previously ignored the overflow.  I don't know what AIX
as did internally (truncate?  wrap?).  Fixing GCC seems to be the correct
solution.

The patch seems reasonable and I don't know what better one could do.  If
everyone else is satisfied, please post the patch to the gcc-patches
mailinglist.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[hainque at adacore dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #13 from hainque at adacore dot com <hainque at adacore dot com> 2010-11-30 17:49:20 UTC ---
dje at gcc dot gnu.org wrote:
> Did something change in GCC that now generates line 0 debug
> information?

 For Ada cases, we had mixups with BUILTINS_LOCATION. The testcase below
 triggered it for entirely different reasons in C with at least 4.5, and
 supposedly on.

 While there are multiple factors at play, I think one triggering piece
 was a change issued from

  http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00649.html

 In particular:

   --- c-parser.c    (revision 140120)
   +++ c-parser.c    (working copy)
   @@ -1301,9 +1301,9 @@ c_parser_declaration_or_fndef (c_parser 
      while (c_parser_next_token_is_not (parser, CPP_EOF)
        && c_parser_next_token_is_not (parser, CPP_OPEN_BRACE))
       c_parser_declaration_or_fndef (parser, false, false, true, false);
   -      DECL_SOURCE_LOCATION (current_function_decl)
   -    = c_parser_peek_token (parser)->location;
      store_parm_decls ();
   +      DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus
   +    = c_parser_peek_token (parser)->location;


 for "__frame_state_for" at line 9 in the example below, we used to have 

 <function_decl 0x7ffff7f4d3c0 __frame_state_for
    public static SI file /home/hainque/tmp/t.c line 10 col 1
                                                ^^^^^^^
 and we now have line 9 instead.

 Later on, code get that loc assigned, which translates as .line 0
 now (used to be .line 1).

 --

  1 const int NREGS = 20;
  2 
  3 typedef struct frame_state
  4 {
  5   void *eh_ptr;
  6   char saved[20];
  7 } frame_state;
  8 
  9 void __frame_state_for (struct frame_state *state_in)
 10 {
 11   int reg;
 12 
 13   for (reg = 0; reg < NREGS; reg++)
 14     state_in->saved[reg] = 0;
 15 }
 16

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #14 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2010-12-13 12:46:25 UTC ---
(In reply to comment #9)
> Is the 64K limit really new?  Is this really a change in AIX as or did
> something else change and start generating files referencing line numbers
> larger than 64K?
> 
> I believe the line number field in XCOFF is defined in /usr/include/linenum.h. 
> According to that file, in 32 bit mode, line numbers are represented by an
> unsigned short, whose maximum value is 65535.  In 64 bit mode, line numbers are
> represented by unsigned int.
> 
> I have not seen this error while bootstrapping GCC on AIX.  The error looks
> correct.  What else changed?

Update from IBM customer support:
Pseudo operation '.line' "works as designed".
However, the bounds checking was introduced in "AIX 6.1 TL04 SP07" and similar
SP's for other TL's.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2010-11/msg02928.htm
                   |                            |l
           Severity|normal                      |major

[Bug target/46655] invalid '.line 0' directive emitted with -g

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #15 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-01-17 12:35:26 UTC ---
Author: ebotcazou
Date: Mon Jan 17 12:35:21 2011
New Revision: 168897

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168897
Log:
    PR target/46655
    * xcoffout.c (ASM_OUTPUT_LINE): Output line only if positive, and only
    if <= USHRT_MAX in 32-bit mode.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/xcoffout.c

[Bug target/46655] invalid '.line 0' directive emitted with -g

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-01-17 12:37:00 UTC ---
Author: ebotcazou
Date: Mon Jan 17 12:36:55 2011
New Revision: 168898

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168898
Log:
    PR target/46655
    * xcoffout.c (ASM_OUTPUT_LINE): Output line only if positive, and only
    if <= USHRT_MAX in 32-bit mode.

Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/xcoffout.c

[Bug target/46655] invalid '.line 0' directive emitted with -g

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.3

--- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-01-17 12:38:51 UTC ---
Fixed in 4.5.x and later.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[richard.nolde at cybox dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

Richard Nolde <richard.nolde at cybox dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard.nolde at cybox dot
                   |                            |com

--- Comment #18 from Richard Nolde <richard.nolde at cybox dot com> 2011-02-24 01:16:22 UTC ---
I'm building gcc-4.5.0 from the current GNU archive on AIX 6.1 (oslevel -s
returns 6100-06-03-1048) using gcc 4.2.4 and the native AIX ld, as, ar, nm, and
ranlib. I do not have any GNU binutils packages installed but I do have bash,
GNU make, and a full compliment of GNU tools in the /opt/freeware tree where
they are typically installed on AIX. I've built numerous other large open
source packages successfully.

I've applied the patch to gcc/xcoffout.c that is provided at the bottom of this
thread. Configure runs successfully but the build fails at this point (full
logs of configure and make output are available:
/usr/bin/gcc  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H
-DGENERATOR_FILE -Wl,-bbigtoc -o build/genattrtab \
    build/genattrtab.o build/rtl.o build/read-rtl.o build/ggc-none.o
build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o
build/errors.o ../../build-powerpc-ibm-aix6.1.0.0/libiberty/libiberty.a
build/genattrtab ../.././gcc/config/rs6000/rs6000.md \
  insn-conditions.md > tmp-attrtab.c
/bin/sh ../.././gcc/../move-if-change tmp-attrtab.c insn-attrtab.c
echo timestamp > s-attrtab
/usr/bin/gcc -c  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../.././gcc -I../.././gcc/. -I../.././gcc/../include
-I../.././gcc/../libcpp/include  -I../.././gcc/../libdecnumber
-I../.././gcc/../libdecnumber/dpd -I../libdecnumber    -I/opt/freeware/include
insn-attrtab.c -o insn-attrtab.o
Assembler:
/ramdisk/udttmp/ccxcYMAe.s: line 26089: 1252-040 The specified expression is
not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.
/ramdisk/udttmp/ccxcYMAe.s: line 27243: 1252-040 The specified expression is
not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.
/ramdisk/udttmp/ccxcYMAe.s: line 27879: 1252-040 The specified expression is
not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.
....
Many more lines of the same error messages followed by:
/ramdisk/udttmp/ccxcYMAe.s: line 139907: 1252-040 The specified expression is
not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.
/ramdisk/udttmp/ccxcYMAe.s: line 141711: 1252-040 The specified expression is
not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.
/ramdisk/udttmp/ccxcYMAe.s: line 143385: 1252-040 The specified expression is
not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.
/ramdisk/udttmp/ccxcYMAe.s: line 144343: 1252-040 The specified expression is
not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.

/ramdisk/udttmp/ccxcYMAe.s: line 146123: 1252-040 The specified expression is
not valid.
        Make sure that all symbols are defined.
        Check the rules on symbols used in an arithmetic expression
        concerning relocation.
gmake[3]: *** [insn-attrtab.o] Error 1
gmake[3]: Leaving directory
`/devel/opensource/gcc/gcc-4.5.0/host-powerpc-ibm-aix6.1.0.0/gcc'
gmake[2]: *** [all-stage1-gcc] Error 2
gmake[2]: Leaving directory `/devel/opensource/gcc/gcc-4.5.0'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/devel/opensource/gcc/gcc-4.5.0'
make: *** [all] Error 2

Let me know if I can provide additional information or logs. It appears that
line numbers are exceeding 65536 for at least some of the errors.
I have run make distclean between each build followed by ./configure
--prefix=/opt/freeware and configure seems to find the correct native utilities
without a problem.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #19 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-02-24 09:26:58 UTC ---
> /usr/bin/gcc -c  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
> -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
> -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I.
> -I../.././gcc -I../.././gcc/. -I../.././gcc/../include
> -I../.././gcc/../libcpp/include  -I../.././gcc/../libdecnumber
> -I../.././gcc/../libdecnumber/dpd -I../libdecnumber    -I/opt/freeware/include
> insn-attrtab.c -o insn-attrtab.o

This is a problem in /usr/bin/gcc, not in the GCC sources you're compiling.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #20 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-02-24 20:42:46 UTC ---
(In reply to comment #19)
> > /usr/bin/gcc -c  -g -fkeep-inline-functions -DIN_GCC ...
> 
> This is a problem in /usr/bin/gcc, not in the GCC sources you're compiling.

(In reply to comment #1)
> $ gmake bootstrap STAGE1_CFLAGS=-O

Richard, does this workaround work for you?

[Bug target/46655] invalid '.line 0' directive emitted with -g

[richard.nolde at cybox dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #21 from Richard Nolde <richard.nolde at cybox dot com> 2011-02-24 20:53:42 UTC ---
On 02/24/2011 01:42 PM, michael.haubenwallner at salomon dot at wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
>
> --- Comment #20 from Michael Haubenwallner<michael.haubenwallner at salomon dot at>  2011-02-24 20:42:46 UTC ---
> (In reply to comment #19)
>    
>>> /usr/bin/gcc -c  -g -fkeep-inline-functions -DIN_GCC ...
>>>        
>> This is a problem in /usr/bin/gcc, not in the GCC sources you're compiling.
>>      
> (In reply to comment #1)
>    
>> $ gmake bootstrap STAGE1_CFLAGS=-O
>>      
> Richard, does this workaround work for you?
>    
I'll try it and see.  In the meantime, I tried using a SRC RPM for gcc 
4.4.0 instead 4.5.0 and got the same error at a different point in the 
build. I've contacted the builder of the GCC package for AIX, michael 
perzl at perlz.org, who builds his OpenSource packages with the IBM xlc 
compiler instead of with Gcc.  I don't like paying for IBMs compiler 
since their support is so expensive and their commitment to Open Source 
has fallen way off.  The versions of Open Source that they distribute, 
including Gcc are usually prehistoric and often don't even work. With 
Gcc 4.1.1, we had to get a consultant to rebuild it, but we traced that 
to the fact that the second stage build was trying to use the newly 
built ld from binutils, which will never work on AIX. The AIX linker is 
a world unto itself.

Michael Perzl has some AIX patches on his website for gcc that might be 
worth looking at but they are for older versions and they may not be 
correct.

I will test and get back to you.

Thanks,
Richard Nolde

Open Source Developer (tiffcrop from LibTiff )

[Bug target/46655] invalid '.line 0' directive emitted with -g

[richard.nolde at cybox dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #22 from Richard Nolde <richard.nolde at cybox dot com> 2011-02-24 22:27:13 UTC ---
On 02/24/2011 01:42 PM, michael.haubenwallner at salomon dot at wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
>
> --- Comment #20 from Michael Haubenwallner<michael.haubenwallner at salomon dot at>  2011-02-24 20:42:46 UTC ---
> (In reply to comment #19)
>    
>>> /usr/bin/gcc -c  -g -fkeep-inline-functions -DIN_GCC ...
>>>        
>> This is a problem in /usr/bin/gcc, not in the GCC sources you're compiling.
>>      
> (In reply to comment #1)
>    
>> $ gmake bootstrap STAGE1_CFLAGS=-O
>>      
> Richard, does this workaround work for you?
>
> I made it about 45 minutes into the build before the build died this
> >  time. I'll have to poke further, but it seems this one might be in the
> >  /devel/opensource/gcc/gcc-4.5.0/host-powerpc-ibm-aix6.1.0.0/gcc/nm
> >  script.  I'll have to rerun and capture everything to a log so see what
> >  is going on.  I did notice that there were numerous warnings that the
> >  configure script could not parse the output of /usr/bin/nm since at that
> >  point it didn't seem to realize that it need the -B switch. This
> >  behavior seems to depend on the version of libtool that was used to
> >  build the package.  Sometimes it works if you export NM="/usr/bin/nm -B"
> >  and other times it breaks if you add -B. I used to have my own script to
> >  extract the symbols into a file that could be used with the AIX linker.
> >  AIX's version of awk doesn't have gensub so it also helps to specify
> >  gawk instead of awk.  I also get different reports from configure
> >  scripts about whether the linker can build shared libraries and some
> >  scripts insist on building them with the .a extension instead of .so,
> >  with or without versioning.
> >  ...
> >  /bin/sh ./libtool --tag CC   --mode=link
> >  /devel/opensource/gcc/gcc-4.5.0/host-powerpc-ibm-aix6.1.0.0/gcc/xgcc
> >  -B/devel/opensource/gcc/gcc-4.5.0/host-powerpc-ibm-aix6.1.0.0/gcc/
> >  -B/opt/freeware/powerpc-ibm-aix6.1.0.0/bin/
> >  -B/opt/freeware/powerpc-ibm-aix6.1.0.0/lib/ -isystem
> >  /opt/freeware/powerpc-ibm-aix6.1.0.0/include -isystem
> >  /opt/freeware/powerpc-ibm-aix6.1.0.0/sys-include    -Wall -Werror
> >  -Wc,-pthread -g -O2     -o libgomp.la -version-info 1:0:0  -no-undefined
> >  -bindir "/opt/freeware/bin" -rpath /opt/freeware/lib alloc.lo barrier.lo
> >  critical.lo env.lo error.lo iter.lo iter_ull.lo loop.lo loop_ull.lo
> >  ordered.lo parallel.lo sections.lo single.lo task.lo team.lo work.lo
> >  lock.lo mutex.lo proc.lo sem.lo bar.lo ptrlock.lo time.lo fortran.lo
> >  affinity.lo
> >  
> >  libtool: link:
> >  /devel/opensource/gcc/gcc-4.5.0/host-powerpc-ibm-aix6.1.0.0/gcc/nm -B
> >  -X32_64 -BCpg  .libs/alloc.o .libs/barrier.o .libs/critical.o
> >  .libs/env.o .libs/error.o .libs/iter.o .libs/iter_ull.o .libs/loop.o
> >  .libs/loop_ull.o .libs/ordered.o .libs/parallel.o .libs/sections.o
> >  .libs/single.o .libs/task.o .libs/team.o .libs/work.o .libs/lock.o
> >  .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o
> >  .libs/time.o .libs/fortran.o .libs/affinity.o   | awk '{ if ((($ 2 ==
> >  "T") || ($ 2 == "D") || ($ 2 == "B"))&&  (substr($ 3,1,1) != ".")) {
> >  print $ 3 } }' | sort -u>  .libs/libgomp.exp
> >  
> >  /devel/opensource/gcc/gcc-4.5.0/host-powerpc-ibm-aix6.1.0.0/gcc/nm[83]:
> >  /usr/bin/nm -B -X32_64:  not found
> >  libtool: link:
> >  /devel/opensource/gcc/gcc-4.5.0/host-powerpc-ibm-aix6.1.0.0/gcc/xgcc
> >  -B/devel/opensource/gcc/gcc-4.5.0/host-powerpc-ibm-aix6.1.0.0/gcc/
> >  -B/opt/freeware/powerpc-ibm-aix6.1.0.0/bin/
> >  -B/opt/freeware/powerpc-ibm-aix6.1.0.0/lib/ -isystem
> >  /opt/freeware/powerpc-ibm-aix6.1.0.0/include -isystem
> >  /opt/freeware/powerpc-ibm-aix6.1.0.0/sys-include    -shared -o
> >  .libs/libgomp.so.1  .libs/alloc.o .libs/barrier.o .libs/critical.o
> >  .libs/env.o .libs/error.o .libs/iter.o .libs/iter_ull.o .libs/loop.o
> >  .libs/loop_ull.o .libs/ordered.o .libs/parallel.o .libs/sections.o
> >  .libs/single.o .libs/task.o .libs/team.o .libs/work.o .libs/lock.o
> >  .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o
> >  .libs/time.o .libs/fortran.o .libs/affinity.o   -lc -Wl,-bnoentry
> >  -pthread   -Wl,-bE:.libs/libgomp.exp -Wl,-bernotok
> >  ld: 0711-317 ERROR: Undefined symbol: .__emutls_get_address
> >  ld: 0711-317 ERROR: Undefined symbol: .__udivdi3
> >  ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
> >  information.
> >  collect2: ld returned 8 exit status
> >  gmake[5]: *** [libgomp.la] Error 1
> >  gmake[5]: Leaving directory
> >  `/devel/opensource/gcc/gcc-4.5.0/powerpc-ibm-aix6.1.0.0/libgomp'
> >  gmake[4]: *** [all-recursive] Error 1
> >  gmake[4]: Leaving directory
> >  `/devel/opensource/gcc/gcc-4.5.0/powerpc-ibm-aix6.1.0.0/libgomp'
> >  gmake[3]: *** [all] Error 2
> >  gmake[3]: Leaving directory
> >  `/devel/opensource/gcc/gcc-4.5.0/powerpc-ibm-aix6.1.0.0/libgomp'
> >  gmake[2]: *** [all-stage1-target-libgomp] Error 2
> >  gmake[2]: Leaving directory `/devel/opensource/gcc/gcc-4.5.0'
> >  gmake[1]: *** [stage1-bubble] Error 2
> >  gmake[1]: Leaving directory `/devel/opensource/gcc/gcc-4.5.0'
> >  gmake: *** [bootstrap] Error 2
> >  
> >        The issues that come up most often for me when using a build
> >  environment without IBMs C compiler are that Gnu autoconf scripts don't
> >  detect the fact that AIX nm needs -B for BSD compatibility.  I need to
> >  define NM="/usr/bin/nm -B" for some programs but that breaks others that
> >  call dirname in configure. I tend to export the paths for AIX ar, as,
> >  nm, ranlib, and ld and GNU paths in /opt/freeware for sed, gawk, grep,
> >  make, and bash. I also find that it is frequently necessary to construct
> >  symlinks back to the standard /usr/bin, /usr/sbin, /usr/lib, and
> >  /usr/include for any libraries that don't already have AIX equivalents.
> >  This also extends to libraries within /opt/freeware/lib/gcc. Much of
> >  this should not be necessary, but it seems to help with some packages
> >  that cannot grok a path with /opt/freeware in it instead of /usr/local.
> >  
> >  
I'm using autoconf-2.68-1, automake-1.11.1-1, GNU make-3.80-3, bash-4.2-1.

Thanks,
Richard Nolde

[Bug target/46655] invalid '.line 0' directive emitted with -g

[richard.nolde at cybox dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #23 from Richard Nolde <richard.nolde at cybox dot com> 2011-02-25 00:20:54 UTC ---
On 02/24/2011 01:42 PM, michael.haubenwallner at salomon dot at wrote:

Progress report on building Gcc 4.5.0 on AIX 6.0:

Using your suggestion for gmake bootstrap STAGE1_FLAGS=-0 gets me much 
further in the build. The problem has moved to building libgomp, and the 
failure appears to be due to the fact that AIX nm needs nm -B to be 
compatible with the AIX ld. The top level configure scripts seem to deal 
with this fine, but in the libgomp directory, configure builds a 
makefile that invokes
   /devel/opensource/gcc/gcc-4.5.0/host-powerpc-ibm-aix6.1.0.0/gcc/nm 
and bombs.

If NM is defined/exported as NM="/usr/bin/nm -B", or "/usr/bin/nm -B 
-X32_64", the script:

errors out a line 83.
[83]: /usr/bin/nm -B -X32_64:  not found

I believe the command   on line 83:      exec "$original" ${1+"$@"} is 
looking for a file named "-B" or "-B -X32_64" depending on how you 
define NM.  It would seem that we need an NM_FLAGS variable comparable 
to LD_FLAGS in which to pass the extra flags required to make AIX do the 
right thing here. The question is why do the other makefiles built by 
configure not have the same problem? If you don't define NM="/usr/bin/nm 
-B" at least, the top level configure reports that you cannot build 
shared libraries, which is not true on AIX. AIX shared libraries contain 
both 32 bit and 64 bit objects and can use .a or .so for a suffix.

It appears that the case statement at the top of the file is going to 
fall through without matching nm since basename returns nm -B and we 
then fall through the second case statement and invoke /usr/bin/nm such 
that it looks for the file -B. I not quite sure on this one.
...
      55 case "$original" in
      56   ../*)
      57     # compute absolute path of the location of this script
      58     tdir=`dirname "$0"`
      59     scriptdir=`cd "$tdir" && pwd`
      60
      61     if test -x $scriptdir/../$dir/$prog; then
      62       test "$fast_install" = yes || exec 
$scriptdir/../$dir/$prog ${1+"$@"}
      63
      64       # if libtool did everything it needs to do, there's a 
fast path
      65       lt_prog=$scriptdir/../$dir/$objdir/lt-$prog
      66       test -x $lt_prog && exec $lt_prog ${1+"$@"}
      67
      68       # libtool has not relinked ld-new yet, but we cannot just 
use the
      69       # previous stage (because then the relinking would just 
never happen!).
      70       # So we take extra care to use prev-ld/ld-new *on 
recursive calls*.
      71       test x"$LT_RCU" = x"1" && exec 
$scriptdir/../prev-$dir/$prog ${1+"$@"}
      72
      73       LT_RCU=1; export LT_RCU
      74       $scriptdir/../$dir/$prog ${1+"$@"}
      75       result=$?
      76       exit $result
      77
      78     else
      79       exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
      80     fi
      81     ;;
      82   *)
      83     exec "$original" ${1+"$@"}
      84     ;;
      85 esac
      86

Adding a few echo statements to send current values to a log file before 
line 55 and at line 83 and then resuming the make from the last 
invocation produces the following:

invoked is set to nm
prog is set to %{prog}
dir is set to binutils
original is set to /usr/bin/nm -B -X32_64
Calling exec /usr/bin/nm -B -X32_64 -B -X32_64 -BCpg .libs/alloc.o 
.libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o 
.libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o 
.libs/parallel.o .libs/sections.o .libs/single.o .libs/task.o 
.libs/team.o .libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o 
.libs/sem.o .libs/bar.o .libs/ptrlock.o .libs/time.o .libs/fortran.o 
.libs/affinity.o

Let me know if I can provide further debugging information.

Thanks,
    Richard Nolde

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
>
> --- Comment #20 from Michael Haubenwallner<michael.haubenwallner at salomon dot at>  2011-02-24 20:42:46 UTC ---
> (In reply to comment #19)
>    
>>> /usr/bin/gcc -c  -g -fkeep-inline-functions -DIN_GCC ...
>>>        
>> This is a problem in /usr/bin/gcc, not in the GCC sources you're compiling.
>>      
> (In reply to comment #1)
>    
>> $ gmake bootstrap STAGE1_CFLAGS=-O
>>      
> Richard, does this workaround work for you?
>
>

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #24 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-02-25 09:49:30 UTC ---
(In reply to comment #23)
> Using your suggestion for gmake bootstrap STAGE1_FLAGS=-0 gets me much 
> further in the build. The problem has moved to building libgomp, and the 
> failure appears to be due to the fact that AIX nm needs nm -B to be 
> compatible with the AIX ld.

This acutally looks like bug#33637.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #25 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-02-25 09:53:57 UTC ---
Ohw, and then there is bug#47032 (caused by bug#46481) you might stumble upon
in libgfortran.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #26 from David Edelsohn <dje at gcc dot gnu.org> 2011-02-25 17:52:21 UTC ---
Richard,

Did you look at the list of sites providing pre-built binaries for AIX listed
on the GCC website:

http://gcc.gnu.org/install/binaries.html

There are multiple options who provide much newer versions of GCC than the ones
included in the AIX Toolbox.

- David

[Bug target/46655] invalid '.line 0' directive emitted with -g

[richard.nolde at cybox dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #27 from Richard Nolde <richard.nolde at cybox dot com> 2011-02-28 15:57:00 UTC ---
On 02/25/2011 10:52 AM, dje at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
>
> --- Comment #26 from David Edelsohn<dje at gcc dot gnu.org>  2011-02-25 17:52:21 UTC ---
> Richard,
>
> Did you look at the list of sites providing pre-built binaries for AIX listed
> on the GCC website:
>
> http://gcc.gnu.org/install/binaries.html
>
> There are multiple options who provide much newer versions of GCC than the ones
> included in the AIX Toolbox.
>
> - David
>
>    
David,
    Yes, I gave up on the IBM site years ago. The versions of Gcc and 
other tools they provide are either hopelessly out-of-date or broken. 
Dr. Michael Perzl has a site, www.perzl.org, to which the GNU GCC entry 
points, for AIX builds and I use his builds whenever possible. He has 
just updated his gcc builds last Friday and I will try them today.  I do 
like to build from source when possible just to validate the build since 
GCC is about as demanding as anything I know of for the compiler suite.

Thanks,
    Richard Nolde

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #28 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-04-01 12:24:32 UTC ---
Looks like IBM "fixed" their Assembler to ignore invalid .line pseudo-ops
again:
https://www-304.ibm.com/support/docview.wss?uid=isg1IZ87535

[Bug target/46655] invalid '.line 0' directive emitted with -g

[richard.nolde at cybox dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #29 from Richard Nolde <richard.nolde at cybox dot com> 2011-05-16 23:19:24 UTC ---
On 04/01/2011 06:24 AM, michael.haubenwallner at salomon dot at wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655
>
> --- Comment #28 from Michael Haubenwallner<michael.haubenwallner at salomon dot at>  2011-04-01 12:24:32 UTC ---
> Looks like IBM "fixed" their Assembler to ignore invalid .line pseudo-ops
> again:
> https://www-304.ibm.com/support/docview.wss?uid=isg1IZ87535
I seem to be unable to use my Gcc Bugzilla account at the moment 
(waiting for an updated password token message), so I'll send this one 
to you in the hope that it adds to the known database of issues for Gcc 
on AIX. I received the URL to update my Bugzilla password and it 
accepted it but I still cannot login.  "The username or password you 
entered is not valid." comes up each time I try.

I'm now running AIX 6.1,  oslevel -s returns 6100-06-03-1048 and the 
problem seems to persist with newer versions of gcc as well. I installed 
gcc 4.4.6 today after having issues trying to build GNU barcode from source.
gcc -v
Using built-in specs.
Target: powerpc-ibm-aix6.1.0.0
Configured with: ../gcc-4.4.6/configure --with-as=/usr/bin/as 
--with-ld=/usr/bin/ld --enable-languages=c,c++,fortran 
--prefix=/opt/freeware --enable-threads 
--enable-version-specific-runtime-libs --disable-nls 
--enable-decimal-float=dpd --host=powerpc-ibm-aix6.1.0.0
Thread model: aix
gcc version 4.4.6 (GCC)

The original Makefile includes -g among the CFLAGS, which produces the 
now well documented error message from the AIX assembler as noted in 
this thread. After revisiting the GCC Bugzilla site today, I added 
initializations for all the Static variables in the source code files 
that were not arrays and were not already initialized and then I tried 
to recompile with -g in the CFLAGS. This attempt now fails with the also 
reported message:
...
/usr/bin/gcc -g -std=gnu89 -O2 -Wall -DPACKAGE_NAME=\"\" 
-DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
-DHAVE_UNISTD_H=1 -DHAVE_STRCASECMP=1    main.o cmdline.o  -L. -lbarcode 
-lpaper -lm -o barcode
ld: 0711-596 SEVERE ERROR: Object main.o
         An RLD for section 2 (.data) refers to symbol 944,
         but the storage class of the symbol is not C_EXT or C_HIDEXT.
collect2: ld returned 12 exit status
make: *** [barcode] Error 1

The only way to get a successful compile under AIX 6.1 TL 3 with IBM's 
fix-du-jour is to remove -g from the CFLAGS.
Here is the top of the GNU barcode Makefile, the rest is standard 
install targets etc.

#
# This Makefile should run fine with both pmake and gmake
#

CC = /usr/bin/gcc
CFLAGS = -std=gnu89 -O2 -Wall -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" 
-DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" 
-DPACKAGE_URL=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STRCASECMP=1
RANLIB = /usr/bin/ranlib

INSTALL = /opt/freeware/bin/install -c

LDFLAGS = -L. -l$(TARGET) -lpaper -lm

prefix = /opt/freeware
BINDIR = $(bindir)
LIBDIR = $(libdir)
INCDIR = $(includedir)
MANDIR = $(prefix)/share
MAN1DIR = $(mandir)/man1
MAN3DIR = $(mandir)/man3
INFODIR = $(infodir)

# getopt may be installed or not, if not take our copy
GETOPT_O =

TARGET = barcode
LIBRARY = lib$(TARGET).a
MAN1 = $(TARGET).1
MAN3 = $(TARGET).3
#INFO = doc/$(TARGET).info
HEADER = $(TARGET).h

LIBOBJECTS = library.o ean.o code128.o code39.o code93.o i25.o \
                 msi.o plessey.o codabar.o \
                 ps.o pcl.o code11.o fonts.o
EXEOBJECTS = main.o cmdline.o $(GETOPT_O)
ALLSOURCES = $(LIBOBJECTS:.o=.c) $(EXEOBJECT:.o=.c)


#Hmm... "RM" is undefined in pmake
RM = rm

#all: $(TARGET) $(LIBRARY) $(MAN1) $(MAN3) $(INFO) sample
all: $(TARGET) $(LIBRARY) sample

$(TARGET): $(LIBRARY) $(EXEOBJECTS)
         $(CC) $(CFLAGS) $(EXEOBJECTS) $(LDFLAGS) -o $(TARGET)



ALSO, FWIW, gdb 7.2.1 under AIX 6.1 coredumps when trying to print any 
variable that is a pointer to char. I can compile programs that don't 
have static variables with -g, but I get a coredump when I tried to 
debug them. I can try to create a simple test case if this is not a 
known bug.

Thanks,
   Richard Nolde

[Bug target/46655] invalid '.line 0' directive emitted with -g

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #30 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-05-17 05:55:57 UTC ---
> I'm now running AIX 6.1,  oslevel -s returns 6100-06-03-1048 and the 
> problem seems to persist with newer versions of gcc as well. I installed 
> gcc 4.4.6 today after having issues trying to build GNU barcode from source.
> gcc -v

Look at comment #17 or the "target milestone" field.

[Bug target/46655] invalid '.line 0' directive emitted with -g

[michael.haubenwallner at salomon dot at]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46655

--- Comment #31 from Michael Haubenwallner <michael.haubenwallner at salomon dot at> 2011-05-17 07:17:57 UTC ---
(In reply to comment #29)
> I'm now running AIX 6.1,  oslevel -s returns 6100-06-03-1048 and the 
> problem seems to persist with newer versions of gcc as well. I installed 
> gcc 4.4.6 today after having issues trying to build GNU barcode from source.
> gcc -v

> ld: 0711-596 SEVERE ERROR: Object main.o
>          An RLD for section 2 (.data) refers to symbol 944,
>          but the storage class of the symbol is not C_EXT or C_HIDEXT.

This most likely is bug#46072 comment#10, which is a subsequent AIX bug already
known to IBM (bug#46072 comment#18).