delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1999/02/01/16:04:48

Delivered-To: listarch-cygwin-developers AT sourceware DOT cygnus DOT com
From: Christopher Faylor <cgf AT cygnus DOT com>
Message-ID: <19990201103846.A26507@cygnus.com>
Date: Mon, 1 Feb 1999 10:38:46 -0500
To: jeffdb AT goodnet DOT com, cygwin32-developers AT cygnus DOT com
Subject: Re: tiny patch for execvp [Re: Problems with winsup-981223]
References: <19981227212632 DOT A24196 AT cygnus DOT com> <199901300438 DOT UAA19176 AT cygnus DOT com> <19990130010435 DOT O10431 AT cygnus DOT com> <199901302309 DOT SAA00319 AT envy DOT delorie DOT com> <19990131001707 DOT A19124 AT cygnus DOT com> <36b4f822 DOT 165663739 AT mail DOT goodnet DOT com>
Mime-Version: 1.0
X-Mailer: Mutt 0.93i
In-Reply-To: <36b4f822.165663739@mail.goodnet.com>; from Mikey on Sun, Jan 31, 1999 at 06:29:17AM +0000
Sender: owner-cygwin32-developers AT cygnus DOT com

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019