problem on building gcc 3.3.1 on AIX5.2

problem on building gcc 3.3.1 on AIX5.2

[Tsutomu Miyashita]

Dear members

I met the problem on building gcc3.3.1 on AIX5.2. This problem occurs on
the GCC version after 3.1 not on 3.0.
I welcom any information about this.

[environment]
OS		AIX5.2 maintenance level 1
compiler	VisualAgeC++ 6.0.0.4
bison		1.875
flex		2.5.4
GCC		3.1 - 3.3.1

[error message]
#> tar -zxvf gcc-3.3.1.tar.gz
#> cd gcc-3.3.1
#> mkdir gccobj
#> cd gccobj
#> ../configure --enable-language=c
#> make bootstrap
	:
	:
	:
cc -c -DIN_GCC -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALE_ALIAS_PATH=\"/usr/local/share/locale\" -DLIBDIR=\"/usr/local/lib\" -
DHAVE_CONFIG_H -I.. -I. -I../../../gcc/intl -I../../../gcc -I../../../gcc/config -I../../../gcc/../include -g
../../../gcc/intl/plural.c -o plural.o
"plural.y", line 264.1: 1506-343 (S) Redeclaration of __gettextlex differs from previous declaration on line 73 of "plural.y".

Tsutomu Miyashita

Re: problem on building gcc 3.3.1 on AIX5.2

[Claudio Bley]

On Thu, Sep 04, 2003 at 05:53:30PM +0900, Tsutomu Miyashita wrote:
> Dear members
> 
> I met the problem on building gcc3.3.1 on AIX5.2. This problem occurs on
> the GCC version after 3.1 not on 3.0.
> I welcom any information about this.
> 
> [environment]
> OS		AIX5.2 maintenance level 1
> compiler	VisualAgeC++ 6.0.0.4
> bison		1.875
> flex		2.5.4
> GCC		3.1 - 3.3.1
> 
> [error message]
> #> tar -zxvf gcc-3.3.1.tar.gz
> #> cd gcc-3.3.1
> #> mkdir gccobj
> #> cd gccobj

