Re: 1.5.0 - showstopper?

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

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