Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Mon, 6 Jan 2003 11:58:36 -0500
From: Christopher Faylor <cgf-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Re: help for compiling problem!
Message-ID: <20030106165836.GE25858@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20030106065320 DOT E6109407C AT sitemail DOT everyone DOT net> <20030106155840 DOT GC25858 AT redhat DOT com> <46935 DOT 213 DOT 38 DOT 17 DOT 50 DOT 1041869937 DOT squirrel AT raq299 DOT uk2net DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46935.213.38.17.50.1041869937.squirrel@raq299.uk2net.com>
User-Agent: Mutt/1.5.1i

On Mon, Jan 06, 2003 at 04:18:57PM -0000, Dave Hooper wrote:
>>>>error:  main.c: undefined reference to '_setlinebuf'
>>>
>> cygwin doesn't provide setlinebuf.
>> In general what this means is that you have to actually "inspect" the
>> code and "port it"
>
>As a follow up to this, and the earlier thread regarding icmp (which
>presumably is resolved in the same way), would it not be "better" to add
>support for the icmp function and setlinebuf to cygwin?

What are you suggesting?  That there should be an eager team of
engineers standing by waiting for requests for unimplemented features?
That sort of pushes all of the responsibility off onto cygwin.  Maybe we
should write an auto-compilation-error detection module which uses
artificial intelligence to detect compilation errors and automatically
correct them, too.

When you port software to new systems, you often have to tweak the
software to accommodate the new system.  If you are porting from linux
to HP/UX and find that there is a feature missing in HP/UX, your first
inclination should not be to send a linker error to HP.  You should
inspect the source code and see if there are porting options that you
can avail yourself of.

Cygwin is different since it is open source and development moves faster
than something like HP/UX, however, the logic of sending linker errors
to a mailing list and waiting days for someone to respond, escapes me.
It seems far better to actually educate yourself on what the missing
function or header file might be doing and, at the very very least,
offering an *educated* idea to the list if you can't find a workaround.

Also, if *you* want functionality, *you* can add it.  I think I can
safely say that no one is sitting around waiting for requests so that
they can implement them for you for free.  For the most part, everyone
works on what interests them.  However, it should be very obvious that
new functionality is added all of the time.  I wouldn't be surprised to
see someone offer setlinebuf now.  That's what new cygwin releases are
for.

>"Better" in the sense that Crystal is better than Moet - and I'm not
>suggesting everyone ought to be able to afford Crystal.  Is there any
>technical reason why support cannot be added to Cygwin for these (and
>other) unprovided functions?

It might even be obvious that since there is a setlinebuf definition in
a header file, then it might already be implemented somewhere (newlib).
However, even if the setlinebuf function was instantly added to cygwin,
that doesn't solve the problem unless you are also expecting instant
release of a new version of cygwin.  That's not going to happen.

In this case, I happen to know that working around the problem is
trivial.  It should be so trivial that a few minutes inspection of a man
page is all that is required.

For icmp functionality, we obviously use whatever Windows provides.
I have no idea if it is possible to implement.  Perhaps someone else
will chime in, although I'm sure this subject has been discussed many
times before.

>Is there a canonical list of what people expect cygwin to support vs.
>what it actually supports, and hence what it currently lacks?

No.  Feel free to provide one.

The model here is freedom.  You have the source code.  You can, within
the limits of the GPL, do what you want with it.  If you are a
conscientious citizen, you can even try to help out the community by
providing actual effort to improve the product via documentation or
source code updates.

cgf
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam AT sources DOT redhat DOT com
and be permanently blocked from mailing lists at sources.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/