Fwd: Re: setting LD_LIBRARY_PATH when cross-compiling

From cf59a674fb60ea702980b154e1f98e3c8a59adb1 Mon Sep 17 00:00:00 2001
From: Rob Ward <rob <at> rob-ward.co.uk>
Date: Thu, 9 Feb 2012 17:42:29 +0000
Subject: [PATCH 2/2] Adds Cross Compiling flag to output from configure

Adds Cross Compiling : ${cross_compiling} to the list that is output from configure
---
 configure.ac |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index 7f74dca..7225e0d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3310,6 +3310,7 @@ AC_MSG_NOTICE([Configured to build curl/libcurl:
   Host setup:      ${host}
   Install prefix:  ${prefix}
   Compiler:        ${CC}
+  Cross Compiling: ${cross_compiling}
   SSL support:     ${curl_ssl_msg}
   SSH support:     ${curl_ssh_msg}
   zlib support:    ${curl_zlib_msg}
--

-- 
1.7.1

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Using Default Proxy Credentials on Windows

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Question about using curl_easy_setopt CURL_INFILESIZE_LARGE

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

How to send http post without receiving data

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

setting LD_LIBRARY_PATH when cross-compiling

Hi friends,

I found this patch of curl's configure.ac in the Yocto project:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-support/curl/c
url/noldlibpath.patch

While being quite hard-coded, it does have a point in that we should not touch 
LD_LIBRARY_PATH when cross-compiling. Any taker on fixing it properly?

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

POP3 returns line data and CRLF separately, drops final CRLF

As noted in a previous e-mail (Jan 31, "State of POP3 in curl?"), I'm
working on a prototype POP3 download program utilizing libcurl.  I've got
my part of that prototype pretty much completed, but have noticed a couple
of anomalies:

1.  Libcurl is returning message data line-by-line, with two callbacks per
line - one for the line data and the other for the CRLF.  This seems like
strange behavior.  I'd coded as if I were getting the data off a TCP
connection - might get one byte, might get the whole message in one shot,
might get anything between.  So I'm curious as to what the intent is here.
If it's going to return line at a time, it would be nice to get the line
with the CRLF in one callback.  If, as a function of the dot de-stuffing,
libcurl returns whole chunks of message data on CRLF boundaries, that
would be fine too.  I can deal with full, unaligned chunks of data too.
For the moment, I'm not going to consider any sort of alignment
entitlement.

2. Libcurl is dropping the final CRLF from the data.  Although it can be
coped with, this seems wrong.  E-mail messages are always CRLF terminated
lines.  Not getting the final CRLF leaves a hanging, incomplete, line.  I
think this might be a mis-interpretation of RFC 1939, section 3 - Basic
Operation:

   Responses to certain commands are multi-line.  In these cases, which
   are clearly indicated below, after sending the first line of the
   response and a CRLF, any additional lines are sent, each terminated
   by a CRLF pair.  When all lines of the response have been sent, a
   final line is sent, consisting of a termination octet (decimal code
   046, ".") and a CRLF pair.  If any line of the multi-line response
   begins with the termination octet, the line is "byte-stuffed" by
   pre-pending the termination octet to that line of the response.
   Hence a multi-line response is terminated with the five octets
   "CRLF.CRLF".  When examining a multi-line response, the client checks
   to see if the line begins with the termination octet.  If so and if
   octets other than CRLF follow, the first octet of the line (the
   termination octet) is stripped away.  If so and if CRLF immediately
   follows the termination character, then the response from the POP
   server is ended and the line containing ".CRLF" is not considered
   part of the multi-line response.

I think the libcurl implementation has keyed off the "CRLF.CRLF" sentence
in the middle of this paragraph, whereas the final sentence clearly states
that the final ".CRLF" is not part of the data.  By implication, the
immediately preceding CRLF of the last line is part of the data.  Or, it's
just a bug! ;P

Using this write callback routine for a LIST command,

 size_t pop_list_data(char *ptr, size_t size, size_t nmemb, void
*userdata)
 {
    int bytes = (int)(size * nmemb);
    int *num_msgs = userdata;
    int n;

    printf("list >%.*s<\n", bytes, ptr);
    if (*ptr >= '0' && *ptr <= '9')
       if ((n = atoi(ptr)) > 0)
          *num_msgs = n;
    return bytes;
 }

with two messages in the mailbox, I get:

> LIST
< +OK 2 messages (31754 octets)
list >1 16050<
list >
<
list >2 15704<
* Connection #0 to host XXXXXX left intact

which shows both issues 1 & 2.   (Yes, I did shamelessly take advantage of
the line-by-line data return for the prototype. ;)  This will be redone in
a final version anyway, using STAT or UIDL.)

Cheers!
Rich
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Protocol https not supported or disabled in libcurl for .aspx site

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

How to identify graceful disconnection by remote peer while using multi-interface

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Memory consumption during large uploads..

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

IPV6 handing regression bisected to commit 9109cdec11ee5a19f132fd7bdf2e9ceefea4de41

Hi:

In the latest curl release there is a regression

9109cdec11ee5a19f132fd7bdf2e9ceefea4de41 is the first bad commit
commit 9109cdec11ee5a19f132fd7bdf2e9ceefea4de41
Author: Daniel Stenberg <daniel <at> haxx.se>
Date:   Mon Dec 5 10:58:38 2011 +0100

     Curl_socket: internal replacement for socket()

     Moved out into a separate function to work as a "generic" socket()
     replacement.

:040000 040000 e0da372e84bb0ef7b31fd40ba0193bf5e5ca686e
0c3f9b07f90ece45b95a32e1ad0800b89ef5077d M      lib

Test:

curl 
http://download.opensuse.org/repositories/openSUSE:/Factory:/Contrib/standard/repodata/repomd.xml

boot your system with ipv6.disable=1

curl built with --enable-cares
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Makefile.vc: why .vc?

Hi,

Why does this file have a .vc extension?
Dropping the extension would allow nmake to be invoked without /f
Makefile.vc argument.

--

-- 
Olaf
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html