RE: Binutils and GCC

RE: Binutils and GCC

[Doug Johnson]

I am having a similar experience.  I built a cross compiling gcc for 
W98->MIPS last week using 1.3.2.  Today I rebuilt my system from bare metal 
to run W2K.  Everything else is fine, but I cannot compile binutils using 
1.3.3.  I get the same error that David is getting.

I have tried to revert to 1.3.2, but that doesn't work because for some 
reason setup now believes that the cygwin package should be 
cygwin-1.3.2-1.tar.bz2 (rather than cygwin-1.3.2-1.tar.gz, which is what I 
have from my previous install).

So I'm kind of toast for the moment.  Any guidance would be helpful.

Thanks.

Doug Johnson

Jason Kajita  wrote:

>David T. Schneider" <dschneider at socsolutions dot com> wrote:
>... When I try to build the tools to compile ARM code on CygWin
>following the direction supplied for building ecos I get:
>/usr/src/binutils-2.10.1/libiberty/strerror.c:461: conflicting types for
>`sys_errlist'
>/usr/include/sys/errno.h:23: previous declaration of `sys_errlist'
>when the make reaches /usr/src/binutils-2.10.1/libiberty/strerror.c
>
>I've also tried performing a native build for gcc-2.95.3 and gcc-3.0.1
>and get the same error.  ...
>
>========================================================================
>Further information on the issue:
>I have believe that this problem may be related to the 1.3.3 cygwin1.dll
>release.  When I revert back to 1.3.2-1, I do not get the error.


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

Re: Binutils and GCC

[Christopher Faylor]

On Mon, Sep 17, 2001 at 11:47:20PM -0700, Doug Johnson wrote:
>I am having a similar experience.  I built a cross compiling gcc for
>W98->MIPS last week using 1.3.2.  Today I rebuilt my system from bare
>metal to run W2K.  Everything else is fine, but I cannot compile
>binutils using 1.3.3.  I get the same error that David is getting.
>
>I have tried to revert to 1.3.2, but that doesn't work because for some
>reason setup now believes that the cygwin package should be
>cygwin-1.3.2-1.tar.bz2 (rather than cygwin-1.3.2-1.tar.gz, which is
>what I have from my previous install).
>
>So I'm kind of toast for the moment.  Any guidance would be helpful.

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.

cgf


>Thanks.
>
>Doug Johnson
>
>Jason Kajita  wrote:
>
>>David T. Schneider" <dschneider at socsolutions dot com> wrote:
>>... When I try to build the tools to compile ARM code on CygWin
>>following the direction supplied for building ecos I get:
>>/usr/src/binutils-2.10.1/libiberty/strerror.c:461: conflicting types for
>>`sys_errlist'
>>/usr/include/sys/errno.h:23: previous declaration of `sys_errlist'
>>when the make reaches /usr/src/binutils-2.10.1/libiberty/strerror.c
>>
>>I've also tried performing a native build for gcc-2.95.3 and gcc-3.0.1
>>and get the same error.  ...
>>
>>========================================================================
>>Further information on the issue:
>>I have believe that this problem may be related to the 1.3.3 cygwin1.dll
>>release.  When I revert back to 1.3.2-1, I do not get the error.
>
>
>--
>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/

-- 
cgf@cygnus.com                        Red Hat, Inc.
http://sources.redhat.com/            http://www.redhat.com/

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

Re: Binutils and GCC [LONG and mildly OT]

[Christopher Currie]

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/

Re: Binutils and GCC [LONG and mildly OT]

[Pavel Tsekov]

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/

Re: Binutils and GCC [LONGER and definitely OT]

[Pavel Tsekov]

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/

Re: Binutils and GCC [LONG and mildly OT]

[Christopher Faylor]

On Thu, Sep 20, 2001 at 01:37:27AM -0400, Christopher Currie wrote:
>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.

If you are going to take it upon yourself to take a cygwin problem into
other mailing lists, you really should check out the CVS sources to see
if this has actually been solved or not.

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

