Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <3F32B389.3040705@netscape.net>
Date: Thu, 07 Aug 2003 16:16:09 -0400
From: Nicholas Wourms <nwourms AT netscape DOT net>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Cygwin's lstat and adding some new functions to newlib
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I couldn't decide which list would be most appropriate for this, so I 
hope that people don't flame me for sending here.  Also, please bear 
with me, as I don't considier myself an "expert" when it comes to 
working with newlib internals.

I'm working on porting a few missing funtions to Cygwin (specifically 
the fts ones), but in order to do that I needed to add them in newlib 
first.  I added the functions into newlib, and exported them in the 
appropriate headers, and then exported the corresponding symbols in 
cygwin.din.  The problem is that the function I'm porting from bsd makes 
several calls to lstat.  Now I've noticed that using syscalls in newlib 
when building for Cygwin can be tricky, since you won't allow them to be 
defined if the macro __INSIDE_CYGWIN__ is set.  By looking at how it was 
done for other functions using a syscall like fstat or fork, it seems 
one is required to add a stub definition for the reentrant version to 
_syslist.h.  When newlib is compiling, it should then define the 
MISSING_SYSCALL_NAMES macro and pick up the definition inside the guard. 
  So, I added this to _syslist.h:
....
#define _lstat lstat
....

I then copied the header to /usr/include, just in case gcc picked up the 
system includes in the wrong order (gcc gives copious warnings regarding 
this when I compile natively).  So at this point, I thought I had done 
everything necessary to get this in working order.  And, indeed, newlib 
compiles without so much as a warning on the source that I added. 
However, when it come time to actually create the Cygwin dll, the build 
aborts with the following message:

/usr/src/cygwin-src/build/i686-pc-cygwin/newlib/libc/libc.a(fts.o)(.text+0x1195): 
In function `fts_stat':
/usr/src/cygwin-src/build/i686-pc-cygwin/newlib/libc/gen/../../../../../src/newlib/libc/gen/fts.c:1332: 
undefined reference to `_lstat'
/usr/src/cygwin-src/build/i686-pc-cygwin/newlib/libc/libc.a(fts.o)(.text+0x120e):/usr/src/cygwin-src/build/i686-pc-cygwin/newlib/libc/gen/../../../../../src/newlib/libc/gen/fts.c:1339: 
undefined reference to `_lstat'
collect2: ld returned 1 exit status

For reference, I've included a snippet of the source file, showing first 
the headers used and then the location of the first error.

......
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/param.h>

#include <errno.h>
#include <dirent.h>
#include <fts.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <string.h>
#include <unistd.h>
#include <reent.h>
#include <_syslist.h>
......
         if (ISSET(FTS_LOGICAL) || follow) {
                 if (stat(p->fts_accpath, sbp)) {
                         saved_errno = errno;
                         if (!lstat(p->fts_accpath, sbp)) {
                              ^^^^^
                                 errno = 0;
                                 return (FTS_SLNONE);
                         }
......

The wierd thing is that it has no problems with stat or fstat, which 
leads me to conclude that somehow lstat isn't being made public in the 
same fashion as the aforementioned two syscalls.

Am I missing something, perhaps a step I was not aware of?
In general (I know you can't be specific), do my headers appear to be 
correctly ordered?
What is the appropriate way to deal with a function which uses a syscall 
not already declared in _syslist.h?

At this point, I'm out of ideas, but I was hoping someone might have had 
to deal with this in the past and could possibly clue me in.  Thanks in 
advance!

Cheers,
Nicholas


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/