Mail Archives: cygwin/2001/09/20/11:32:00
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/
- Raw text -