Re: libgcj/1736: [irix 6.5] Cannot create libgcj - Arg list too long

Re: libgcj/1736: [irix 6.5] Cannot create libgcj - Arg list too long

[rodrigc]

Synopsis: [irix 6.5] Cannot create libgcj - Arg list too long

State-Changed-From-To: feedback->closed
State-Changed-By: rodrigc
State-Changed-When: Sun Jan 27 15:36:14 2002
State-Changed-Why:
    http://gcc.gnu.org/ml/gcc-cvs/2001-03/msg00635.html

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=1736

libgcj/1736: [irix 6.5] Cannot create libgcj - Arg list too long

[David.Billinghurst]

>Number:         1736
>Category:       libgcj
>Synopsis:       [irix 6.5] Cannot create libgcj - Arg list too long
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 22 15:56:05 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     David Billinghurst
>Release:        cvs 20010115
>Organization:
>Environment:
mips-sgi-ixi6.5
>Description:
Cannot create ligcj.la.  Apparently this is a known problem.


`/exd4/billingd/obj/gcc-java/mips-sgi-irix6.5/mabi=64/libjava'
/bin/sh ./libtool --mode=link /exd4/billingd/obj/gcc-java/gcc/xgcc
-B/exd4/billingd/obj/gcc-java/gcc/
-B/exd4/billingd/tmp/gcc/mips-sgi-irix6.5/bin/
-B/exd4/billingd/tmp/gcc/mips-sgi-irix6.5/lib/ -isystem
/exd4/billingd/tmp/gcc/mips-sgi-irix6.5/include  -mabi=64
-L/exd4/billingd/obj/gcc-java/mips-sgi-irix6.5/mabi=64/libjava -g   -mabi=64
-o libgcj.la -rpath /exd4/billingd/tmp/gcc/lib/mabi=64
-L/exd4/billingd/obj/gcc-java/mips-sgi-irix6.5/mabi=64/libjava/../libstdc++-
v3/libsupc++ -lsupc++ -rpath /exd4/billingd/tmp/gcc/lib/mabi=64
-version-info `grep -v '^#' /exd4/billingd/src/gcc/libjava/libtool-version`
prims.lo posix.lo jni.lo 
...
...
...
/lang/s_sin.lo boehm.lo no-threads.lo  `ar t ../libffi/.libs/libffi.a
2>/dev/null | sed 's/\.o/\.lo/g' | sed 's/^/..\/libffi\//g'`
./libltdl/libltdlc.la 
make[4]: execvp: /bin/sh: Arg list too long
make[4]: *** [libgcj.la] Error 127


>How-To-Repeat:
With cvs gcc, enable libgcj in top level configure.in

make bootstrap 
>Fix:
Is it possible to build libgcj incrementally?
>Release-Note:
>Audit-Trail:
>Unformatted:
>From fgouget@codeweavers.com Sun Apr 01 00:00:00 2001
From: fgouget@codeweavers.com
To: gcc-gnats@gcc.gnu.org
Subject: c++/1600: The placement of __attribute__ confuses g++
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010110025645.2466.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00134.html
Content-length: 2889

>Number:         1600
>Category:       c++
>Synopsis:       The placement of __attribute__ confuses g++
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 09 19:06:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Francois Gouget
>Release:        CVS 2001/01/08
>Organization:
>Environment:
Debian Linux on Intel ('testing' distribution as of about 2001/01/08)
libc6: 2.2-6
>Description:
   When compiling the code included below with g++ from 
CVS 2001/01/08 I get:

$ /usr/local/opt/gcc-20010108/bin/g++ -c test1.cpp
test1.cpp:14: cannot convert `void (*)()' to `void (*)()' for argument `1' to 
   `int atexit(void (*)())'

   Here's more information about g++ used:

$ /usr/local/opt/gcc-20010108/bin/g++ -v
Reading specs from /usr/local/opt/gcc-20010108/bin/../lib/gcc-lib/i686-pc-linux-gnu/2.97/specs
Configured with: ./src/configure --prefix=/usr/local/opt/gcc --exec-prefix=/usr/local/opt/gcc --enable-shared --enable-threads --enable-languages=c,c++
gcc version 2.97 20010108 (experimental)

   The same code compiles fine if the second declaration of 
m_func is used instead of the first one, or if one uses g++ 
2.95.2. On my machine that would be:

$ g++ -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
gcc version 2.95.2 20000220 (Debian GNU/Linux)


   Maybe the placement of __attribute__ is illegal, 
although it does seem allowed in other contexts, but in 
any case g++ should not complain about the call to atexit 
(which is why I have set Class to rejects-legal).

   Before I managed to reproduce this problem in a small 
example I had this problem in a piece of code (in the MFC) 
where m_func and the atexit call were thousands of lines 
apart. I found that fixing all the m_func-style 
definitions as per the workaround was necessary before 
g++ would stop complaining about atexit.
   This problem seems to only affect the declaration of 
pointers to function that are a field of a class. If the 
declaration concerns a global variable or a function 
parameter the placement of __attribute__ seems to cause no 
ill side-effect (i.e. I did not have to change those).

   On last word: the reason I'm using g++ from CVS is 
because I need the '__attribute__((com_interface))'.
>How-To-Repeat:
Compile the following:

--- cut here ---
extern int atexit (void (*__func) (void)) throw ();

class SomeClass
{
public:
    void  (__attribute__((__stdcall__)) *m_func)();
    //void __attribute__((__stdcall__)) (*m_func)();
};

void foo()
{
}

char _term = (char)atexit(&foo);
--- cut here ---
>Fix:
   The workaround is to move __attribute__ out of the 
parenthesis enclosing the name of the pointer to function
(see the commented out declaration of m_func). 
>Release-Note:
>Audit-Trail:
>Unformatted:
>From lerdsuwa@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: lerdsuwa@gcc.gnu.org
To: lerdsuwa@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/1733
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010220082601.3533.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01511.html
Content-length: 540

The following reply was made to PR c++/1733; it has been noted by GNATS.

From: lerdsuwa@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, lerdsuwa@gcc.gnu.org, snyder@fnal.gov
Cc:  
Subject: Re: c++/1733
Date: 20 Feb 2001 08:24:29 -0000

 Synopsis: C++ ICE in copy_body_r with optimization on
 
 State-Changed-From-To: analyzed->closed
 State-Changed-By: lerdsuwa
 State-Changed-When: Tue Feb 20 00:24:29 2001
 State-Changed-Why:
     Fixed in the mainline and gcc 3.0 branch.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1733&database=gcc