From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] lftp: new package.
Date: Fri, 22 Nov 2013 10:20:51 +0100 [thread overview]
Message-ID: <528F21F3.9010904@mind.be> (raw)
In-Reply-To: <20131122091552.247012c6@skate>
On 22/11/13 09:15, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Thu, 21 Nov 2013 23:19:10 +0100, Arnout Vandecappelle wrote:
>
>>> Seeing this, I believe that passing i_cv_posix_fallocate_works=yes in
>>> the ./configure environment is a better solution.
>>
>> But that wouldn't detect the uClibc case when posix_fallocate isn't
>> available...
>
> I thought there were two tests, with two different variables:
>
> * One testing if a program with posix_fallocate() can be *compiled*.
> This test we need to let it as it is.
>
> * One testing if a program with posix_fallocate() can *run*. This test
> we need to tell the configure script to just assume that
> posix_fallocate() works (but of course, making the assumption that
> a failure on the previous test will make the configure conclude that
> posix_fallocate is not available).
Well, yes, there are two tests in configure, but only a single macro in
lftp.m4. AC_TRY_RUN compiles the first argument and then tries to run it
(if not cross-compiling). The second argument is executed if the run
succeeds, the third argument if the compilation or the run fails, the
fourth argument if compilation succeeds but it cannot be ran because
you're cross-compiling.
There are a number of other instances of AC_TRY_RUN in the lftp
configure scripts, but the others all have the fourth argument.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
next prev parent reply other threads:[~2013-11-22 9:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 15:16 [Buildroot] LFTP: a sophisticated ftp/sftp/http/fish client with few dependencies Arnaud Rébillout
2013-11-21 15:16 ` [Buildroot] [PATCH] lftp: new package Arnaud Rébillout
2013-11-21 15:42 ` Thomas Petazzoni
2013-11-21 16:17 ` Arnaud Rébillout
2013-11-21 17:12 ` Thomas Petazzoni
2013-11-21 21:54 ` Arnout Vandecappelle
2013-11-21 22:00 ` Thomas Petazzoni
2013-11-21 22:19 ` Arnout Vandecappelle
2013-11-22 8:15 ` Thomas Petazzoni
2013-11-22 9:20 ` Arnout Vandecappelle [this message]
2013-11-25 13:06 ` Arnaud Rébillout
2013-11-25 13:19 ` Arnaud Rébillout
-- strict thread matches above, loose matches on Subject: below --
2013-11-25 12:55 [Buildroot] [PATCH v2] " Arnaud Rébillout
2013-11-25 12:55 ` [Buildroot] [PATCH] " Arnaud Rébillout
2013-11-25 17:59 ` Arnout Vandecappelle
2013-12-02 9:36 ` Arnaud Rébillout
2013-12-02 22:04 ` Arnout Vandecappelle
2013-12-03 7:59 ` Arnaud Rébillout
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528F21F3.9010904@mind.be \
--to=arnout@mind.be \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox