From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Tsekov To: Christopher Currie Cc: cygwin@cygwin.com Subject: Re: Binutils and GCC [LONGER and definitely OT] Date: Thu, 20 Sep 2001 08:30:00 -0000 Message-id: <3BAA0BA7.3E62FD60@syntrex.com> References: <20010918114701.D510@redhat.com> <20010920013727.A5780@mamet.westofhouse.net> <3BA9A18B.DADA5A1A@syntrex.com> <20010920103848.B23076@mutation.ins.com> X-SW-Source: 2001-09/msg01222.html 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/