Compiler cc vs acc in 64 bits

Hi:
We have the "Forte C 6 update 2" and I have a C program and I need to compiler in 64bits using acc and cc
Note:
acc is the same tha /usr/ucb/cc, it which use the /usr/ccs/bin/ucbcc program. This /usr/ccs/bin/ucbcc program is a link to /opt/SUNWspro/WS6U2/bin/acc
The command that I used was:
# /usr/ucb/cc -D_BSD -c -xarch=v9 cuadraex.c
ucbcc: Warning: Option -YP,:/usr/ucblib/sparcv9:/opt/SUNWspro/WS6U2/bin/../lib/sparcv9:/opt/SUNWspro/WS6U2/bin/sparcv9:/usr/ccs/lib/sparcv9:/usr/lib/sparcv9 passed to ld, if ld is invoked, ignored otherwise
This command generated the objet file called "cuadraex.o" of 64 bits
# file cuadraex.o
cuadraex.o: ELF 64-bit MSB relocatable SPARCV9 Version 1
And now I run this command for to generate the exe file:
# /usr/ucb/cc -D_BSD -o cuadraex -xarch=v9 cuadraex.o
ucbcc: Warning: Option -YP,:/usr/ucblib/sparcv9:/opt/SUNWspro/WS6U2/bin/../lib/sparcv9:/opt/SUNWspro/WS6U2/bin/sparcv9:/usr/ccs/lib/sparcv9:/usr/lib/sparcv9 passed to ld, if ld is invoked, ignored otherwise
ucbcc: Cannot find /opt/SUNWspro/WS6U2/lib/wordalignI8.o
When I do the same with the compiler "cc", I don't have problem
# cc -c -xarch=v9 cuadraex.c
# cc -o cuadraex -xarch=v9 cuadraex.o
That's working
Can somebody help me?
Best regards

The man page for acc(1) says:
DESCRIPTION
acc (SPARC only) is not intended to be used directly on Solaris. The sole purpose for
making it available on Solaris is to enable /usr/ucb/cc. The package SUNWscpu must be
installed to use this. The options
for /usr/ucb/cc are the same as for acc and are described here.
The man page is for Solaris 8 and I have FD6.2
installed. You might want to make sure that SUNWscpu
in installed.

Similar Messages

Compilation of C program in 64 bit mode using gcc

How do i compile a C program in 64 bit mode using gcc 2.95.2. I am using Sun Os 5.8.
Pls give the command

