Subject: Re: Binutils and GCC [LONGER and definitely OT]
From: Pavel Tsekov <[email-masked]>
To: Christopher Currie <[email-masked]>
Cc: [email-masked]
Date: Thu, 20 Sep 2001 17:30:47 +0200

Christopher Currie wrote:
> 
> On Thu, Sep 20, 2001 at 09:58:03AM +0200, Pavel Tsekov wrote:
> > 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.
> 
> Two problems with this solution, one practical and one philosophical.
> The practical problem is that this test is not a single standalone test
> that we can change, but a generic test that is fed a list of variables
> to check for. The autoconf for this is shown below.
> 
> Line 124:
> vars="sys_errlist sys_nerr sys_siglist"
> 
> Line 306:
> for v in $vars; do
>   AC_MSG_CHECKING([for $v])
>   AC_CACHE_VAL(libiberty_cv_var_$v,
>     [AC_TRY_LINK([int *p;], [extern int $v; p = &$v;],
>                  [eval "libiberty_cv_var_$v=yes"],
>                  [eval "libiberty_cv_var_$v=no"])])
>   # ... more omitted ...
> done
> 
> Even if you don't know autoconf, I think you can see that this 'for'
> loop is pretty generic, and changing it for sys_errlist might break
> the test for other variables, both present and future.

You guess is right - i dont know autoconf well. After posting this mail
i went to the cvs web interface to gcc and tried to find the code
you pasted in your previous mail but I didnt find anything neither in 
configure nor in configure.in. So I understand something is going wrong
- 
now I know the missing pieces.

So I see you're right that the fix I proposed isnt fitting well. However
I
like more the philosophical statement. As about the practical - as I
look 
at this statement `vars="sys_errlist sys_nerr sys_siglist"` this
variables
seem to have something in common to me :) So i dont expect here to be
added
any variables which do not have at least some of the characteristics of
the
already present ones.

> 
> The philosophical problem is related to my original fix, in that both
> of our solutions depend on knowledge of the internals of a particular
> operating system or, in this case, execution environment. This is the
> classic definition of "begging the question," meaning that we know we're
> compiling on Cygwin, therefore let's write a test that proves that
> Cygwin supports sys_errlist. But since we know that already, why test
> for it? This is the attitude that my solution (based on a similar
> code segment for mingw) takes.
> 
> However, this is all contrary to the intent of autoconf, which is to
> try and test for features of the compiler, not the operating system.
> Sometimes you can't avoid it, of course, but it's worth the effort to
> find a better way.

Hehe, yes :) That's why I thought about fixin the testcase - it would
possible
fit well with respect to the purpose of autoconf :)

> 
> > 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 :)
> 
> This has to do with the nature of C. A C compiler can't do type checking
> on extern variables. It has to believe what you tell it. So if you
> tell it that sys_errlist is an int, and don't include the appropriate
> system header file, it has no choice but to believe you. When the linker
> comes and binds in the standard library, it neither knows nor cares about
> the size and type of a variable, because it's not important to the job
> of updating the address of the variable, which is what the linker does.
> 
> This fact is made useful by the configure script to create a generic
> test for library variables. The script could declare the variable
> const char * const, and it wouldn't care, although it would have to
> declare p as "const char * const *",  which is needlessly confusing.

I asked the question cause I didnt knew there is this autconf
"AC_TRY_LINK"
loop :) I look silly now :)) hehe

> 
> The reason the test is broken in cygwin is because cygwin now defines
> sys_errlist in cygwin.dll instead of libc.a, which changes the linkage.
> A better test wouldn't rely on the way the C linker works. Whether
> such a test is possible is left as an exercise for the reader. ;-)

I think the linker still links against libc.a but this one acts as
import library
for cygwin.dll. So there is nothing wrong with it. The more important
difference is
that sys_errlist and frieds are __attribute__(( dllexport )).

> 
> Sorry for a much longer answer than you probably wanted.
> 

I dont mind :) Thank you that you sched some light :)

> Christopher

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