Imap-send recently learned to conditionally compile against and use curl for imap support. To use this feature, you must both: 1. Compile with USE_CURL_FOR_IMAP_SEND 2. Specify --curl on the command line to enable it It is OK (and even desirable) for the code checking --curl to be compiled even if USE_CURL_FOR_IMAP_SEND is not in effect; this lets us explain the situation to the user (instead of saying "--curl? never heard of it"). However, the code which conditionally runs when --curl is enabled must _not_ be compiled in this case. It references functions which are neither declared nor defined, causing the compiler to complain. Signed-off-by: Jeff King <peff@xxxxxxxx> --- On top of br/imap-send-via-libcurl. I needed this to compile 'pu' with NO_CURL (which I don't usually do, but was testing on a minimal box). I expect it can just be squashed in to the next re-roll. Since we were talking about testing in another thread, Junio, I wonder if it is worth having you compile your integration results against a couple different configs (e.g., NO_CURL). Obviously that will make things slower if you don't throw more CPU power at it, but that seems like a problem that can be solved with build servers or similar. imap-send.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/imap-send.c b/imap-send.c index ad4ac22..e0e1f09 100644 --- a/imap-send.c +++ b/imap-send.c @@ -1542,8 +1542,10 @@ int main(int argc, char **argv) if (server.tunnel) return append_msgs_to_imap(&server, &all_msgs, total); +#ifdef USE_CURL_FOR_IMAP_SEND if (use_curl) return curl_append_msgs_to_imap(&server, &all_msgs, total); +#endif return append_msgs_to_imap(&server, &all_msgs, total); } -- 2.1.2.596.g7379948 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html