When i use the follwing script
cc -w -v -DSOLARIS -DSOLARIS2 -m64 -c $1.c -I./. -I/usr/lib/sparcv9 -I/usr/include -I/usr/include/sys -I/usr1/soft/smshdr -I/oracle9i/precomp/public -I/oracle9i/sqllib/public
I got the following error .. Pls help
Reading specs from /opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/specs
gcc version 2.95.2 19991024 (release)
/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/cpp -lang-c -v -I./. -I/usr/li
b/sparcv9 -I/usr/include -I/usr/include/sys -I/usr1/soft/smshdr -I/oracle9i/prec
omp/public -I/oracle9i/sqllib/public -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dsparc -D
sun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__S
VR4 -D__sparc -D__sun -D__unix -Asystem(unix) -Asystem(svr4) -w -D__arch64__ -Ac
pu(sparc64) -Amachine(sparc64) -DSOLARIS -DSOLARIS2 XCupCRC.c /var/tmp/cckMTbiU.
i
GNU CPP version 2.95.2 19991024 (release) (sparc)
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/sparcv9
/usr/include
/usr/include/sys
/usr1/soft/smshdr
/oracle9i/precomp/public
/opt/sfw/include
/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/../../../../sparc-sun-solaris2
.8/include
/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/../../../../include/g++-3
End of omitted list.
/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2/cc1 /var/tmp/cckMTbiU.i -quiet
-dumpbase XCupCRC.c -m64 -w -version -o /var/tmp/ccqeBknF.s
cc1: -m64 is not supported by this configuration
cc1: -mptr32 not allowed on -m64
GNU C version 2.95.2 19991024 (release) (sparc-sun-solaris2.8) compiled by GNU C
version 2.95.2 19991024 (release).
XCupCRC.c: In function `XCupCRC':
XCupCRC.c:45: internal error--unrecognizable insn:
(insn 208 206 210 (set (reg:DI 10 %o2)
(symbol_ref:DI ("*.LLC0"))) -1 (nil)
(nil))

Compilation error, When moving from 32-bit to 64-bit code

Hello,
I m getting Compilation error, This program already compiled on 32 bit, but getting compilation error on 64 bit.
CC -V
CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25
make
Making dependencies...
cc -g -D__EXTENSIONS__ -D_SVID_GETTOD -I../h -I/app/oracle/product/9.2_32/precomp/public -I. -xcg92 `getconf LFS_CFLAGS | head -1` -D UT_TRACE_FUNCTION -Dbool=int -g -D -I. -m64 -xarch=sparcvis -H -w -E 2>&1 >/dev/null Bitmap.cc BitmapData.cc BitmapInputTxnStream.cc BitmapOutputStream.cc UnexpectedException.cc FieldData.cc FieldDataCollection.cc FieldDefinition.cc FieldDefinitionCollection.cc OutputFixedStream.cc ParsingEngine.cc Schema.cc Statistics.cc String.cc TraceStream.cc TxnStream.cc c_api.cc SocketImpl.cc Socket.cc ServerSocket.cc UnixSocket.cc Thread.cc test.cc | grep -v License | grep -v command | ../dvl.bin/mkdep >.depends
Dependencies updated...
CC -g -D__EXTENSIONS__ -D_SVID_GETTOD -I../h -I/app/oracle/product/9.2_32/precomp/public -I. -xcg92 `getconf LFS_CFLAGS | head -1` -D UT_TRACE_FUNCTION -Dbool=int -g -D -I. -m64 -xarch=sparcvis -c Bitmap.cc
"/opt/SUNWspro/prod/include/CC/Cstd/./limits", line 1046: Error: Multiple declaration for std::numeric_limits<int>.
"/opt/SUNWspro/prod/include/CC/Cstd/./ostream", line 192: Error: Multiple declaration for std::ostream::operator<<(int).
"/opt/SUNWspro/prod/include/CC/Cstd/./ostream", line 351: Where: While specializing "std::ostream ".
"/opt/SUNWspro/prod/include/CC/Cstd/./ostream", line 351: Where: Specialized in non-template code.
"/opt/SUNWspro/prod/include/CC/Cstd/./ostream", line 192: Error: Multiple declaration for std::wostream::operator<<(int).
"/opt/SUNWspro/prod/include/CC/Cstd/./ostream", line 354: Where: While specializing "std::wostream ".
"/opt/SUNWspro/prod/include/CC/Cstd/./ostream", line 354: Where: Specialized in non-template code.
"/opt/SUNWspro/prod/include/CC/Cstd/./istream", line 104: Error: Multiple declaration for std::istream::operator>>(int&).
"/opt/SUNWspro/prod/include/CC/Cstd/./istream", line 373: Where: While specializing "std::istream ".
"/opt/SUNWspro/prod/include/CC/Cstd/./istream", line 373: Where: Specialized in non-template code.
"/opt/SUNWspro/prod/include/CC/rw7/rw/defs.h", line 316: Error: A typedef name cannot be used in an elaborated type specifier..
"/opt/SUNWspro/prod/include/CC/rw7/rw/defs.h", line 317: Error: A typedef name cannot be used in an elaborated type specifier..
"/opt/SUNWspro/prod/include/CC/rw7/rw/defs.h", line 318: Error: A typedef name cannot be used in an elaborated type specifier..
"RuntimeException.h", line 131: Error: Function RuntimeException::~RuntimeException() can throw only the exceptions thrown by the function std::exception::~exception() it overrides.
"RuntimeException.h", line 97: Error: Could not find std::exception::exception(const char*) to initialize base class.
"RuntimeException.h", line 121: Error: xmsg is not a member of std::exception.
"Bitmap.cc", line 62: Error: Cannot return int(Bitmap::*)()const from a function that should return int.
11 Error(s) detected.
make: *** [Bitmap.o] Error 11
In Makefile CFLAGS setting are as follows,
### Setup common symbols for .depends
SRC = $(TEST_SRC)
INCLUDES = $(TEST_INC)
# clean objects, executeable, generated .pc -> .c
CLEAN = -r *.o $(PGM_EXEC) Templates.DB/* SunWS_cache/*
include $(ROOT)/h/common.mak
# The system include directory must be specifically included first because some of the
# ghost includes use system include file names (e.g., generic.h)
# Modified these section to compile on TVLAPP1HAG
CFLAGS += -D $(STDOUT_TRACE)
CFLAGS += -Dbool=int -g -D$(MAINLINE) $(OUR_COLLECTION)
#CFLAGS += -compat -Qoption ccfe -abirel=4.1
#CFLAGS += -Qoption ccfe -abirel=4.1
CFLAGS += -I. -m64 -xarch=sparcvis
#CFLAGS += -I. -mt
# Add the flag for multi-threaded apps
LDFLAGS += -lsocket -lnsl -lthread
# declare an empty macro for compiler directive flags, to be command-line
# driven (ie, for -D directives)
CCFLAGS=
CCFLAGS += -DRW_NO_CPP_RECURSION
# The following manipulation of CC and overriding the .cc.o suffix
# dependency is removed here to use what is supplied by default int
# the h/common.mak file.
#XX = CC
#CC = CC
#COMPILE = $(CC) -o $*.o $(CFLAGS) $(CCFLAGS) -c $*.cc
#.cc.o:
# $(COMPILE)
Please Help

Hello,
Still I am not able to solve the error. please help me.. Please see the below code...
Error:
s3dvap983:/export/home/pshirode/rel_v95/cc_lib > make
Making dependencies...
cc -g -D__EXTENSIONS__ -D_SVID_GETTOD -I../h -I/app/oracle/product/9.2_32/precomp/public -I. `getconf LFS_CFLAGS | head -1` -D UT_TRACE_FUNCTION -g -D -I. -m64 -xarch=sparcvis -H -w -E 2>&1 >/dev/null Bitmap.cc BitmapData.cc BitmapInputTxnStream.cc BitmapOutputStream.cc UnexpectedException.cc FieldData.cc FieldDataCollection.cc FieldDefinition.cc FieldDefinitionCollection.cc OutputFixedStream.cc ParsingEngine.cc Schema.cc Statistics.cc String.cc TraceStream.cc TxnStream.cc c_api.cc SocketImpl.cc Socket.cc ServerSocket.cc UnixSocket.cc Thread.cc test.cc | grep -v License | grep -v command | ../dvl.bin/mkdep >.depends
Dependencies updated...
CC -g -D__EXTENSIONS__ -D_SVID_GETTOD -I../h -I/app/oracle/product/9.2_32/precomp/public -I. `getconf LFS_CFLAGS | head -1` -D UT_TRACE_FUNCTION -g -D -I. -m64 -xarch=sparcvis -c Bitmap.cc
"/opt/SUNWspro/prod/include/CC/rw7/rw/defs.h", line 316: Error: A typedef name cannot be used in an elaborated type specifier..
"/opt/SUNWspro/prod/include/CC/rw7/rw/defs.h", line 317: Error: A typedef name cannot be used in an elaborated type specifier..
"/opt/SUNWspro/prod/include/CC/rw7/rw/defs.h", line 318: Error: A typedef name cannot be used in an elaborated type specifier..
"RuntimeException.h", line 137: Error: Function RuntimeException::~RuntimeException() can throw only the exceptions thrown by the function std::exception::~exception() it overrides.
"RuntimeException.h", line 103: Error: Could not find std::exception::exception(const char*) to initialize base class.
"RuntimeException.h", line 127: Error: xmsg is not a member of std::exception.
"Bitmap.cc", line 62: Error: Cannot return int(Bitmap::*)()const from a function that should return int.
7 Error(s) detected.
make: *** [Bitmap.o] Error 7
96 class RuntimeException : public xmsg {
97 public:
98
99 /**
100 * Create an exception with a simple error message
101 * @param message The error message
102 */
103 RuntimeException(const char* msg) : xmsg(msg) {}
104
105 /**
106 * Create an exception with an error code, fileinfo, and message. This will
107 * produce an error message that looks like:
108 * in File:%s at line#: %d \n %error_message%
109 *
110 * @param error An integer error code. The catch block can use the error()
111 * method to examine this value
112 * @param fileinfo The location in a source file where the error occured
113 * @param msg The error message
114 * @see RuntimeException.error
115 */
116 RuntimeException(int p_error, const Fileinfo& f, const char* msg)
117 {
118 error = perror;
119 strstream buffer;
120 buffer << "in File:"
121 << f.filename()
122 << " at line#:"
123 << f.lineno() << endl << msg
124 << ends; // required for this strstream library, other versions
125 // like Borland the stream is always null terminated
126
127 xmsg::xmsg(buffer.str());
128 delete buffer.str(); // added by db 03-Jul-98 accoprding to the
129 // ssbuf(3C++) man page - other implementations may
130 // use malloc/free but Solaris uses new/delete
131 }
132
133 /** @return the error code */
134 int error() {return _error;}
135
136 /** Clean up instance */
137 virtual ~RuntimeException() {}
138
139
140 protected:
141
142 /**
143 * Default constructor - not very useful to throw an exception without at
144 * least an error message, so this is reserved for only subclasses.
145 */
146 RuntimeException() : xmsg() {}
147
148 private:
149
150 /** the error code associated with the error */
151 int _error;
152 };
153

Issues Compiling using CC on solaris 64 bit

I am trying to use Wall command along with cc Compiler on Solaris 64 bit but it throws me the error:
"cc: illegal option -Wall".
I have been working on gcc for a while and this is my first encounter with cc compiler.
Please provide the corresponding alternative for Wall on CC
Thanks in advance
-SJ

Well, do you mean cc or CC.
cc is the sun C compiler. CC is the sun C++ compiler
-Wall is a gccism. All it does it turn on more compiler warnings.
So its hardly a critical feature
if you need to know about cc/CC options then try "man CC" or "man cc"
You will probably have to add /opt/SUNWspro/man to your manpath first.
Looking through the CC man page -verbose=diag appears to be the closest equivalent.
The closest I see in the cc man page is just "-v"
This is from studio 7. The options may have changed in more recent versions..

Fbe internal error when compiling OpenSSL 1.0.2 64 bit

./Configure solaris64-sparcv9-cc no-shared -m64 -xcode=pic32 -xldscope=hidden
./make
cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -xcode=pic32 -xldscope=hidden -xtarget=ultra -xarch=v9 -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c -c -o md5-sparcv9.o md5-sparcv9.S
cc: Warning: -xarch=v9 is deprecated, use -m64 to create 64-bit programs
/opt/solarisstudio12.4/bin/fbe: "/tmp/cpp.1426232079.27660.01.s": , approx line 1041: internal error: pic_relocs(): hh reltype?
Reading around, it seems to be caused by setting -xcode=pic32 but I need to set that because I am building a static library that will be linked into a shared library and that requires relocation.
Changing the makefile so that the -xcode=pic32 flag is not passed when compiling .s files solves the problem but I am unsure if I will have an invalid build.
Previous OpenSSL versions have compiled cleanly with this flag set.
Does the message 'internal error' indicate that it is a bug in the compiler? If so is there a fix?
Can anyone advise please?

Internal errors, such as the one you encountered, are generally considered compiler bugs. They indicate that the compiler reached an unexpected state and therefore bailed out. I opened bug 20703141: internal error: pic_relocs(): hh reltype? to investigate. I see the same error message emitted by the current Studio development release; I will update this thread if I find a work-around.
Thanks,
Mark

Visual Studio compiling 64 Bit Plugin for InDesign Server CS5

Hello guys,
Again I have a problem compiling 64 bit plugins, but this time in windows environments, the 32 bit compiling works fine (also on 64 bit machines). The first thing I've done was creating a new project configuration for 64 bit environments copying the 32 bit settings. Now I changed the precompiled libraries to use the 64 bit ones and changed the output directories. After that the compilation process completed without errors, but the resource files have not been copied to the output directory (the directory for them has been created, but it remains empty). Adding the created plugin into the servers directory ends up with a server message that the plugin could not be recognized. Have I missed something that is necessary for compiling 64 bit plugins?
I'm using the 64 Bit Developer Version of the indesign server CS5. The operating system is a Windows Server 2008 x64 R2 with Visual Studio 2008.
Thanks!
P.S. a plugin compiled with 32 bit settings (including 32 bit libraries) also works for the 64 bit version of the server, so does it make any difference if I'm using 32 bit or 64 bit libraries?

The libraries were all correct (all using 64-bit). The problem was a pathing issue. libxml2 needs iconv.dll, but it couldn't find the 64-bit version that I built. Once it found it, everything worked correctly.
The funny thing about depends.exe is that it isn't right all the time. For example, if you open one of the 64-bit .aip files that ships with Illustrator (rename it to .dll first), you'll see what I'm talking about. It complains that you're mixing x86 and x64 CPU types, even though you're not.
The program I used to discover my issue is Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx). I've been using it for years and love it.

64-bit compilation problem on Solaris/Intel: 7th argument not initialized

I have a problem when compiling a program on a 64-bit Solaris Intel server. The problem is that when calling a function, if the 7th or next arguments are long arguments and I pass uncasted small integers values to it, the first 32-bit of my values are uninitialized.
I have isolated the problem in the following source code.
#include <stdio.h>
#include <strings.h>
void fnc1(a,b,c,d,e,f,g,h)
long a,b,c,d,e,f,g,h;
printf("%ld,%ld,%ld,%ld,%ld,%ld,%ld,%ld\n", a,b,c,d,e,f,g,h);
void main()
fnc1(0x10101010deadbeef,0x20202020deadbeef,
     0x30303030deadbeef,0x40404040deadbeef,
     0x50505050deadbeef,0x60606060deadbeef,
     0x70707070deadbeef,0x80808080deadbeef);
fnc1(1,2,3,4,5,6,7,8);
}I compile it using the following command:
cc src1.c -g $* -m64 -o prog1.exeWhen I run the resulting .exe, I get the following result:
1157442768875667183,2314885534015405807,3472328299155144431,4629771064294883055,5787213829434621679,6944656594574360303,8102099359714098927,-9187201948855714065
1,2,3,4,5,6,8102099355978170375,-9187201952591642616The problem is that the first 32 bits of my 7th and 8th arguments are not initialized when the function is called.
I know that in the following cases, I do not have the problem:
- if I cast the arguments;
- on other platforms (AIX, SunOs/Sparc, HPUX) or if I compile in 32-bit;
- if I use optimization (-xO1 to -xO5) ;
- if I prototype my function at the beginning of my source (void fnc1(long a,long b,long c,long d,long e,long f,long g,long h););
I have over 1,000,000 lines of existing code to support. I am afraid using optimization would have other impacts and for now, I cast the arguments as problems are reported. Would there be a better way to handle this? By using a compiler switch?
Thanks in advance.

Tom.Truscott wrote:
clamage45 wrote:
But if you are passing to an ellipsis, you either cast actual arguments to the type the function expects, or the function extracts the default promoted type. Such code always works ...Yes, and developers should attempt to accomplish just that. Alas this is very difficult to ensure, particularly given the lack of a run-time type checking mechanism.In theory, proper use of the ellipsis function would be documented, and programmers would read and follow the documentation. In practice, some programmers don't read the instructions, or forget them, or someone ill-advisedly changes the way the function works so that existing calls stop working. Variable-argument functions are a fragile mechanism. (I program almost exclusively in C++, which has combinations of features such that variable-argument functions are rarely, if ever, needed.)
Can one even assume that the value of the NULL macro is correct? Never, because the C standard allows a variety of definitions for NULL, and implementations vary. Passing NULL to an ellipsis is a recipe for failure. Don't do it.
>
Suppose you have function FI with an ellipsis that expects to get int arguments, and another FL that expects to get long arguments. When you port the code to a 64-bit environment, function FL fails. If you use the -signext option, function FI will fail.Ah, but for us FL never fails, since the compilers always widen the arguments. I fail to see the circumstance in which widening would cause FI to fail, could you please give a more specific example?
void FI(int count, ...)
    va_list va;
    va_start(va, count);
    int t;
    while( --count >= 0) {
       t = va_arg(va, int);
       do_something(t);
}Function FI expects to extract 32-bit int arguments. If compiled with -signext, the calling function will pass 64-bit arguments. Perhaps the -signext option also causes the 32-bit extraction to be changed to a 64-bit extraction. I have no personal experience with the option, and I'm not in a position where I can experiment right now.

SDK CVI compiler Warnings 64-bit

It seems I am finding CVI Compiler warnings when compiling 64 Bit applications with SDK. I don't get these warning errors when I compile the same applications for 32 Bit.
For example the CVI Compiler warning that I just found was found when I used SDK header file: "SetupAPI.h" with the typedef struct: SP_DEVINFO_DATA and SP_DEVICE_INTERFACE_DATA.
The warning message I got was when I compiled the statements with the SetupAPI.h file included:
SP_DEVINFO_DATA DeviceInfoData;
/* warning message */
DeviceInfoData.cbSize = sizeof(SP_DEVINFO_DATA);
// Warning: Conversion from 'unsigned __int64' to 'DWORD' might lose data.
/*warning message*/
SP_DEVICE_INTERFACE_DATA did = {sizeof(did)};
// Warning: Conversion from 'unsigned __int64' to 'DWORD' might lose data.
When I compile these statements in 32-Bit I don't get these errors.
Of course I can change the "SetupAPI.H" SDK Header supplied by NI but that defeats the whole purpose of why NI would distribute the header file in the first place.

OK - Milan -
I think you misunderstood what I was writing about.
If you look at the SetupAPI.h file that is supplied by NI SDK with CVI 2010 at line 700 with the following typedef struct:
// Device information structure (references a device instance
// that is a member of a device information set)
typedef struct _SP_DEVINFO_DATA {
    DWORD cbSize;
    GUID ClassGuid;
    DWORD DevInst;    // DEVINST handle
    ULONG_PTR Reserved;
} SP_DEVINFO_DATA, *PSP_DEVINFO_DATA;
The DWORD is defined as
"typedef unsigned long"
in cvidef.h (CVI 2010) header file.
Yes I could change the SetupAPI.h inside the header file to change the type to be __int64 instead so that it works with 64 Bit. However, if other applications that are written for 32 bit will now be impacted if the SetupAPI.h is used with the __int64 data type DWORD.
So what NI should so everywhere where they define "DWORD" that is used in the SDK they should have a conditional compile to set the type to "typedef __int64" in CVI 64-bit applications and
"typedef unsigned long" in 32 Bit Applications.

64 bit compilation using gcc - please help

Hi All,
My system runs on
SunOS SUNSMART 5.9 Generic_112233-08 sun4u sparc SUNW,Sun-Fire-280R
i have a c program which compiles and runs perfectly. Now i came to know that using the -xarch=v9 option with the gcc which compiling we can produce a 64 bit executable. I compiled the program like this
gcc -c GbmCashTran.c
gcc -o GbmCashTran GbmCashTran.o *.so -xtarget=native -xarch=sparcv9 -lsocket
but when i check whether it has compiled as 64 bit executable using the 'file' command like
file GbmCashTran
it gives the result as
GbmCashTran: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped
why is this???
Please tell me how to compile this c program into a 64 bit executable.......
tanx
bala

By all the accounts I've seen, gcc 2.95.x will produce 64-bit executables for SPARC. The first version which appears to work (after significant handholding) is gcc 3.0. You can see a fairly good description of how to bootstrap the gcc 3.0 build into a working 64-bit compiler here
http://www.well.com/~jax/rcfb/solaris_tips/build_gcc_3.0_64bit.html
Also, you can find prebuilt and installable versions of gcc at
http://sunfreeware.com/
I think the version there is 3.3.2

64 bit driver compilation

hi,
i need to compile a driver code in 64 bit using forte 6.2.
there is a function declaration and function definition,
something like:
xx_ioctl (dev, cmd, arg, flag, credp, rval-p);//prototype
dev_t dev;
int cmd;
int arg;
int flag;
cred_t credp;
int *rval-p;
//definition
xx_ioctl(ignorethisone,ignorethisone,(caddr_t)arg,ignorethisone,ignorethisone) { do things;}
i was getting cast warning at the "(caddr_t)arg" argument in above.
I changed the "int arg" to "long arg" and that solved all the warnings.
is this valid?.
-Raoul

First, make sure you are using SC5.0 compilers. The -xcode option did not exist before that. Using -xcode=abs32 will give you smaller generated code.
The -xregs=no%appl option tells the compiler not to use %g2 or %g3 registers on sparcv9. I believe this was needed only to work around a run-time linker bug prior to S7 5/99. If your driver needs to run on an earlier update of S7, you should use this option; otherwise, it is not needed.
Also read the compilation section of the
Writing Device Drivers book

Compiling 64bit packages under a normal 32 bit arch installation

Hello!
For making packages (e.g. custom kernels) I have a virtual arch installation 32 bit (vmware). After the package is compiled I copy it to the destination machine and install it.
At the moment I want to install my first 64 bit archlinux and I want to make a custom kernel for the system. Is it possible to get the 64 bit tree of arch linux and compile it for my 64 bit system under my 32 bit virtual machine?
Second question: Can I use the normal custom kernel script (wiki article: http://wiki.archlinux.org/index.php/Cus … _with_ABS) for a 64 bit kernel?
Greetings,
Flasher

This shouldn`t work within a 32bit-system. But you can compile 32bit-stuff on a 64-bit machine (using a chroot environment).

