1.5.0 - showstopper?

Charles Wilson cygwin@cwilson.fastmail.fm
Sun Jul 6 22:55:00 GMT 2003


Charles Wilson wrote:

 > With zlib, I'm getting this "extra" symbol re-exported:
 >
 >         [  20] fopen
 >
 > Note that cygwin1.dll (1.5.0) contains
 >         [ 200] _fopen
 >         [ 201] _fopen64
 >         [ 812] fopen


Also, here are the symbols *imported* from cygwin1.dll by this new cygz.dll:

         1316c       8  __errno
         13178     201  _fopen64
         13184     618  abort
         1318c     664  calloc
         13198     715  cygwin_detach_dll
         131ac     717  cygwin_internal
         131c0     736  dll_dllcrt0
         131d0     780  fclose
         131dc     789  fdopen
         131e8     792  fflush
         131f4     815  fprintf
         13200     816  fputc
         13208     818  fread
         13210     819  free
         13218     825  fseek
         13220     831  ftell
         13228     836  fwrite
         13234    1008  malloc
         13240    1025  memcpy
         1324c    1028  memset
         13258    1115  pthread_mutex_lock
         13270    1118  pthread_mutex_unlock
         13288    1168  realloc
         13294    1185  rewind
         132a0    1301  sprintf
         132ac    1312  strcat
         132b8    1316  strcpy
         132c4    1324  strlen
         132d0    1347  strtoul
         132dc    1422  vsprintf

Note that the only "problem child" is _fopen64 / fopen.  fdopen has 
doesn't get re-exported, etc.  Now, I know that ftell* functions had 
some 64bit magic -- but that only applied to 'ftello' not 'ftell'.

 > I also tried to build popt, but ran into the same problem -- with 
certain other symbols:
 >
 >         [   1] geteuid
 >         [   2] getuid
 >         [   3] lseek
 >         [   4] open


And the symbols imported from cygwin1.dll by this new cygpopt0.dll are

         c1f8        8  __errno
         c204       27  __getreent
         c214      115  _ctype_
         c220      249  _geteuid32
         c230      280  _getuid32
         c23c      354  _lseek64
         c248      389  _open64
         c254      618  abort
         c25c      621  access
         c268      664  calloc
         c274      680  close
         c27c      715  cygwin_detach_dll
         c290      717  cygwin_internal
         c2a4      736  dll_dllcrt0
         c2b4      766  execvp
         c2c0      767  exit
         c2c8      796  fgets
         c2d0      815  fprintf
         c2dc      816  fputc
         c2e4      819  free
         c2ec      836  fwrite
         c2f8      852  getenv
         c304     1008  malloc
         c310     1028  memset
         c31c     1115  pthread_mutex_lock
         c334     1118  pthread_mutex_unlock
         c34c     1164  read
         c354     1168  realloc
         c360     1301  sprintf
         c36c     1312  strcat
         c378     1313  strchr
         c384     1314  strcmp
         c390     1316  strcpy
         c39c     1318  strdup
         c3a8     1319  strerror
         c3b4     1324  strlen
         c3c0     1328  strncmp
         c3cc     1329  strncpy
         c3d8     1334  strrchr
         c3e4     1339  strtod
         c3f0     1344  strtol
         c3fc     1347  strtoul

Again, the only "problems" are _geteuid32 / geteuid, _getuid32 / getuid, 
_lseek64 / lseek, and _open64 / open.

Is it possible that all functions currently in 
winsup/cygwin/Makefile.in's OBSOLETE_FUNCTIONS list will run afoul of 
this issue, even if (or maybe especially if) they have new aliases 
defined in NEW_FUNCTIONS ?

I'm a little confused by cygwin's symbol aliasing/replacement strategy 
and how it interacts with the contents of cygwin1.dll and libcygwin.a. 
But at least I mostly understand the autoimport stuff. <g>

--
Chuck




More information about the Cygwin-developers mailing list