Mohan (this-is-cool) 's snapshot gcc33-20030409

erik poupaert erik.poupaert@chello.be
Mon May 12 10:50:00 GMT 2003


On Mon, 2003-05-12 at 12:15, Ranjit Mathew wrote:
> > The compilation works fine up to the point where it starts processing
> > lib/gcc-lib/mingw32/3.3/include/limits.h. Then it says: syslimits.h "No
> > such file or directory". And indeed,limits.h does try to include -- in
> > the middle of undecypherable ifdefs -- a file "syslimits.h" which is not
> > present in the directory where limits.h is located itself.
> 
> In the folder, %GCC%\lib\gcc-lib\mingw32\3.3\include, just create
> a file "syslimits.h" that contains:
> ---------------------------- 8< ---------------------------------
> /* syslimits.h stands for the system's own limits.h file.
>    If we can use it ok unmodified, then we install this text.
>    If fixincludes fixes it, then the fixed version is installed
>    instead of this text.  */
> 
> #define _GCC_NEXT_LIMITS_H  /* tell gcc's limits.h to recurse */
> #include_next <limits.h>
> #undef _GCC_NEXT_LIMITS_H
> ---------------------------- 8< ---------------------------------

Thanks for the tip, but I think I'll abstain from trying to fix zip so
that it works with bash on mingw32. It would be interesting, but I've
got so many other things to do; and replacing zip with fastjar would
probably be the way to go anyway.

> That *should* solve the problem you are facing, though the real
> issue is *why* it should come in the first place.

I don't know why. The people at mingw32 are the ones concerned, I guess.
I'd submit the question to them, if it weren't for all the hoops you
have to jump through, before they consider a bug report:

* it must be submitted through some kind of annoying tool with lots of
forms and fields to enter
* it must have a testscript, and be easily reproducable
* and so on

Instead of accepting the problem, they then create a series a new ones
for me. It's a bit like government services. Instead of giving you the
document you need, they'll send you over to a few other offices first.
It simply becomes a project in itself.

There should be a function of "Bug Evaluator/Acceptor": a person who
accepts unedited and incomplete emails, who asks relevant questions, and
then transparently submits the issue to the internal backoffice systems.
Requesting occasional bug submitters to jump through all the hoops of
the internal backoffice systems, simply prevents bug submitting. I don't
want to get acquainted with all the different bug submitting procedures
of all the projects that I use. I'd be involved in hundreds of
procedures.

And probably I'd have to subscribe to their mailing list as well. But I
don't want to know all the details of what internal stuff is going on,
in their project. I wouldn't be able to read it all. There should be a
mailing list without subscription, for people who occasionally need to
ask a question. And the Bug/Request Evaluators/Acceptors could filter
and push all of this through to the back office people.

That's it. There is a need for a Front Office/Back Office separation in
open source projects.



More information about the Java mailing list