Conflicting 'typedef' error - Which gcc switch to use?

2006-09-18 Thread amit

I am using gcc3.3.5 on solaris2.7. Its a 64 bit compilation

I am compiling a file 'plugin.cpp'. It includes mach.h and the complation
gives the following error. 
-
mach.h  error: conflicting
   types for `typedef vx_u32_t off32_t'

/usr/include/sys/types32.h:30: error: previous declaration as `typedef
int32_t
   off32_t'


I cant remove mach.h, neither i can edit the file mach.h
Is there any particular switch/flag which can resolve the conflicting
'typedef' error

The flags i am using are - 
/usr/local/gcc/3.3.5/bin/gcc -c -fpermissive -fno-gnu-keywords -DXTFUNCPROTO
-Usun -xildoff -fPIC -m64 -xchip=ultra -xarch=v9 -xnone -DLGTO_LP64 -g
-DIDENT -DALT_ORIGIN=\"../lib/nsr\" -DDM_SOLARIS -D_POSIX_PTHREAD_SEMANTICS
-DASYNC_IO -DNSR_POSIX4_ASYNC_IO -Dsolaris -DRELEASE_27 -DDM_BUILD=\"tmp\"
-DHSM_SERVER -D__lgto
ndmp__ -DSNMP_SUPPORT -DENABLERS -DSTL_SUPPORT -DSTL_CLIENT_SUPPORT
-DOPENVAULT_SUPPORT -Dsolaris64 


-- 
View this message in context: 
http://www.nabble.com/Conflicting-%27typedef%27-error---Which-gcc-switch-to-use--tf2292090.html#a6366344
Sent from the gcc - bugs mailing list archive at Nabble.com.



[Bug c++/39409] New: internal compiler error: Segmentation fault

2009-03-09 Thread amit at mobiletornado dot com
$ uname -a
system type: AIX aix52a 1 6 000921F2D700

$ gcc -v
Using built-in specs.
Target: powerpc-ibm-aix6.1.0.0
Configured with: ../configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--enable-languages=c,c++,java --prefix=/opt/freeware --enable-threads
--enable-version-specific-runtime-libs --host=powerpc-ibm-aix6.1.0.0
--target=powerpc-ibm-aix6.1.0.0 --build=powerpc-ibm-aix6.1.0.0
--disable-libjava-multilib
Thread model: aix
gcc version 4.2.0

gcc command:
g++ -g -fstack-check -DAIX  -fPIC -D_REENTRANT -DTUNICODE -g -fstack-check
-DAIX -D_PTHREADS -fcheck-new -D__STL_ASSERTIONS -D__STDC_LIMIT_MACROS -c -o
updatethread.o updatethread.cpp

error:
updatethread.cpp: At global scope:
updatethread.cpp:2777: internal compiler error: Segmentation fault


-- 
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amit at mobiletornado dot com


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



[Bug c++/39409] internal compiler error: Segmentation fault

2009-03-09 Thread amit at mobiletornado dot com


--- Comment #1 from amit at mobiletornado dot com  2009-03-09 14:38 ---
Created an attachment (id=17430)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17430&action=view)
the preprocessed file (gzipped)


-- 


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



[Bug c++/33793] New: global scoping for htons/htohs fails (::htons)

2007-10-16 Thread amit dot khandelwal at lehman dot com
GCC version: 3.2.3
Host: Linux

Sample code.

#include 

int main()
{
unsigned short t;
::htons(t);
return 0;
}

/usr/bin/g++  -O2 t.cpp 
t.cpp: In function `int main()':
t.cpp:10: syntax error before `__extension__'
t.cpp:10: `__x' undeclared (first use this function)
t.cpp:10: (Each undeclared identifier is reported only once for each function 
   it appears in.)
t.cpp:10: `__v' undeclared (first use this function)
t.cpp: At global scope:
t.cpp:10: syntax error before `)' token

If I don't use -O2 the code compiles. If I change ::htons to htons the code
compiles even with -O2. Why does it fail for ::htons()


-- 
   Summary: global scoping for htons/htohs fails (::htons)
   Product: gcc
   Version: 3.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amit dot khandelwal at lehman dot com


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



[Bug libstdc++/18684] static member function not defined in std::locale::facet class

2008-01-16 Thread amit dot mitkar at gmail dot com


--- Comment #6 from amit dot mitkar at gmail dot com  2008-01-16 21:28 
---
Am seeing the same problem. I understand that its not a bug with g++ but what
about the resolution. How should one get around the issue ? 

In yanliu's second comment the said program doesn't directly reference the
function in question, yet the link still fails.

How to fix that problem ?

-Amit


-- 


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