Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Date: Thu, 20 Sep 2001 01:37:27 -0400
To: cygwin AT cygwin DOT com
Cc: gcc-bugs AT gnu DOT org, bug-binutils AT gnu DOT org
Subject: Re: Binutils and GCC [LONG and mildly OT]
Message-ID: <20010920013727.A5780@mamet.westofhouse.net>
Mail-Followup-To: cygwin AT cygwin DOT com, gcc-bugs AT gnu DOT org, bug-binutils AT gnu DOT org
References: <20010918114701 DOT D510 AT redhat DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.20i
From: Christopher Currie <christopher AT currie DOT com>

All,

Sorry for the cross-posting, but this regards a bug in libiberty and I
don't know whether gcc or binutils has ownership of it.

On Tue, Sep 18, 2001 at 11:47:01AM -0400, Christopher Faylor wrote:
> It is just C source code we're talking about, right?  You have an editor?
> Look at the place where the errors are coming from and make an
> educated guess about fixing it.
> 
> What is the worse that can happen?  If you screw up do you think that
> this will cause gcc to subtly miscompile your code so that all of the
> add instructions are turned into sub instructions or something?  That's
> not going to happen.
> 
> You are all programmers right?  Inspect the code.  Invest five minutes
> worth of analysis into the problem.
> 
> If this is too tough for you, try removing the offending file from the
> makefile or building from CVS sources.
> 
> I can't believe that there are three messages on this subject from people
> who are apparently programmers without one suggested fix.

<rant>
Probably because most of them are busy trying use the tools to do the
work they get paid to do, rather than spend the time fixing the tools.
Since backing out to the previous version allows them to do that, they've
done what's expected of them and logged a bug report that (IMHO) helps
a maintainer (who, I would think, either has volunteered or is paid to
do such things) track down what might be causing the problem.
</rant>

That being said, I took a look at it myself because I'd encountered it
earlier and set it aside to look at later. I go into a bit more detail here
than I probably need to, for the sake of those who are interested in
why this is occuring but don't have time to look at it. Those who
simply want the "fix" should scroll to the bottom.

The problem seems to be in libiberty, and a configure script that makes
bad assumptions about the way str_errlist is declared. The configure
script runs the following test:

int *p;
int main() {
extern int sys_errlist; p = &sys_errlist;
; return 0; }

On a standard Unix box, this test would compile if sys_errlist is
defined somewhere in the C standard library. But in the latest version
of the Cygwin dll, sys_errlist is defined (after macro expansion) as:

extern __attribute__(( dllimport )) const char * const sys_errlist;

The importand part is the __attribute__(( dllimport )) which (for non-
windows programmers) changes the way that the name is mangled, so that
when the configure test tries to link, can't match up the sys_errlist
defined in the test to the one in the library, and assumes it doesn't
exist.

This can be illustrated by looking at the output of nm. Assume test.c
contains the first code snippet above:

bash$ gcc -c test.c

bash$ nm test.o
00000000 b .bss
00000000 d .data
00000000 t .text
00000000 t ___gnu_compiled_c
         U ___main
00000000 T _main
00000010 C _p
         U _sys_errlist
00000000 t gcc2_compiled.

Compare that to test2.c which adds __attribute__(( dllimport )) to the
third line.

bash$ gcc -c test2.c

bash$ nm test2.o
00000000 b .bss
00000000 d .data
00000000 t .text
00000000 t ___gnu_compiled_c
         U ___main
00000000 T _main
00000010 C _p
         U __imp__sys_errlist
00000000 t gcc2_compiled.

THE FIX:

Well, since this a configuration issue and not a code issue, I tried editing
libibery/configure.in with the patch below. However, libiberty uses autoconf
macros that don't exist anymore in autoconf 2.51, the current cygwin version,
so I had to download and install autoconf 2.13 in order to test it. This
patch got me past the bug in libiberty, but as of this writing gcc is still
compiling, so I can't attest as to how well it will eventually work. Your
mileage may vary.

So:

1) apply the patch in the libiberty directory of gcc-3.0.1 (I'm hoping
   binutils will work as well)
2) install autoconf 2.13
3) run autoconf 2.13 in the libiberty directory
4) reconfigure and compile gcc

Caveats:

This is a hack of the worst magnitude. It really doesn't fix the test that's
broken in the first place, it simply makes assumptions based upon your
environment. If I've got the time (and that's a big if) I might try and
write a better test or look deeper into the libiberty code that requires it.


*** configure.in.OLD    Thu Sep 20 00:47:00 2001
--- configure.in        Thu Sep 20 00:51:36 2001
***************
*** 250,255 ****
--- 250,261 ----
        vars="`echo $vars | sed -e 's/sys_siglist//'`"
        checkfuncs="`echo $checkfuncs | sed -e 's/strsignal//' -e 's/psignal//'`
"
      fi
+
+     # Under Cygwin, sys_nerr and sys_errlist exist, but they are
+     # dllimports, so the test below won't find them.
+     libiberty_cv_var_sys_nerr=yes
+     libiberty_cv_var_sys_errlist=yes
+
      ;;

    *-*-mingw32*)


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/