[Q] can't resolve symbol '__getcwd' error in arla 0.20 and 0.21

[Takashi Ichihara]

>  Hi all
>
>  It seems that in some enviromnents, the getpwd (libgetcwd.so.0.21 
>or getcwd.so in arla 0.20) seems to have a problem. This problem 
>occurs in the arla version 0.21 and 0.20 and there is no problem 
>in the previous version (arla-0.19, 0.18, 0.17.1, I have checked)
>
>   I have two different environments of "Linux Kernel 2.2.0 + 
>Arla 0.21".  One (Enviromnent 1) has this problem and the other 
>(Environment 2) does not have this problem.  
>
>Does anyone has any idea ?   
>
>--------------
>Environment 1
>--------------
> 
>  Dual Pentium II 450 MHz, 256 MB Memory, IDE 4G HD 
>  Redhat 5.1 + several upgrade softwares installed
>  Kernel 2.2.0 (SMP support option)
>  arla   0.21  (libgetcwd.so.0.21 pre-load)
>  uname -a : Linux xxxxx.rrrrr.bnl.gov 2.2.0 #1 SMP Tue Jan 26 21:30:30 
>             EST 1999 i686 unknow
>
> Problem
> -------
>
>  The pgf77 (PGI fortran) and f77 (Absoft fortran) does not work when 
>libgetcwd.so.0 is pre-loaded (error - can't resolve symbol '__getcwd),
>while g77 (GNU F77) still works.
>
>  csh> pgf77 sim,f                             (PGI fortran : NG)
>  pgf77: can't resolve symbol '__getcwd' 
>
>  csh> f77 sim.f                               (Absoft fortran: NG)
>  f77fe: can't resolve symbol '__getcwd'
>  /usr/bin/f77: sim.int: No such file or directory
>                                      				      
>  csh> g77 sim.f                      	       (GNU fortran: ok)
>  csh>       
>
> o When the libgetcwd.so.0 (getcwd.so) is not pre-loaded, both the 
>   pgf77, f77, and g77 works fine.  (But pwd of csh or tcsh does not 
>   work under /afs directory)  
>
> o alra-0.17.1 + kernel 2.2.0 DOES NOT have this problem. This works.
> o arla-0.18   + kernel 2.2.0 DOES NOT have this problem. This works.
> o arla-0.19   + kernel 2.2.0 DOES NOT have this problem. This works.
> o arla-0.20   + Kernel 2.2.0 has this problem. 
>
>  Therefore, this problem of  "can't resolve symbol '__getcwd' " seems 
>to be introduced in arla-0.20 and also continues to arla-0.21.


     If I copy the ~arla-0.19/xfs/linux/getcwd.c to ~arla-0.21/xfs/linux/
getcwd.c and make libgetcwd.so and pre-load this libgetcwd.so, then the 
erros above of " can't resolve symbol '__getcwd'" completely disappears.  

  The main parts of the two sources are

arla-0.21/xfs/linux/getcwd.c
|
| char *getcwd(char * buf, size_t size)
| {
|     int retval;
|
|     retval = sys_getcwd(buf, size);
|     if (retval >= 0)
|         return buf;
|     if (errno == ENOSYS)
|         return __getcwd(buf, size);
|     else
|         return NULL;
|  }

arla-0.19/xfs/linux/getcwd.c
|
| char *getcwd(char * buf, size_t size)
| {
|    int retval;
|
|    retval = sys_getcwd(buf, size);
|    if (retval >= 0)
|        return buf;
|    errno = -retval;
|    return NULL;
}

  So, the following three statemens in getcwd.c of arla 0.21 and 0.20
 
>   if (errno == ENOSYS)
>          return __getcwd(buf, size);
>    else
 
seem to make our problem of   " can't resolve symbol '__getcwd'" .
I can temporaly remove our problem by eliminationg these three lines. 
Is this a good thing ?

					Takashi Ichiahra

>
>-----------------
>Environment (2)
>-----------------
>
>  Pentium pro 200 MHz, single CPU, 128 MB Memory,  IDE 4GB HD
>  Redhat 5.2 installed
>  kernel 2.2.0 (not SMP supported)
>  arla   0.21  (libgetcwd.so.0.21 pre-load)
>  uname -a : Linux xxxxxx.riken.go.jp 2.2.0 #1 Wed Jan 27 10:36:09 JST 
>             1999 i686 unknown
>
>  csh> pgf77 sim.f				(pgi f77 ok)
>       Linking:
>
>  csh> f77 sim.f                                (Absoft f77 ok)
>  FORTRAN 77 Compiler 4.4, Copyright (c) 1987-1997, Absoft Corp.
>  csh>
>
>  csh> g77 sim.f				(gnu f77 ok)
>  csh>
>
>  There seems to be of no problem of "Kernel 2.2 + arla 0.21(getcwd.so 
>pre-loaded)"  on this environment (single CPU kernel and RH5.2-base)
>for pgf77, f77 and g777.  Kernel 2.2.0 +arla 0.20 also works well 
>without problem.
>
>----------------
>
>The prime differences between these two environments are
>
>    o  SMP support kernel (2.2.0) (1) or no SMP kernel (2.2.0) (1)
>    o  RH 5.1 based (1) or RH 5.2 based (2)
>
>Thank you for any suggestions.
>
>Best Regards
>
>   Takashi Ichihara
>   Radiation lab/Accelerator Research Facility
>   The Institute of Physical and Chemical Research (RIKEN)
>   2-1, Hirosawa, Wako, 351-0106, Japan
>      (Internet)       Ichihara at rarfaxp.riken.go.jp
>
>
>
>
>
>