Some points:

1) No one is paid to support this code.

2) No one has volunteered to support other people's efforts to compile the
   code.

3) No one was asking for a definitive fix.  I was basically commenting on
   how strange it was that people who are supposed to be programmers were
   stalled for days over a problem that could have been solved by an #ifdef.
   The problem has been fixed definitively in sources.redhat.com CVS sources
   for weeks.  However, that fix won't magically propagate to older source
   tar balls.  So, a brain-dead simple fix to strerror.c is required.

   Either that or you can use the solution THAT I ALREADY SUGGESTED.

4) If someone is building the code on their own rather than using the binaries
   that *I did* volunteer to provide then it is either part of their job or
   they have some other reason for doing it.  It's not part of my job in
   any way to track down their problems for them.  I could build the programs
   just fine when I released them.  If that changes over time, I'm not going
   to make a new release just to satisfy people who want to build things on
   their own.  If someone needs to do that then they really should know what
   they are doing.  Either that or they should pay someone to support them.
   Or, they could try to use the *latest* versions of the sources where any
   problems would be solved.

5) Even if we were to buy into your theory that I have either volunteered
   to help you build the tools or your even more inane theory that I am
   actually being *paid* to help people for free; merely reporting a problem
   with no more analysis than a cut and paste of an error message is hardly
   a way to help me out.  Even if it was a vague help, the majority of this
   thread was comprised of "I am stalled too! I need a fix!" messages which
   conveyed no useful information.

I haven't looked at your patch.  You seem competent so I assume that it
solves your problem.

I also assume that a patch won't help most of the original posters who
were complaining in the cygwin mailing list since it will require them
to learn about both patch and autoconf.  However, maybe there are some
other previously silent but competent people like you who were also
silently fuming over the injustice of not being able to compile their
own version of the tools and maybe they will be able to use the solution
that you provided.

Or, you could always just remove strerror from the Makefile like I
originally suggested...

cgf

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

WTF?!

[Pavel Tsekov]

Christopher Faylor wrote:
> 
> On Thu, Sep 20, 2001 at 01:37:27AM -0400, Christopher Currie wrote:
> >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.
> 
> If you are going to take it upon yourself to take a cygwin problem into
> other mailing lists, you really should check out the CVS sources to see
> if this has actually been solved or not.
> 
> >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>
> 
> Some points:
> 
> 1) No one is paid to support this code.
> 
> 2) No one has volunteered to support other people's efforts to compile the
>    code.
> 
> 3) No one was asking for a definitive fix.  I was basically commenting on
>    how strange it was that people who are supposed to be programmers were
>    stalled for days over a problem that could have been solved by an #ifdef.
>    The problem has been fixed definitively in sources.redhat.com CVS sources
>    for weeks.  However, that fix won't magically propagate to older source
>    tar balls.  So, a brain-dead simple fix to strerror.c is required.
> 
>    Either that or you can use the solution THAT I ALREADY SUGGESTED.
> 
> 4) If someone is building the code on their own rather than using the binaries
>    that *I did* volunteer to provide then it is either part of their job or
>    they have some other reason for doing it.  It's not part of my job in
>    any way to track down their problems for them.  I could build the programs
>    just fine when I released them.  If that changes over time, I'm not going
>    to make a new release just to satisfy people who want to build things on
>    their own.  If someone needs to do that then they really should know what
>    they are doing.  Either that or they should pay someone to support them.
>    Or, they could try to use the *latest* versions of the sources where any
>    problems would be solved.
> 
> 5) Even if we were to buy into your theory that I have either volunteered
>    to help you build the tools or your even more inane theory that I am
>    actually being *paid* to help people for free; merely reporting a problem
>    with no more analysis than a cut and paste of an error message is hardly
>    a way to help me out.  Even if it was a vague help, the majority of this
>    thread was comprised of "I am stalled too! I need a fix!" messages which
>    conveyed no useful information.
> 
> I haven't looked at your patch.  You seem competent so I assume that it
> solves your problem.
> 
> I also assume that a patch won't help most of the original posters who
> were complaining in the cygwin mailing list since it will require them
> to learn about both patch and autoconf.  However, maybe there are some
> other previously silent but competent people like you who were also
> silently fuming over the injustice of not being able to compile their
> own version of the tools and maybe they will be able to use the solution
> that you provided.
> 
> Or, you could always just remove strerror from the Makefile like I
> originally suggested...
> 
> cgf
> 

