./configure with CC="ccache gcc" doesn't work

./configure with CC="ccache gcc" doesn't work

[Andy Wingo]

Hello,

On my Fedora 13 x86-64 system,

    $ env | grep CC
    CC=ccache gcc
    $ ./configure --prefix=/usr --libdir=/usr/lib64
    [...]
    Checking for getline... No (will use our own instead).
    Checking for strcasestr... No (will use our own instead).
    Checking for rpath support... No (nothing to worry about).
    Checking for -Wl,--as-needed... No (nothing to worry about).
    [... success ...]

The replacement strcasestr later causes build errors:

    CXX -O2 lib/directory.o
    In file included from lib/notmuch-private.h:41,
                     from lib/directory.cc:22:
    /usr/include/string.h:371: error: new declaration ‘const char* strcasestr(const char*, const char*)’
    compat/compat.h:46: error: ambiguates old declaration ‘char* strcasestr(const char*, const char*)’

But if I export CC=gcc, things succeed:

    Checking for getline... Yes.
    Checking for strcasestr... Yes.
    Checking for rpath support... Yes.

And the build goes fine.

I think the problem occurs due to the IFS setting in configure.  Not
sure what the right solution is; I am not married to having ccache in the
environment.  It's simply that this is what has worked in the past.  If
there is a better option for using ccache I'm happy to switch, as long
as it's globally applicable.

Happy hacking,

Andy

Re: ./configure with CC="ccache gcc" doesn't work

[Michal Sojka]

Hi Andy,

On Wed, 19 Jan 2011, Andy Wingo wrote:
> On my Fedora 13 x86-64 system,
> 
>     $ env | grep CC
>     CC=ccache gcc
>     $ ./configure --prefix=/usr --libdir=/usr/lib64
>     [...]
>     Checking for getline... No (will use our own instead).
>     Checking for strcasestr... No (will use our own instead).
>     Checking for rpath support... No (nothing to worry about).
>     Checking for -Wl,--as-needed... No (nothing to worry about).
>     [... success ...]
> 
> The replacement strcasestr later causes build errors:
> 
>     CXX -O2 lib/directory.o
>     In file included from lib/notmuch-private.h:41,
>                      from lib/directory.cc:22:
>     /usr/include/string.h:371: error: new declaration ‘const char* strcasestr(const char*, const char*)’
>     compat/compat.h:46: error: ambiguates old declaration ‘char* strcasestr(const char*, const char*)’
> 
> But if I export CC=gcc, things succeed:
> 
>     Checking for getline... Yes.
>     Checking for strcasestr... Yes.
>     Checking for rpath support... Yes.
> 
> And the build goes fine.
> 
> I think the problem occurs due to the IFS setting in configure.  Not
> sure what the right solution is; I am not married to having ccache in the
> environment.  It's simply that this is what has worked in the past.  If
> there is a better option for using ccache I'm happy to switch, as long
> as it's globally applicable.

Hmm, the IFS thing in configure seems annoying in this case. But you can
create a little script containing

  exec ccache gcc "$@"

and set CC to the name of the script, cannot you?

-Michal

Re: ./configure with CC="ccache gcc" doesn't work

[Andy Wingo]

Hi Michal,

On Thu 20 Jan 2011 10:50, Michal Sojka <sojkam1@fel.cvut.cz> writes:

> Hmm, the IFS thing in configure seems annoying in this case. But you can
> create a little script containing
>
>   exec ccache gcc "$@"
>
> and set CC to the name of the script, cannot you?

Sure.  But the ccache thing is fairly common, AFAIK, and IMO notmuch's
configure should either handle spaces in a non-absolute-path $CC or exit
with an error in that case.

And, oddly enough, the $CC does succeed in compiling, modulo this build
error -- so it seems that the $IFS isn't actually providing any benefit
in this case.  (If the IFS did its job, I would expect to see an error
like "ccache gcc: command not found" or something.)

Andy

Re: ./configure with CC="ccache gcc" doesn't work

[Michal Sojka]

