Mail Archives: cygwin-developers/1999/02/01/07:54:46
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 -