Cristopher, why dont just you stop reading those posts which actually 
dont tend to be good enough for you ? I think if point 1 applies to
you then you are not being paid to read the mailing lists too - are you
?
So "silly" mails are easily to be recognized - you can just pass them
by.

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

Re: WTF?!

[Christopher Faylor]

On Thu, Sep 20, 2001 at 05:40:25PM +0200, Pavel Tsekov wrote:
>Cristopher, why dont just you stop reading those posts which actually 
>dont tend to be good enough for you ?

Because I am mean.

>I think if point 1 applies to you then you are not being paid to read
>the mailing lists too - are you ?

No.  I'm not.  Would you like me to ignore all of the email I get
relating to keeping this mailing list running, too?  I could just turn
the mailing list off.  That would be a lot easier.

>So "silly" mails are easily to be recognized - you can just pass them
>by.

If the "silly" emails are so easily recognized then why were you
contributing to the discussion?

Why were you discussing making modifications to libiberty which had
already been done in CVS?

Why were you discussing solutions at all when I already suggested that
people either use the CVS version or remove the offending file from the
makefile?

Maybe your "ignore filter" is a little too high and mine is a little too
low.

cgf

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

Re: WTF?!

[Pavel Tsekov]

Christopher Faylor wrote:
> 
> On Thu, Sep 20, 2001 at 05:40:25PM +0200, Pavel Tsekov wrote:
> >Cristopher, why dont just you stop reading those posts which actually
> >dont tend to be good enough for you ?
> 
> Because I am mean.

I know you are :)

> 
> >I think if point 1 applies to you then you are not being paid to read
> >the mailing lists too - are you ?
> 
> No.  I'm not.  Would you like me to ignore all of the email I get
> relating to keeping this mailing list running, too?  I could just turn
> the mailing list off.  That would be a lot easier.

This is not what I mean of course. The line below should explain it.

> 
> >So "silly" mails are easily to be recognized - you can just pass them
> >by.
> 
> If the "silly" emails are so easily recognized then why were you
> contributing to the discussion?
> 
> Why were you discussing making modifications to libiberty which had
> already been done in CVS?

I saw it actually after I posted the first mail from me concerning the
problem. It was late - I'm sorry. I stated that clear in the second one.
However I didnt discuss fixes of liberty but a way to fix the fix for
liberty.
I.e. I felt that this is the right way to do the thing - fixing the
testcase
with respect to autoconf.

> 
> Why were you discussing solutions at all when I already suggested that
> people either use the CVS version or remove the offending file from the
> makefile?

I dont see the solution from you - I really don't. I read the mailing
list from
my local mailbox not from the web - here I have only four (4) messages
from you
an none of them say somethings of actually fixing the problem. The only
post which
gives any useful info says this:

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

I dont blame you or anyone - just there are too much msgs like that one 
above - I dont see way should be messages like that. Or like "go to read
how to ask smart questions" etc. This wont change anything - at least I
think
so.

> 
> Maybe your "ignore filter" is a little too high and mine is a little too
> low.
> 
> cgf

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

Re: WTF?!

[Larry Hall (RFK Partners, Inc)]

At 12:28 PM 9/20/2001, Pavel Tsekov wrote:
>Christopher Faylor wrote:
> > 
> > Why were you discussing solutions at all when I already suggested that
> > people either use the CVS version or remove the offending file from the
> > makefile?
>
>I dont see the solution from you - I really don't. I read the mailing
>list from
>my local mailbox not from the web - here I have only four (4) messages
>from you
>an none of them say somethings of actually fixing the problem. The only
>post which
>gives any useful info says this:
>
>----