,----[ http://gcc.gnu.org/install/configure.html ]
| First, we highly recommend that GCC be built into a separate directory
| than the sources which does not reside within the source tree. This is
| how we generally build GCC; building where srcdir == objdir should
| still work, but doesn't get extensive testing; building where objdir
| is a subdirectory of srcdir is unsupported.
`----

So, try 

tar -zxvf gcc-3.3.1.tar.gz
mkdir gccobj
cd gccobj
../gcc-3.3.1/configure [...]

-- 
Claudio Bley                                 ASCII ribbon campaign (")
Debian GNU/Linux user                         - against HTML email  X 
http://www.cs.uni-magdeburg.de/~bley/                     & vCards / \

Same internal function name in libstdc++.so.5 and libjvm.so

[Ajay Bansal]

Hi All


We are facing a "same function name" issue in two different libraries on
Linux. My program is linked with both libstdc++ and libjvm. I am using gcc
3.2.1 on Linux.

My code has following line : 

dynamic_cast<CSObject*>(m_unresolved)->WriteObject(lpszSString);

Which dumps core.

As it was not very clear why this piece of code can give a dump, I changed
the code as follows:

        if ( dynamic_cast<CSObject*>(m_unresolved))
	
dynamic_cast<CSObject*>(m_unresolved)->WriteObject(lpszSString);

 
Now core comes while executing "if" statement. I have checked for validity
of pointers "m_unresolved" and "lpszSString". Both are valid.   

On Linux, with gcc 3.2.1, dynamic_cast internally calls function
"__dynamic_cast". Problem is - this function is present both in
libstdc++.so.5 and libjvm.so. In our code, function from libjvm is being
called. If I change dynamic_cast to simple C style cast, everything works
fine. (nm for libstdc_++ and libjvm is given below)

----------------------------------------
[abansal@linux2 lib]$ nm -A *.so.* |grep __dynamic
libstdc++.so.5:00051bc0 T __dynamic_cast .so.5.0.1:00051bc0 T 
libstdc++__dynamic_cast

[abansal@linux2 lib]$ nm /usr/j2sdk1.4.1_02/jre/lib/i386/server/libjvm.so
|grep __dynamic
00485c34 T __dynamic_cast
----------------------------------------


Changing all dynamic_casts to simple C style casts in the code solves the
issue, but I know that that is undesirable. Can somebody please suggest us
what should we do in this case?


Regards
Ajay 
 

Same internal function name in libstdc++.so.5 and libjvm.so

[Ajay Bansal]

Hi All


We are facing a "same function name" issue in two different libraries on
Linux. My program is linked with both libstdc++ and libjvm. I am using gcc
3.2.1 on Linux.

My code has following line : 

dynamic_cast<CSObject*>(m_unresolved)->WriteObject(lpszSString);

Which dumps core.

As it was not very clear why this piece of code can give a dump, I changed
the code as follows:

        if ( dynamic_cast<CSObject*>(m_unresolved))
	
dynamic_cast<CSObject*>(m_unresolved)->WriteObject(lpszSString);

 
Now core comes while executing "if" statement. I have checked for validity
of pointers "m_unresolved" and "lpszSString". Both are valid.   

On Linux, with gcc 3.2.1, dynamic_cast internally calls function
"__dynamic_cast". Problem is - this function is present both in
libstdc++.so.5 and libjvm.so. In our code, function from libjvm is being
called. If I change dynamic_cast to simple C style cast, everything works
fine. (nm for libstdc_++ and libjvm is given below)

----------------------------------------
[abansal@linux2 lib]$ nm -A *.so.* |grep __dynamic
libstdc++.so.5:00051bc0 T __dynamic_cast .so.5.0.1:00051bc0 T 
libstdc++__dynamic_cast

[abansal@linux2 lib]$ nm /usr/j2sdk1.4.1_02/jre/lib/i386/server/libjvm.so
|grep __dynamic
00485c34 T __dynamic_cast
----------------------------------------


Changing all dynamic_casts to simple C style casts in the code solves the
issue, but I know that that is undesirable. Can somebody please suggest us
what should we do in this case?


Regards
Ajay 
 

RE: problem on building gcc 3.3.1 on AIX5.2

[Tsutomu Miyashita]

> ,----[ http://gcc.gnu.org/install/configure.html ]
> | First, we highly recommend that GCC be built into a separate directory
> | than the sources which does not reside within the source tree. This is
> | how we generally build GCC; building where srcdir == objdir should
> | still work, but doesn't get extensive testing; building where objdir
> | is a subdirectory of srcdir is unsupported.
> `----
> 
> So, try 
> 
> tar -zxvf gcc-3.3.1.tar.gz
> mkdir gccobj
> cd gccobj
> ../gcc-3.3.1/configure [...]
Thank you for your information.
I made GCC according to your suggestion, but same problem occured too.

Thanks
Tsutomu Miyashita

Re: problem on building gcc 3.3.1 on AIX5.2

[Claudio Bley]

On Fri, Sep 05, 2003 at 11:49:59AM +0900, Tsutomu Miyashita wrote:
> > ,----[ http://gcc.gnu.org/install/configure.html ]
> > | First, we highly recommend that GCC be built into a separate directory
> > | than the sources which does not reside within the source tree. This is
> > | how we generally build GCC; building where srcdir == objdir should
> > | still work, but doesn't get extensive testing; building where objdir
> > | is a subdirectory of srcdir is unsupported.
> > `----
> > 
> > So, try 
> > 
> > tar -zxvf gcc-3.3.1.tar.gz
> > mkdir gccobj
> > cd gccobj
> > ../gcc-3.3.1/configure [...]
> Thank you for your information.
> I made GCC according to your suggestion, but same problem occured too.

Okay. I just wanted to make sure it wasn't some unfortunate
coincidence because of building in a subdir of `srcdir' that caused
the error. Too bad it didn't work out.

But I did a little web research on google and it seems this is a known
problem (see http://gcc.gnu.org/ml/gcc-prs/2002-11/msg00963.html) when
building with the cc compiler. I also found a message from David
Lawless reporting a successful build on AIX 4.2.1.0 
(http://gcc.gnu.org/ml/gcc/2003-05/msg02228.html) who suggests to
apply this simple patch:

$ diff gcc-3.2.3/gcc/intl/plural.c.org gcc-3.2.3/gcc/intl/plural.c
176,180d175
< #ifndef __cplusplus
< #ifndef __STDC__
< #define const
< #endif
< #endif


He also said:

--disable-shared    is absolutely necessary
--disable-multilib  unless you have a Regatta or
                    have all eternity to wait

but I don't know whether this still applies (to your environment).

HTH
-- 
Claudio Bley                                 ASCII ribbon campaign (")
Debian GNU/Linux user                         - against HTML email  X 
http://www.cs.uni-magdeburg.de/~bley/                     & vCards / \

RE: problem on building gcc 3.3.1 on AIX5.2

[Tsutomu Miyashita]

> $ diff gcc-3.2.3/gcc/intl/plural.c.org gcc-3.2.3/gcc/intl/plural.c
> 176,180d175
> < #ifndef __cplusplus
> < #ifndef __STDC__
> < #define const
> < #endif
> < #endif
I modified plural.c like above and the problem was resolved.
Thanks Claudio!!

Tsutomu Miyashita

RE: Same internal function name in libstdc++.so.5 and libjvm.so

[lrtaylor]

You are correct.  However, you can still add it explicitly to the command line with g++ (if you're using gcj, then I'm not sure).  For example,

g++ -o prog file.cpp -lstdc++ -lsomeotherlib 

Now, if you do an 'ldd' on 'prod', you should see libstdc++ before libsomeotherlib.

Lyle

 -----Original Message-----
From: 	Ajay Bansal [mailto:abansal@netegrity.com] 
Sent:	Thursday, September 04, 2003 10:16 AM
To:	gcc-help@gcc.gnu.org
Subject:	RE: Same internal function name in libstdc++.so.5 and libjvm.so

But I don't _link_ with libstdc++ explicitly!!!!!!!!!!!!!!!!!!!!!!! It is
linked implicitly by g++ compiler.

(Am I correct??) 


-----Original Message-----
From: lrtaylor@micron.com [mailto:lrtaylor@micron.com] 
Sent: Thursday, September 04, 2003 9:39 PM
To: abansal@netegrity.com; gcc-help@gcc.gnu.org

Hi,

Can you change your link line so that libstdc++ is linked to before libjvm?
If I understand correctly, it should get the function our of the first
library linked to that defines it (I could be wrong, though...)

Lyle Taylor

 -----Original Message-----
From: 	Ajay Bansal [mailto:abansal@netegrity.com] 
Sent:	Thursday, September 04, 2003 5:17 AM
To:	gcc-help@gcc.gnu.org
Subject:	Same internal function name in libstdc++.so.5 and libjvm.so

Hi All


We are facing a "same function name" issue in two different libraries on
Linux. My program is linked with both libstdc++ and libjvm. I am using gcc
3.2.1 on Linux.

My code has following line : 

dynamic_cast<CSObject*>(m_unresolved)->WriteObject(lpszSString);

Which dumps core.

As it was not very clear why this piece of code can give a dump, I changed
the code as follows:

        if ( dynamic_cast<CSObject*>(m_unresolved))
	
dynamic_cast<CSObject*>(m_unresolved)->WriteObject(lpszSString);

 
Now core comes while executing "if" statement. I have checked for validity
of pointers "m_unresolved" and "lpszSString". Both are valid.   

On Linux, with gcc 3.2.1, dynamic_cast internally calls function
"__dynamic_cast". Problem is - this function is present both in
libstdc++.so.5 and libjvm.so. In our code, function from libjvm is being
called. If I change dynamic_cast to simple C style cast, everything works
fine. (nm for libstdc_++ and libjvm is given below)

----------------------------------------
[abansal@linux2 lib]$ nm -A *.so.* |grep __dynamic
libstdc++.so.5:00051bc0 T __dynamic_cast .so.5.0.1:00051bc0 T 
libstdc++__dynamic_cast

[abansal@linux2 lib]$ nm /usr/j2sdk1.4.1_02/jre/lib/i386/server/libjvm.so
|grep __dynamic
00485c34 T __dynamic_cast
----------------------------------------


Changing all dynamic_casts to simple C style casts in the code solves the
issue, but I know that that is undesirable. Can somebody please suggest us
what should we do in this case?


Regards
Ajay 
 

RE: Same internal function name in libstdc++.so.5 and libjvm.so

[Ajay Bansal]

But I don't _link_ with libstdc++ explicitly!!!!!!!!!!!!!!!!!!!!!!! It is
linked implicitly by g++ compiler.

(Am I correct??) 


-----Original Message-----
From: lrtaylor@micron.com [mailto:lrtaylor@micron.com] 
Sent: Thursday, September 04, 2003 9:39 PM
To: abansal@netegrity.com; gcc-help@gcc.gnu.org

Hi,

Can you change your link line so that libstdc++ is linked to before libjvm?
If I understand correctly, it should get the function our of the first
library linked to that defines it (I could be wrong, though...)

Lyle Taylor

 -----Original Message-----
From: 	Ajay Bansal [mailto:abansal@netegrity.com] 
Sent:	Thursday, September 04, 2003 5:17 AM
To:	gcc-help@gcc.gnu.org
Subject:	Same internal function name in libstdc++.so.5 and libjvm.so

Hi All


We are facing a "same function name" issue in two different libraries on
Linux. My program is linked with both libstdc++ and libjvm. I am using gcc
3.2.1 on Linux.

My code has following line : 

dynamic_cast<CSObject*>(m_unresolved)->WriteObject(lpszSString);

Which dumps core.

As it was not very clear why this piece of code can give a dump, I changed
the code as follows:

        if ( dynamic_cast<CSObject*>(m_unresolved))
	
dynamic_cast<CSObject*>(m_unresolved)->WriteObject(lpszSString);

 
Now core comes while executing "if" statement. I have checked for validity
of pointers "m_unresolved" and "lpszSString". Both are valid.   

On Linux, with gcc 3.2.1, dynamic_cast internally calls function
"__dynamic_cast". Problem is - this function is present both in
libstdc++.so.5 and libjvm.so. In our code, function from libjvm is being
called. If I change dynamic_cast to simple C style cast, everything works
fine. (nm for libstdc_++ and libjvm is given below)

----------------------------------------
[abansal@linux2 lib]$ nm -A *.so.* |grep __dynamic
libstdc++.so.5:00051bc0 T __dynamic_cast .so.5.0.1:00051bc0 T 
libstdc++__dynamic_cast

[abansal@linux2 lib]$ nm /usr/j2sdk1.4.1_02/jre/lib/i386/server/libjvm.so
|grep __dynamic
00485c34 T __dynamic_cast
----------------------------------------


Changing all dynamic_casts to simple C style casts in the code solves the
issue, but I know that that is undesirable. Can somebody please suggest us
what should we do in this case?


Regards
Ajay 
 

RE: Same internal function name in libstdc++.so.5 and libjvm.so

[Ajay Bansal]

But I don't _link_ with libstdc++ explicitly!!!!!!!!!!!!!!!!!!!!!!! It is
linked implicitly by g++ compiler.

(Am I correct??) 


-----Original Message-----
From: lrtaylor@micron.com [mailto:lrtaylor@micron.com] 
Sent: Thursday, September 04, 2003 9:39 PM
To: abansal@netegrity.com; gcc-help@gcc.gnu.org

Hi,

Can you change your link line so that libstdc++ is linked to before libjvm?
If I understand correctly, it should get the function our of the first
library linked to that defines it (I could be wrong, though...)

Lyle Taylor

 -----Original Message-----
From: 	Ajay Bansal [mailto:abansal@netegrity.com] 
Sent:	Thursday, September 04, 2003 5:17 AM
To:	gcc-help@gcc.gnu.org
Subject:	Same internal function name in libstdc++.so.5 and libjvm.so

Hi All


We are facing a "same function name" issue in two different libraries on
Linux. My program is linked with both libstdc++ and libjvm. I am using gcc
3.2.1 on Linux.

My code has following line : 

dynamic_cast<CSObject*>(m_unresolved)->WriteObject(lpszSString);

Which dumps core.

As it was not very clear why this piece of code can give a dump, I changed
the code as follows:

        if ( dynamic_cast<CSObject*>(m_unresolved))
	
dynamic_cast<CSObject*>(m_unresolved)->WriteObject(lpszSString);

 
Now core comes while executing "if" statement. I have checked for validity
of pointers "m_unresolved" and "lpszSString". Both are valid.   

On Linux, with gcc 3.2.1, dynamic_cast internally calls function
"__dynamic_cast". Problem is - this function is present both in
libstdc++.so.5 and libjvm.so. In our code, function from libjvm is being
called. If I change dynamic_cast to simple C style cast, everything works
fine. (nm for libstdc_++ and libjvm is given below)

----------------------------------------
[abansal@linux2 lib]$ nm -A *.so.* |grep __dynamic
libstdc++.so.5:00051bc0 T __dynamic_cast .so.5.0.1:00051bc0 T 
libstdc++__dynamic_cast

[abansal@linux2 lib]$ nm /usr/j2sdk1.4.1_02/jre/lib/i386/server/libjvm.so
|grep __dynamic
00485c34 T __dynamic_cast
----------------------------------------


Changing all dynamic_casts to simple C style casts in the code solves the
issue, but I know that that is undesirable. Can somebody please suggest us
what should we do in this case?


Regards
Ajay 
 

RE: Same internal function name in libstdc++.so.5 and libjvm.so

[lrtaylor]

Hi,

Can you change your link line so that libstdc++ is linked to before libjvm?  If I understand correctly, it should get the function our of the first library linked to that defines it (I could be wrong, though...)

Lyle Taylor

 -----Original Message-----
From: 	Ajay Bansal [mailto:abansal@netegrity.com] 
Sent:	Thursday, September 04, 2003 5:17 AM
To:	gcc-help@gcc.gnu.org
Subject:	Same internal function name in libstdc++.so.5 and libjvm.so

Hi All


We are facing a "same function name" issue in two different libraries on
Linux. My program is linked with both libstdc++ and libjvm. I am using gcc
3.2.1 on Linux.

My code has following line : 

dynamic_cast<CSObject*>(m_unresolved)->WriteObject(lpszSString);

Which dumps core.

As it was not very clear why this piece of code can give a dump, I changed
the code as follows:

        if ( dynamic_cast<CSObject*>(m_unresolved))
	
dynamic_cast<CSObject*>(m_unresolved)->WriteObject(lpszSString);

 
Now core comes while executing "if" statement. I have checked for validity
of pointers "m_unresolved" and "lpszSString". Both are valid.   

On Linux, with gcc 3.2.1, dynamic_cast internally calls function
"__dynamic_cast". Problem is - this function is present both in
libstdc++.so.5 and libjvm.so. In our code, function from libjvm is being
called. If I change dynamic_cast to simple C style cast, everything works
fine. (nm for libstdc_++ and libjvm is given below)

----------------------------------------
[abansal@linux2 lib]$ nm -A *.so.* |grep __dynamic
libstdc++.so.5:00051bc0 T __dynamic_cast .so.5.0.1:00051bc0 T 
libstdc++__dynamic_cast

[abansal@linux2 lib]$ nm /usr/j2sdk1.4.1_02/jre/lib/i386/server/libjvm.so
|grep __dynamic
00485c34 T __dynamic_cast
----------------------------------------


Changing all dynamic_casts to simple C style casts in the code solves the
issue, but I know that that is undesirable. Can somebody please suggest us
what should we do in this case?


Regards
Ajay