Openembedded Core Discussions
 help / color / mirror / Atom feed
From: ChenQi <Qi.Chen@windriver.com>
To: Saul Wold <sgw@linux.intel.com>
Cc: Zhenfeng.Zhao@windriver.com, openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] autotools.bbclass: use relative path for acpaths whenever possible
Date: Fri, 23 Nov 2012 16:31:50 +0800	[thread overview]
Message-ID: <50AF3476.1000401@windriver.com> (raw)
In-Reply-To: <50AD6F8E.50807@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 5312 bytes --]

On 11/22/2012 08:19 AM, Saul Wold wrote:
> On 11/08/2012 09:47 PM, Qi.Chen@windriver.com wrote:
>> From: Chen Qi <Qi.Chen@windriver.com>
>>
>> When the TMPDIR is very long, say, 410 characters, aclocal would
>> fail because the argument list is too long. This patch is an effort
>> to use relative path for acpaths whenever possible, aiming at
>> making the build system work correctly when the sanity check says OK.
>>
>> With the current implementation of autoreconf, it's impossible to
>> thoroughly replace absolute path with relative path. Therefore, we
>> use relative path when there's on subdirectory to configure; otherwise,
>> we use absolute path.
>>
> Have you done a world build long path names with this patch on 1.4 and 
> does it cause any failures with autoreconf and subdirs?
>
> Sau!
>
Hi Saul,

Thank you for your suggestion.

I did do the test before I sent out the patch, but at that time I only 
used 'bitbake core-image-sato'.
However when I re-tested it yesterday with 'bitbake world', qt4-native 
configure failed.
(Sorry for my carelessness.)

The failure is not caused by the changes in autotools.bbclass.
It failed to configure because *the path is too long to be fitted into 
the static char array defined in its qconfig.cpp file*.

Below are some details:
src/corelib/global/qconfig.cpp:11:67: *error: initializer-string for 
array of chars is too long* [-fpermissive]
The statements in qconfig.cpp that caused this failure are:
static const char qt_configure_prefix_path_str       [*256* + 12] = 
"qt_prfxpath=/buildarea/qchen1/poky/build-autotools-test/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs\
/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/s\
ubs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs0/sysroots/x86_64-linux/usr";
static const char qt_configure_documentation_path_str[*256* + 12] = 
"qt_docspath=/buildarea/qchen1/poky/build-autotools-test/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs\
/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/s\
ubs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs/subs0/sysroots/x86_64-linux/usr/doc";
...


Anyway it should be fixed as part of bug#2766 (long TMPDIR problem).
Thus, I'll rework on bug#2766 and try to fix it.

However, statements in qconfig.cpp lead me to doubt about the length 
limit of TMPDIR (currently 410).
As we see in qconfig.cpp, */if the TMPDIR has chars more than 256, it 
would fail for certain./*

*I think we should re-consider the length limit for TMPDIR.*


Thanks,
Chen Qi



>
>> [YOCTO #2766]
>>
>> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
>> ---
>>   meta/classes/autotools.bbclass |   14 +++++++++-----
>>   1 file changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/meta/classes/autotools.bbclass 
>> b/meta/classes/autotools.bbclass
>> index b97d74b..86d8939 100644
>> --- a/meta/classes/autotools.bbclass
>> +++ b/meta/classes/autotools.bbclass
>> @@ -123,8 +123,11 @@ autotools_do_configure() {
>>           rm -f `dirname $ac`/configure
>>           done )
>>       if [ -e ${S}/configure.in -o -e ${S}/configure.ac ]; then
>> +               [ -e configure.in ] && CONFIGURE_AC=configure.in || 
>> CONFIGURE_AC=configure.ac
>>           olddir=`pwd`
>>           cd ${S}
>> +        # Determine whether there's subdirs to configure
>> +        grep -q -m 1 AC_CONFIG_SUBDIRS $CONFIGURE_AC && sub_cfg=1 || 
>> sub_cfg=0
>>           # Remove any previous copy of the m4 macros
>>           rm -rf ${B}/aclocal-copy/
>>           ACLOCAL="aclocal --system-acdir=${B}/aclocal-copy/"
>> @@ -132,6 +135,11 @@ autotools_do_configure() {
>>               acpaths=
>>               for i in `find ${S} -maxdepth 2 -name \*.m4|grep -v 
>> 'aclocal.m4'| \
>>                   grep -v 'acinclude.m4' | grep -v 'aclocal-copy' | 
>> sed -e 's,\(.*/\).*$,\1,'|sort -u`; do
>> +                    # If no subdirs to configure, we use relative path
>> +                    # This is used for supporting long TMPDIR in Yocto
>> +                    if [ $sub_cfg == 0 ]; then
>> +                        i=`echo $i | sed -e 's#${S}#\.#'`
>> +                fi
>>                   acpaths="$acpaths -I $i"
>>               done
>>           else
>> @@ -161,11 +169,7 @@ autotools_do_configure() {
>>           if ! echo ${EXTRA_AUTORECONF} | grep -q "aclocal"; then
>>               rm -f aclocal.m4
>>           fi
>> -        if [ -e configure.in ]; then
>> -            CONFIGURE_AC=configure.in
>> -        else
>> -            CONFIGURE_AC=configure.ac
>> -        fi
>> +
>>           if grep "^[[:space:]]*AM_GLIB_GNU_GETTEXT" $CONFIGURE_AC 
>> >/dev/null; then
>>               if grep "sed.*POTFILES" $CONFIGURE_AC >/dev/null; then
>>                   : do nothing -- we still have an old unmodified 
>> configure.ac
>>
>



[-- Attachment #2: Type: text/html, Size: 9233 bytes --]

      reply	other threads:[~2012-11-23  8:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-09  5:47 [PATCH 0/1] autotools.bbclass: use relative path for acpaths whenever possible Qi.Chen
2012-11-09  5:47 ` [PATCH 1/1] " Qi.Chen
2012-11-22  0:19   ` Saul Wold
2012-11-23  8:31     ` ChenQi [this message]

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=50AF3476.1000401@windriver.com \
    --to=qi.chen@windriver.com \
    --cc=Zhenfeng.Zhao@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=sgw@linux.intel.com \
    /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