<snip>

>If this is too tough for you, try removing the offending file from the
>makefile or building from CVS sources.


Wow, Pavel!  I can't believe you missed this part!  Apparently you misread
this original message from Chris at least twice.  I assume now that I 
pointed out Chris's suggestion in the original posting (which you 
thoughtfully appended to your message! :-) ), you see what you
missed.  If you don't agree with the way he answered you, well, I can't 
help you there.  However, it seems clear to me that he offered very useful 
information initially.  YMMV. 





Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


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

Re: WTF?!

[Pavel Tsekov]

"Larry Hall (RFK Partners, Inc)" wrote:
> 
> At 12:28 PM 9/20/2001, Pavel Tsekov wrote:
> >Christopher Faylor wrote:
> > >
> > > Why were you discussing solutions at all when I already suggested that
> > > people either use the CVS version or remove the offending file from the
> > > makefile?
> >
> >I dont see the solution from you - I really don't. I read the mailing
> >list from
> >my local mailbox not from the web - here I have only four (4) messages
> >from you
> >an none of them say somethings of actually fixing the problem. The only
> >post which
> >gives any useful info says this:
> >
> >----
> 
> <snip>
> 
> >If this is too tough for you, try removing the offending file from the
> >makefile or building from CVS sources.
> 
> Wow, Pavel!  I can't believe you missed this part!  Apparently you misread
> this original message from Chris at least twice.  I assume now that I
> pointed out Chris's suggestion in the original posting (which you
> thoughtfully appended to your message! :-) ), you see what you
> missed.  If you don't agree with the way he answered you, well, I can't
> help you there.  However, it seems clear to me that he offered very useful
> information initially.  YMMV.

Yeah, it seems I missed it. Thanks for enlightening me. Although this is
not the
appropriate way for answering the question as it comes to me.

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

Re: WTF?!

[Larry Hall (RFK Partners, Inc)]

At 12:50 PM 9/20/2001, Pavel Tsekov wrote:
>"Larry Hall (RFK Partners, Inc)" wrote:
> > 
> > At 12:28 PM 9/20/2001, Pavel Tsekov wrote:
> > >Christopher Faylor wrote:
> > > >
> > > > Why were you discussing solutions at all when I already suggested that
> > > > people either use the CVS version or remove the offending file from the
> > > > makefile?
> > >
> > >I dont see the solution from you - I really don't. I read the mailing
> > >list from
> > >my local mailbox not from the web - here I have only four (4) messages
> > >from you
> > >an none of them say somethings of actually fixing the problem. The only
> > >post which
> > >gives any useful info says this:
> > >
> > >----
> > 
> > <snip>
> > 
> > >If this is too tough for you, try removing the offending file from the
> > >makefile or building from CVS sources.
> > 
> > Wow, Pavel!  I can't believe you missed this part!  Apparently you misread
> > this original message from Chris at least twice.  I assume now that I
> > pointed out Chris's suggestion in the original posting (which you
> > thoughtfully appended to your message! :-) ), you see what you
> > missed.  If you don't agree with the way he answered you, well, I can't
> > help you there.  However, it seems clear to me that he offered very useful
> > information initially.  YMMV.
>
>Yeah, it seems I missed it. Thanks for enlightening me. Although this is
>not the
>appropriate way for answering the question as it comes to me.


To each his own.




Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


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

Re: WTF?!

[Robert Praetorius]

