public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Pavel Tsekov <ptsekov@syntrex.com>
To: Christopher Currie <christopher@currie.com>, cygwin@cygwin.com
Subject: Re: Binutils and GCC [LONG and mildly OT]
Date: Thu, 20 Sep 2001 00:58:00 -0000	[thread overview]
Message-ID: <3BA9A18B.DADA5A1A@syntrex.com> (raw)
In-Reply-To: <20010920013727.A5780@mamet.westofhouse.net>

Hey there :)

Christopher Currie wrote:
> 
> 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.
> 
 
> 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; }

Since you say you're not satisfied with the quality of your fix but you
dont have enough time, let me suggest something the
still uses the above test program.

To fix the problem we can do the following:

int *p;
int main() {
#ifdef __CYGWIN__
extern __attribute__(( dllimport )) const char * const sys_errlist;
#else
extern int sys_errlist;
#endif /* __CYGWIN__ */
p = &sys_errlist;
retrurn 0;
}

This way we will get the compiler to produce the properly mangled name
of sys_errlist variable.

Btw I dont know why the configure script (as you pasted it) expects to
find sys_errlist as int - its "const char * const" in cygwin
as you pointed out and on linux i see it's "__const char * __const
sys_errlist[];". sys_nerr is int :)

However you see my point regardin of types etc this will fix the problem
with the name mangling.

> 
> 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/

  reply	other threads:[~2001-09-20  0:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-18  0:05 Binutils and GCC Doug Johnson
2001-09-18  8:46 ` Christopher Faylor
2001-09-19 22:37   ` Binutils and GCC [LONG and mildly OT] Christopher Currie
2001-09-20  0:58     ` Pavel Tsekov [this message]
     [not found]       ` <20010920103848.B23076@mutation.ins.com>
2001-09-20  8:30         ` Binutils and GCC [LONGER and definitely OT] Pavel Tsekov
2001-09-20  8:24     ` Binutils and GCC [LONG and mildly OT] Christopher Faylor
2001-09-20  8:40       ` WTF?! Pavel Tsekov
2001-09-20  9:06         ` WTF?! Christopher Faylor
2001-09-20  9:28           ` WTF?! Pavel Tsekov
2001-09-20  9:39             ` WTF?! Larry Hall (RFK Partners, Inc)
2001-09-20  9:50               ` WTF?! Pavel Tsekov
2001-09-20  9:58                 ` WTF?! Larry Hall (RFK Partners, Inc)
2001-09-20 10:30                   ` WTF?! Robert Praetorius
2001-09-20 10:47                     ` WTF?! Christopher Faylor
2001-09-20 11:17                       ` WTF?! Larry Hall (RFK Partners, Inc)
2001-09-20  9:50             ` WTF?! Christopher Faylor
2001-09-20 12:30       ` Binutils and GCC Christopher Currie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BA9A18B.DADA5A1A@syntrex.com \
    --to=ptsekov@syntrex.com \
    --cc=christopher@currie.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).