RE: libcurl on QNX 6
Date: Tue, 8 Jan 2002 15:54:28 -0000
I checked out the new QNX entry in docs/INSTALL on your WWW and wondered if
it could be worded better as that wasn't what I actually did in the end, as
there are various socket() calls in libcurl which could all potentially
I would suggest the following words:
"As QNX is targetted for resource constrained environments, the QNX headers
set conservative limits. This includes the FD_SETSIZE macro, set by default
to 32. Socket descriptors returned within the CURL library may exceed this,
resulting in memory faults/SIGSEGV crashes when passed into select(..) calls
using fd_set macros.
A good all-round solution to this is to override the default when building
libcurl, by overriding CFLAGS during configure, example
# configure CFLAGS='-DFD_SETSIZE=64 -g -O2'"
Hope it makes sense...
> -----Original Message-----
> From: Daniel Stenberg [SMTP:daniel_at_haxx.se]
> Sent: Monday 07 January 2002 03:19 PM
> To: Bentham, David (Poole)
> Cc: libcurl Mailing list
> Subject: RE: libcurl on QNX 6
> On Thu, 3 Jan 2002 David.Bentham_at_poole.siemens.co.uk wrote:
> > Fortunately in the QNX headers its defined as
> > #ifndef FD_SETSIZE
> > #define FD_SETSIZE 32
> > #endif
> > so its relatively easy to override without changing the original
> > definition. QNX claim posix compliance so this definition style could be
> > standard in other o/s's. Eg Microsoft Visual C++ 6 defines it similarly,
> > but its set to 64.
> The standard Linux headers seems to set the same define to 1024!
> > My initial thoughts are to put some simple test in the Makefile?
> > a 'configure' option to pass in a user- (or best-guess) override
> > in the GCC options.
> That might be a good idea. The annoying part will probably be that the
> won't be available in any known header, so we'll have to search a wide
> of headers. And when we find out, we can't be sure we just change it like
> that, without affecting other things.
> Or can we?
> Anyway, I added your previous notes to the docs/INSTALL document in a
> section, so that it won't be forgotten in the future.
> > On the other hand, it seems bizzarre that the o/s function call to
> > socket(..) returns a socket descriptor outside its own arbitrary
> > perhaps I'll inform QNX about this.
> I find it odd too.
> Thanks anyway for your digging and informations!
> Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
This communication contains information which is confidential, and is for
the exclusive use of the addressee(s). If you are not a named addressee
please contact the sender immediately, and also delete the communication
from your system.
Any views or opinions presented are solely those of the author and do not
necessarily represent those of Siemens plc unless otherwise specifically
Received on 2002-01-08