Win32 API with pgf90 7.0-3

Accelerated Computing HPC Compilers Legacy PGI Compilers
1

Hi,

this is an issue with pgf90 7.0-3 under WindowsXP together with gcc 3.4.4

I have a small C program that gets the MAC addresses on a machine, using GetAdaptersInfo() after #include <iphlpapi.h>, convert it to a string, and now I would like to pass it to a Fortran program.

The C function works fine, a simple Fortran program that calls that routine, compiled with g77 3.4.4, prints out the MAC address:

program macadd
integer ret
character13 mac
call get_winmac(mac,ierr)
write(,*) 'MAC: ',mac
end

g77 -g -fno-second-underscore main.f get_info.o -liphlpapi -lnetapi32

works.

But, when I use pgf90 instead of g77, there are several problems:

  1. libiphlpapi.a and libnetapi32.a are not found, because pgf90 wants to have a *.lib file … annoying, but a simple cp *.a to *.lib helps

  2. If my C program has a static array of predefined size like:

IP_ADAPTER_INFO ainfo[16];

gcc uses __alloca from the glibc to put it on the stack.

If I link with pgf90, it complains about undefined reference to __alloca, and if I tell pgf90 to use /usr/lib/libc.a (or libc.lib after copying it, see above), I guess that I get a mixture of different glibc versions… and the link step fails.

Solution: if I use malloc() for ainfo, it works.

  1. Finally, I get an executable:

pgf90 -g -Mfree -Munix main.f get_info.o -liphlpapi -lnetapi32

but the resulting main.exe crashes before even entering the first line in the C function - and gdb has no idea where or why.


So I guess that the libiphlpapi.a and libnetapi32.a from /usr/lib of my cygwin are not usable with pgf90. Is there anything I can do to get a function that gives the MAC addresses of the installed devices using pgf90 and gcc?? Any idea why the Win32API libraries can not be used??

Uwe

2

Hi Uwe,

Unfortunately in order to support interoperability with the Microsoft C compiler, we do not support interoperability Cygwin GNU. You can try the PGI 6.0 release which does support liking with Cygwin libraries, however this support is limited to the specific version of Cygwin which accompanies the compiler and may not have the functionality you require.

  • Mat
3

Hi,

PGI 6.0 for Windows was very unstable, I tried to compile our code, but gave up after a while. We are also using PGI Compilers under Linux, and there PGI 6.2 was the first 6.x release that we were able to use (and we are still using it for X86_64 systems).

So 6.0 will simply not work for several other reasons. I was hoping that PGI 7.0 will be usable the same way 5.2 was on Windows, and thought that the PG Visual Fortran is the one that should work with MS C… We are porting Unix code, and I was waiting several months for a new PGI on Windows version, simply to be able to use all those Makefiles on the bash that comes with PGI.

Will there ever by a Fortran Compiler for Windows that fully supports gcc from PGI?

By the way: Is there any flag to tell pgf90 7.0 to link *.a libraries instead of seraching for *.lib files when using -lname ?

Uwe

4

Hi Uwe,

So 6.0 will simply not work for several other reasons. I was hoping that PGI 7.0 will be usable the same way 5.2 was on Windows, and thought that the PG Visual Fortran is the one that should work with MS C… We are porting Unix code, and I was waiting several months for a new PGI on Windows version, simply to be able to use all those Makefiles on the bash that comes with PGI.

Have you investigated SUA? See HERE

Will there ever by a Fortran Compiler for Windows that fully supports gcc from PGI?

We are interoperability with Native Windows Objects and any compiler which also supports Native Windows Objects. I believe the SUA GCC does support native objects, but the Cygwin version does not.

By the way: Is there any flag to tell pgf90 7.0 to link *.a libraries instead of seraching for *.lib files when using -lname ?

No but since we do have an environment variable for objects, PGI_OBJSUFFIX, adding an environment variable for libraries wouldn’t be difficult. If you like I can send the compiler team a feature request or if you prefer, please send a note to customer support trs@pgroup.com.

Is there any reason why you can’t use PGCC and Microsoft’s native object libraries? You can still use Cygwins’s make utility but also allow your programs to be run both in Cygwin and natively.

  • Mat
5

Hi Mat,

Have you investigated SUA?

some time ago, and decided to run cygwin instead.

No but since we do have an environment variable for objects, PGI_OBJSUFFIX, adding an environment variable for libraries wouldn’t be difficult.

Thanks!! I did not find that in the documentation, perhaps I was not looking for the right keywords. Makes it a lot easier NOT to edit 85 Makefiles…

Is there any reason why you can’t use PGCC and Microsoft’s native object libraries? You can still use Cygwins’s make utility but also allow your programs to be run both in Cygwin and natively.

The reason is quite simple: gcc worked just fine until yesterday… no need to buy a C compiler, if I have already one.

The funny thing is that we have more than 3000 Fortran files (with one or several subroutines), and 8 C functions. gcc with pgf90 under Win32 runs without problems, but obviously simply because we do not have any WIN32-APIs calls… Meanwhile the C functions could be replaced by Fortran too, but I guess that there is no way to get a MAC address out of Fortran or from gcc without using the WIN32-API.

Thanks, Mat, for the very fast and detailed support !! I will try SUA again or buy pgcc.

Uwe

6

Update:

We have an old Visual C Compiler from Microsoft on one of our machines here, so I took the object file from that VC. Compiling and linking was no problem, binaries do run as they should.

Thanks Mat,

Uwe

7

Hi Uwe,

That’s good news.

FYI, I added TPR#4222 to requests a new environment variable “PGI_LIBSUFFIX” which would allow you to toggle the library suffix from “.lib” to “.a”. While I don’t know exactly when this will be added, given it’s fairly easy, I would assume it will be in 7.0-6 currently scheduled for the beginning of August 2007. Also, I sent a note to our documents person that PGI_OBJSUFFIX is not included in our User’s Guide.

Thanks,
Mat