Greeetings all,
As an Interix user on x64 I was excited to hear about PGIs compiler. At the moment there is only one other compiler available AFAIK. I downloaded an evaluation version for x64 SUA and installed it. Unfortunatly the installer failed due to wrong permissions applied to the installed directories (it removed all permissions). After some tweaks and a couple of reinstallations, I managed to get it right (I think). It would be advisable to update the installer, it really needs to be fool-proof. The 2 weeks evaluation period is also far too short.
When I did my first test compile I run into a bug: The -largeaddressaware:no linker switch needs to be added to ldrc(121).
When compiling e.g. test compile of GNU make I get some strange warnings:
PGC-W-0114-More than one type specified (/opt/pgi/sua64/7.0-6/include/sys/types.h: 143)
PGC-W-0143-Useless typedef declaration (no declarators present) (/opt/pgi/sua64/7.0-6/include/sys/types.h: 143)
PGC-W-0115-Duplicate standard type (/opt/pgi/sua64/7.0-6/include/sys/types.h: 148)
PGC-W-0143-Useless typedef declaration (no declarators present) (/opt/pgi/sua64/7.0-6/include/sys/types.h: 148)
PGC-W-0114-More than one type specified (/opt/pgi/sua64/7.0-6/include/sys/types.h: 256)
PGC-W-0143-Useless typedef declaration (no declarators present) (/opt/pgi/sua64/7.0-6/include/sys/types.h: 256)
I can’t figure out why.
The compiler includes the Interix gcc.3.3 x86 headers and libs - are you sure this is right?
What about gcc shared libraries? Are they supported in x64 and if so, how to enable, create and use them? Since the linker ultimately is the MS x64 linker, it would be interesting to hear if you have found a solution of this.
sys/types.h(143) => typedef u_int32_t uid_t;
which expands to
typedef unsigned int u_int32_t;
pgcc appears to choke on typedefs on typedefs? This behavior causes pgcc to fail some configure scripts resulting in wrong configuration. Is there any switches that need to be assigned?
I concluded that shared libraries are not supported in Interix by PGI.
Unfortunatly the installer failed due to wrong permissions applied to the installed directories (it removed all permissions).
I’ll pass this on.
The 2 weeks evaluation period is also far too short.
Please contact PGI Sales at sales@pgroup.com. They can usually extend this for you.
When I did my first test compile I run into a bug: The -largeaddressaware:no linker switch needs to be added to ldrc(121).
Can you please describe the bug?
When compiling e.g. test compile of GNU make I get some strange warnings:
It appears to me that for these messages that “uid_t” might be getting declared elsewhere. However, I’m unable to recreate the issue here so am not positive. What include files are you using? What command line arguments are you using?
The compiler includes the Interix gcc.3.3 x86 headers and libs - are you sure this is right?
Yes. A few of GNU header files are not interoperable with PGI compilers and needed to be rewritten. However, we do try to keep the header files as close to the original version as possible.
What about gcc shared libraries? Are they supported in x64 and if so, how to enable, create and use them? Since the linker ultimately is the MS x64 linker, it would be interesting to hear if you have found a solution of this.
We have been working closely with Microsoft on creating a linker which will be able to create shared libraries on 32-bit SFU. This linker will be available with the 7.0-7 release. Prior releases and 64-bit SUA do not support GNU style shared libraries.
I appears to me that for these messages that “uid_t” might be getting declared elsewhere. However, I’m unable to recreate the issue here so am not positive. What include files are you using? What command line arguments are you using?
It did that to me to as well, so I checked the Interix SDK headers. Some defines are guarded with GNUC and _MSC_VER - quite unnecessary actually - so I unified them and removed the compiler conditionals. That is: First part of types.h, inttypes.h where int64_t and friends are defined. There is no duplicate uid_t define, but there are exact duplicates of other defines in the headers, of size_t for example. My stdint.h is edited to pass the autoconf C99 test (carefully done!). There could be some detail inflicted by me somewhere causing the problem, one never know. However, gcc, icl and the MS compiler have no problem.
It seems to me that pgcc have problems with typedefs like this:
typedef unsigned long long int uint64_t;
I was thinking there could be a switch like “enable ANSI C”-whatever missing.
I don’t remember exactly what the message was, but the linker complains about “ADDR32” conversion without this switch in the PGI libraries and refuse to link. I’m using the MS x64 linker 8.00.50727.762 (VS2005 SP1).
7.0-7 release for SUA
Something to look forward to, I think! So, will this release have a GNU-style ld or a MS linker interface?
While it does sound like you know what you’re doing, modifying system include files is generally not a good idea. Unfortunately, I don’t have any good advice for you except to try it with the original headers. Note that these are just warnings so may be ignored. However, I leave this up to you.
It seems to me that pgcc have problems with typedefs like this:
typedef unsigned long long int uint64_t;
Can you please give an example of the problem you see? The following toy program is able to handle this typedef without any issue.
%cat myt.c
typedef unsigned long long int uint64_t;
typedef uint64_t myi64_t;
void main () {
myi64_t i;
i = 123123123;
printf("%ld\n", i);
}
%pgcc myt.c
%./a.out
123123123
I was thinking there could be a switch like “enable ANSI C”-whatever missing.
Can you please clarify?
I don’t remember exactly what the message was, but the linker complains about “ADDR32” conversion without this switch in the PGI libraries and refuse to link.
Where you trying to use the generated objects in a DLL? If so, then this is not yet supported for 64-bit SUA. You may consider using the PGI Windows compilers which do support DLL creation.
Something to look forward to, I think! So, will this release have a GNU-style ld or a MS linker interface?
The 32-bit SUA/SFU compilers will use a GNU-style linker while the 64-bit SUA compilers will use MS link.
modifying system include files is generally not a good idea
No, but with Interix headers there are some issues, especially with the MS compiler and LP64. You cannot use the original headers in x64 without a compiler with LP64 support. cc and l2ll - OK, but not in VS. There are a few bugs, discovered in SUA 5.2, still appears in the Longhorn beta.
$ ./a.out
123123123
You’re right, there must be a conflict somewhere in the headers. I look into that again. pgcc have ANSI C as standard, right? I was thinking if a switch like -c89/-c99 was needed.
Where you trying to use the generated objects in a DLL? If so, then this is not yet supported for 64-bit SUA. You may consider using the PGI Windows compilers which do support DLL creation.
No, just a first simple testprogram. You must be able to recreate it with a fresh pgcc installation. The only thing I changed was the PSDK directory to my VS installation (which contains newer versions of the tools). It all depends on how the PGI libraries was linked. I only tested the x64 version, I doubt there is a problem in 32bit.
The 32-bit SUA/SFU compilers will use a GNU-style linker while the 64-bit SUA compilers will use MS link.
That sounds great and very interesting if you manage to get shared library support.
pgcc have ANSI C as standard, right? I was thinking if a switch like -c89/-c99 was needed.
By default the PGI C compilers use C99. To use C89 use “-c89”.
Would it be possible for you to write-up a report and sample code about the ADDR32 error you’re seeing and send it to PGI customer support at trs@pgroup.com? I’d like to have an engineer look at it.
write-up a report and sample code about the ADDR32 error you’re seeing
OK, I post it here as well.
// test_longtype.c
extern int __cdecl printf (const char *, ...);
int __cdecl main(void)
{
int size = sizeof(int);
printf("size of int is %u\n", size);
size = sizeof(long);
printf("size of long is %u\n", size);
return 0;
}
$ pgcc -O1 -o test_longtype test_longtype.c
libpgc.a(stkchk.o) : error LNK2017: 'ADDR32' relocation to '.data' invalid without /LARGEADDRESSAWARE:NO
...
libpgc.a(trace_interix.o) : error LNK2017: 'ADDR32' relocation to '.data' invalid without /LARGEADDRESSAWARE:NO
LINK : fatal error LNK1165: link failed because of fixup errors
My fix:
ldrc(121) /subsystem:$SUBSYS … /largeaddressaware:no /machine:$MACHINE[/quote]
autoconf tests that terminate with “TERMINATED by signal 13” I discovered so far. As I understand the tests are aborted before completed resulting in wrong configuration.
AC_AIX - checking for AIX
AC_HEADER_STDC - checking for ANSI C header files
AC_TYPE_UID_T - checking for uid_t in sys/types.h
AC_FUNC_GETLOADAVG
AC_CACHE_VAL
AC_EGREP_CPP
exactly why is beyond me. Some of these may fail due to other macros.
I got the same error pgc TERMINATED by signal 13 then uses GNU configure
to fix that error I defines export CPP=pgprepro in /etc/profile.lcl
PS:
$ uname -a
Interix droopy 5.2 SP-9.0.3790.4125 authenticamd AMD64_Family_15_Model_47_Stepping_2
PPS: I found better solution ;) export CPP=“pgcpp -U__cplusplus -E”