On Thu, 20 Jan 2011, Andy Wingo wrote:
> On Thu 20 Jan 2011 10:50, Michal Sojka <sojkam1@fel.cvut.cz> writes:
> 
> > Hmm, the IFS thing in configure seems annoying in this case. But you can
> > create a little script containing
> >
> >   exec ccache gcc "$@"
> >
> > and set CC to the name of the script, cannot you?
> 
> Sure.  But the ccache thing is fairly common, AFAIK, and IMO notmuch's
> configure should either handle spaces in a non-absolute-path $CC or exit
> with an error in that case.
> 
> And, oddly enough, the $CC does succeed in compiling, modulo this build
> error -- so it seems that the $IFS isn't actually providing any benefit
> in this case.  (If the IFS did its job, I would expect to see an error
> like "ccache gcc: command not found" or something.)

Hmm, after experimenting a bit, it seems that there is no way to
distinguish between the command with space in its name and your case
with ccache.

I tend to think that having IFS without space is not much useful here
because plenty of software use GNU Make and it cannot handle file names
with spaces at all. So many things would be really difficult, if someone
use spaces in the name of his/her binaries such as gcc or xapian-config.

I went through configure in notmuch and it seems that there is only one
place where the value of IFS matters (the call to ldconfig), so we may
want to apply the patch bellow. On the other hand, a brief look at
Makefile reveals that there are many things that wont work if there are
spaces in filanames[1], so I'm not sure whether to care about that
single case at all.

diff --git a/configure b/configure
index c58dd0f..a196962 100755
--- a/configure
+++ b/configure
@@ -1,13 +1,5 @@
 #! /bin/sh
 
-# Removing space from IFS makes it much easier to support filenames
-# with spaces. See http://www.dwheeler.com/essays/filenames-in-shell.html
-# for gory details.
-IFS="$(printf '\n\t')"
-
-# Since we don't have space in IFS we use tab to separate things in lists
-tab="$(printf '\t')"
-
 # Set several defaults (optionally specified by the user in
 # environemnt variables)
 CC=${CC:-gcc}
@@ -303,11 +295,14 @@ elif [ $uname = "Linux" ] ; then
     platform=LINUX
     linker_resolves_library_dependencies=1
     ldconfig_paths=$(/sbin/ldconfig -N -X -v 2>/dev/null | sed -n -e 's,^\(/.*\):\( (.*)\)\?$,\1,p')
+    OLD_IFS=$IFS
+    IFS="$(printf '\n')" 
     for path in $ldconfig_paths; do
        if [ "$path" = "$libdir_expanded" ]; then
            libdir_in_ldconfig=1
        fi
     done
+    IFS=$OLD_IFS
 else
     printf "Unknown.\n"
     cat <<EOF


Footnotes: 
[1]  For example most commands in install targets contain unquoted
     parameters so if DESTDIR contains a space, it wont work.

Re: ./configure with CC="ccache gcc" doesn't work

[Carl Worth]

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

On Thu, 20 Jan 2011 15:38:39 +0100, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> On Thu, 20 Jan 2011, Andy Wingo wrote:
> > Sure.  But the ccache thing is fairly common, AFAIK, and IMO notmuch's
> > configure should either handle spaces in a non-absolute-path $CC or exit
> > with an error in that case.

Hi Andy,

Thanks for pointing out the bug. I didn't notice this because I get
ccache by putting a symlink in ~/bin/cc -> /usr/bin/ccache.

I hadn't expected the IFS change to cause any problem like this, but
there it is.

> I went through configure in notmuch and it seems that there is only one
> place where the value of IFS matters (the call to ldconfig), so we may
> want to apply the patch bellow. On the other hand, a brief look at
> Makefile reveals that there are many things that wont work if there are
> spaces in filanames[1], so I'm not sure whether to care about that
> single case at all.

Thanks for the analysis. I've committed this change now.

> [1]  For example most commands in install targets contain unquoted
>      parameters so if DESTDIR contains a space, it wont work.

I've run through and fixed all of these that I saw. And I did a quick
test with:

	make DESTDIR="/tmp/bar baz" install

and it at least seems to work.

I agree that this kind of thing is probably not likely to happen
often. But since I did decide to invent my own build system, I feel I
have an obligation to make it as "correct" as possible.

-Carl

-- 
carl.d.worth@intel.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]