This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin project. See the Cygwin home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: tiny patch for execvp [Re: Problems with winsup-981223]



On Sun, Jan 31, 1999 at 06:29:17AM +0000, Mikey wrote:
>On Sun, 31 Jan 1999 00:17:07 -0500, you wrote:
>
>>On Sat, Jan 30, 1999 at 06:09:08PM -0500, DJ Delorie wrote:
>>>> > _ctype_ DATA
>>>>
>>>> We run configure/builds almost every night and haven't run across a
>>>> problem with this.  Have you updated your libcygwin.a?
>>>
>>>You would only see this problem if the native compiler was a
>>>cygwin-hosted compiler.  In other words, on builds *on* NT would see
>>>this.  Unix builds would never see this.
>>
>>I understand where the prpblem was coming from.  I thought that you
>>actually did configure/build on NT fairly regularly.
>
>Actually the only specific problem that this currently causes is that a
>spurious -DNEED_sys_nerr and -DNEED_sys_errlist are generated, (or
>whatever the macros are that trigger building the two I'm not running
>configure right now :), which means that programs that link with
>libiberty will get different static versions of sys_nerr, and
>sys_errlist.
>
>The reason I brought this up is so that the people who do core
>development would be aware of the problems associated with using/not
>using the DATA keyword in .def files.  and the consequences to configure
>scripts.

If we removed the DATA keyword, does that mean that there will be a
sys_errlist symbol in libcygwin.a but it won't refer to the actual
table?  If so, does that mean that this code would do something funky:

char *sys_errlist[];
main()
{
  puts(sys_errlist[1]);
}

If the above code would compile and link but not work as expected then
I'd rather keep the DATA.

>I don't know who is responsible for maintaining the autoconf scripts
>(Ian?) but I would think that probably not breaking configure (on 200+
>targets :) is more important than the occasional breakage from programs
>not including the correct header.  so I would vote to not use the DATA
>keyword in cygwin32.

Ian is on a leave of absence from Cygnus so he's not maintaining libiberty
for Cygnus.  I've added an additional check for sys_errlist and sys_nerr
to the libiberty configure.  There were already similar checks for this
in the script.

Isn't this the preferred solution?  Or will the above code work correctly?

-chris