Ntopng compilation and installation on Windows Server 2008 R2

Hi All, need some help on how to compile ntopng source to windows 64-bit OS.
I tried to look for some good solutions but nothing.
Cheers, JK

On Tue, 2 Sep 2014 10:04:26 +0000, njk84 wrote:
Hi All, need some help on how to compile ntopng source to windows 64-bit OS.
I tried to look for some good solutions but nothing.
You're asking about a non-Microsoft product. You should asked the providers
of the software this question.
http://www.ntop.org/support/need-help/
Paul Adare - FIM CM MVP
An ASCII character walks into a bar and orders a double. "Having a
bad day?" asks the barman. "Yeah, I have a parity error," replies the
ASCII character. The barman says, "Yeah, I thought you looked a bit
off." -- Skud

How to develop a plugin for 64-bit windows 2008 server?

I have developed a plugin to open local application from web pages, but the plugin could only run on 32-bit windows and 32-bit and 64-bit windows 7, it couldn't work on 64-bit windows 2008 server. The plugin was compiled by vs2008 studio on 32-bit windows xp. Any instructions or advices, men of genius? Thanks

Hi Gnittala,
Thanks for your reply.
I debug the javascript code in firebug on windows 8 and found that firefox would be not responding while executing "document.body.append(myPlugin)".
My javascript code is below:
function openLocalApp(cmdPath, cmdLine) {
var npMyPlugin = navigator.mimeTypes["application/mozilla-npruntime-scriptable-plugin"];
if (npMyPlugin) {
var myPlugin = document.createElement("embed");
myPlugin.style.visibility = "hidden";
myPlugin.type = "application/mozilla-npruntime-scriptable-plugin";
myPlugin.width = 0;
myPlugin.height = 0;
document.body.appendChild(myPlugin);
myPlugin.foo(cmdPath, cmdLine);
} else {
alert("Failed to create the plugin!");
And firefox plugin's source code copys from the following link:
http://mxr.mozilla.org/seamonkey/source/modules/plugin/samples/npruntime/
Just changed a little.
I know the sample is very old, but newer proper sample couldn't be found. So if you can give me a newer sample, I'll appreciate.
Thanks again.

64 Bits and Motif

I compile a Motif application in 64 bit as follows:
CC -xtarget=generic64 -g -c fonttest.C
CC -xtarget=generic64 -g -o fonttest fonttest.o -lstdc++ -lm -lXm -lXt -lX11
it compiles just fine. But when I run it I get the following errors at runtime:
Warning: Cannot convert string "-dt-interfacesystem-medium-r-normal-m*-*-*-*-*-*-*-*-*" to type FontSet
Warning: Unable to load any usable fontset
Warning:
Name: FONTLIST_DEFAULT_TAG_STRING
Class: XmRendition
Conversion failed. Cannot load font.
this error repeats several times. I load a font manually for the
drawing area and it works fine, but the (default) fontset stuff fails.
Anyone have any ideas?
Thanx,
scott

When you load a font by hand, do you load this font,
or some other? The message means that your app can't
find the font requested. Find some font you know that
you have and use it. You may be setting a default
font in one of your dot files.

F1 key for help not working in 32-Bit Application

OS : Windows Embedded Standard with Service Pack 1
System Type : 64-bit Operating System
Problem: Our application is a 32-Bit Windows Form application which runs fine on the intended OS. However when the user hits F1 the help is not displayed. I cannot find any errors System Event event log. I created a small Windows
Form TEST application that mimics the problem. When I compile the TEST application for 32-Bit specifically and hit the F1 button nothing happens. I then compile the same TEST application for Any-CPU which will run as 64-Bit the help is displayed
when the F1 key is hit.
Our Windows Form application must run as a 32-Bit due to legacy reasons. This same application runs fine in any other version of Windows ( Windows 7, Windows Server 2008, Window 8.1). That is, help is always displayed .
What should my next step to help resolve this problem?

This forum is for POSReady. You posted to the correct WES7 forum already.
www.annabooks.com / www.seanliming.com / Book Author - Pro Guide to WE8S, Pro Guide to WES 7, Pro Guide to POS for .NET

Compiler cc vs acc in 64 bits

Similar Messages

Maybe you are looking for