something strange with g77 compiler

[Simone Piccardi]

Hi,
I'm not sure that this is a bug, but still it seems to me a very strange
behaviour.
I'm using ecgs 1.0.3a in a RedHat 5.2 Intel Pentium II machine.
Cause I don't know if this is depending on egcs or in the specific
installation I'm sending this report both to egcs team and RedHat

I'm writing some routines for data analysis using fortran code, and I
would like to use some other C routines to read binary files and
preprocess raw data.
To check the possibility to mix fortran and C routines I wrote a sample
Fortran program (openfile.f), using a C subroutine to make an lseek
inside a binary file
and read back some data (readfile.c). 
I wrote also a Fortran subroutine (posfile.f) to use FSeek intrinsic. 
The code is this:

openfile.f:
**********************************************************************
*
* Program openfile: this program open a file and call a C subroutine 
* to seek and read it: for testing purpose
*
* By S. Piccardi Nov. 1998
*
* Version 1.0 16-Nov-1998 First version
*
**********************************************************************
	program openfile
	character*80 filename
	integer fd,lunfile
	integer pos,bytes
	character*20 buffer
C
C OPEN file with fortran statment 
C
	filename='provafile'
	lunfile=10
	print *,'UNIT=',lunfile
	open(UNIT=lunfile,file=filename,status='old')
	fd=FNum(lunfile)
	bytes=12
	pos=81
	PRINT *,'before c code',buffer
	call readfile(fd,pos,buffer,bytes)
	print *,'position=',pos
	call posfile(lunfile,pos)
	PRINT *,'before fortran read',buffer
	read (lunfile,10) buffer
 10	format(a15)
	PRINT *,'after fortran read',buffer
	close(lunfile)
	end

posfile.f
      subroutine posfile(UNIT,OFFSET)
      integer UNIT,OFFSET,WHENCE
      
      WHENCE=0
      print *,'Sub UNIT=',UNIT
      print *,'SUb OFFSET=',OFFSET
      CALL FSeek(UNIT, OFFSET, WHENCE)
      return
      end


readfile.c
/***************************************************************
 *                                                             *
 * subroutine readfile: read a given number of bytes from an   *
 * open file aa a fixed point to a buffer                      *
 *                                                             *
 * author: Simone Piccardi                                     *
 *                                                             *
 * purpose:  test for use of open, read, lseek between a C     *
 * subroutine and a FORTRAN program                            *
 *                                                             *
 * usage: readfile(fd,pos,buffer,bytes)                        *
 *                                                             *
 ***************************************************************/

/* 
        include needed modules
*/ 
#include <stdio.h>              /* include standard i/o library */
#include <stdlib.h>             /* include standard library */
#include <string.h>             /* include string library */
#include <unistd.h>     /* include unix standard library */
#include <sys/types.h>
#include <f2c.h>
 
#define debug           /* label for debugging section */

/* program begin */
void readfile(int *fd, int *pos, char *buffer, int *bytes){
/* variables definition */
	off_t position;
	int fildes;
	off_t offset;
	int whence;
	size_t readbyte;
/*
   begin main routine 
*/
	fildes=*fd;
	printf("File descriptor number %d\n",fildes);
	offset=*pos;
	printf("Offset %d\n",(int)offset);
	whence=SEEK_SET;
	position=lseek(fildes,offset,whence);
	if (position!=offset){
		perror("cannot move in file\n");
		exit(1);
	}
	readbyte=*bytes;
	printf("Bytes to read %d\n",readbyte);
	read(fildes,buffer,readbyte);
}

and the makefile that I use for compilation is:
#----------------------------------------------------------------------
#
# Makefile for a Linux System:
# use GNU FORTRAN compiler g77
#
#----------------------------------------------------------------------
FF=g77
FFLAGS=-g -Wall  -fvxt -fno-automatic 
FFLADJ=-c
FLIBS=  -L/cern/pro/lib -lkernlib -lpacklib -lpawlib -lgraflib -lmathlib
CC=gcc
CFLAGS=-g -Wall 
CFLADJ=-c
#
# Compiler:     g77
# Flags:        -g      (enable debug) 
#               -Wall   (turn on all warnings)
#               -fno-automatic  
#                       (force compiler to use static variables)
#               -fvxt   (use VAXish extensions)
#
# Added Flags   -c      (to compile object, without linking)
#
#
#
OBJ=readfile.o




prova: openfile.f posfile.f readfile.o
	$(FF) $(FFLAGS) -o prova openfile.f posfile.f readfile.o


readfile.o: readfile.c
	$(CC) $(CFLAGS) $(CFLADJ) -o readfile.o readfile.c

clean:
	rm -f *.o 


Using these files what I have giving make command is:
cd /home/piccardi/pamela/
make 
g77 -g -Wall  -fvxt -fno-automatic  -o prova openfile.f posfile.f
readfile.o
/tmp/cca068641.o: In function `MAIN__':
/home/piccardi/pamela/openfile.f:27: undefined reference to `readfile_'
collect2: ld returned 1 exit status
make: *** [prova] Error 1

Compilation exited abnormally with code 2 at Fri Nov 20 16:56:44


if I change the C subroutine name from:
void readfile(int *fd, int *pos, char *buffer, int *bytes){
to:
void readfile_(int *fd, int *pos, char *buffer, int *bytes){
everything works fine.
No problem for the fortran subroutine posfile. 
My question is: is this behaviour right when you ant to mix code from
different
languages?

PS: I tried to use f2c integer type definition, but using:
void readfile_(integer *fd, int *pos, char *buffer, int *bytes){
instead of previous gave me these results on compilation

gcc -g -Wall  -c -o readfile.o readfile.c
readfile.c:28: parse error before `*'
readfile.c: In function `readfile_':
readfile.c:38: `fd' undeclared (first use this function)
readfile.c:38: (Each undeclared identifier is reported only once
readfile.c:38: for each function it appears in.)
readfile.c:40: `pos' undeclared (first use this function)
readfile.c:48: `bytes' undeclared (first use this function)
readfile.c:50: `buffer' undeclared (first use this function)
make: *** [readfile.o] Error 1

Compilation exited abnormally with code 2 at Fri Nov 20 17:14:49


removing the include to f2c.h did not solve the previous problem.