perhaps if the main cygwin mailing list were renamed to cygwin-
asbestos-longjohns ( http://www.cnam.fr/Jargon/jargon.html?64 ) 
it would set expectations in a way that would cut down the level 
of shock and surprise (I'm not shocked, but I'm pretty much in 
agreement with http://www.tuxedo.org/~esr/faqs/smart-
questions.html ).

Naahhh.  Nothing would be sufficient.  This is life on the net.  
The unacculturated proportion of the stream never goes down 
because of the continual influx.


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

Re: WTF?!

[Christopher Faylor]

On Fri, Sep 21, 2001 at 03:29:20AM +1000, Robert Praetorius wrote:
>perhaps if the main cygwin mailing list were renamed to cygwin-
>asbestos-longjohns ( http://www.cnam.fr/Jargon/jargon.html?64 ) 
>it would set expectations in a way that would cut down the level 
>of shock and surprise (I'm not shocked, but I'm pretty much in 
>agreement with http://www.tuxedo.org/~esr/faqs/smart-
>questions.html ).
>
>Naahhh.  Nothing would be sufficient.  This is life on the net.  
>The unacculturated proportion of the stream never goes down 
>because of the continual influx.

Wow.  That's a discouraging (if true) observation.

I think the usual observation at this point is "If you really think
that those are flames you don't know what flames are".

I think it may be time for a "death of cygwin unless changes are made"
prediction, too.  Or did we already have that?

cgf

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

Re: WTF?!

[Larry Hall (RFK Partners, Inc)]

At 01:47 PM 9/20/2001, Christopher Faylor wrote:
>On Fri, Sep 21, 2001 at 03:29:20AM +1000, Robert Praetorius wrote:
> >perhaps if the main cygwin mailing list were renamed to cygwin-
> >asbestos-longjohns ( http://www.cnam.fr/Jargon/jargon.html?64 ) 
> >it would set expectations in a way that would cut down the level 
> >of shock and surprise (I'm not shocked, but I'm pretty much in 
> >agreement with http://www.tuxedo.org/~esr/faqs/smart-
> >questions.html ).
> >
> >Naahhh.  Nothing would be sufficient.  This is life on the net.  
> >The unacculturated proportion of the stream never goes down 
> >because of the continual influx.
>
>Wow.  That's a discouraging (if true) observation.
>
>I think the usual observation at this point is "If you really think
>that those are flames you don't know what flames are".
>
>I think it may be time for a "death of cygwin unless changes are made"
>prediction, too.  Or did we already have that?



More or less.  I think we've run through the standard check list of 
complaints and rebuttals.  The cycle is complete.  It's time to leave 
this merry-go-round until another day.  There's nothing more to see here.  
Back to work! ;-)



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


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

Re: WTF?!

[Christopher Faylor]

On Thu, Sep 20, 2001 at 06:28:32PM +0200, Pavel Tsekov wrote:
>Christopher Faylor wrote:
>> >I think if point 1 applies to you then you are not being paid to read
>> >the mailing lists too - are you ?
>> 
>> No.  I'm not.  Would you like me to ignore all of the email I get
>> relating to keeping this mailing list running, too?  I could just turn
>> the mailing list off.  That would be a lot easier.
>
>This is not what I mean of course. The line below should explain it.

No.  I don't think you understand.  I get *a lot* of email from people
off-list who are completely confused about how to use the mailing list.
It would be truly wonderful if I didn't have to deal with that email on
a daily basis.  I'd love to just classify it as silly and forget about
it.

I'm not going to do that, of course because there isn't anyone else
available for dealing with these issues.

Similarly when the third "I can't compile libiberty" message came in, I
assumed that everyone was obviously thinking about the problem
incorrectly and no one was actually going to offer a solution.  So, I
offered an observation and a solution.

cgf

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

Re: Binutils and GCC

[Christopher Currie]

On Thu, Sep 20, 2001 at 11:25:18AM -0400, Christopher Faylor wrote:
> If you are going to take it upon yourself to take a cygwin problem into
> other mailing lists, you really should check out the CVS sources to see
> if this has actually been solved or not.

You're right, my bad. If I'd looked, I'd have seen that they fixed it
in CVS a month ago. Consider me suitably chastised. All of your points
are valid, and I would have realized that had I looked at the CVS tree.

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/