'scan-build ./configure' hang

Hi,

I’m trying to analyze a certain project [1] with the clang-analyzer. But at a certain step [2] during ‘scan-build ./configure’, the command appears to hang (or at least perform so slowly that it appears to hang). If I just run ‘./configure’ without scan-build, the configure finishes quite fast and as expected. I’m running the latest svn version (r252789) of llvm/clang/scan-build on Fedora 23.

I aborted the scan-build and took a look at ‘config.log’ but must admit I’m not quite sure what to look for.

Any and all help to figure out what is going on here, and help fix it, is appreciated.

Thanks,

  • Maarten

[1]
Hyperion
https://github.com/hercules-390/hyperion

[2]
checking whether getopt wrapper kludge is necessary…

I usually run ‘top’ in another console. Often, you will find an instance of clang running the analyzer. It is usually taking a fair amount of CPU and memory.

If this is the case, then you may be able to look at the command line to see which part of the configure is causing the slow build.

Hi,

Thanks for the feedback, its appreciated. Well I tried to do some digging, and it looks to me like this specific configure step is trying to compile these two small c testcases [1] (config.log mentions ‘conftest.c’, but I couldnt find that file on disk).

$ ps -ef | grep ccc-analyzer
gives me :
/bin/sh ./libtool --mode=compile /usr/local/bin/…/libexec/ccc-analyzer conftest1.c -c -o conftest1.lo

Running this on the command line gives me endless lines of this :

Waiting for -c.o.lock to be removed
Waiting for -c.o.lock to be removed

and so on and so on

  • Maarten

[1]
$ cat conftest1.c

/*
Test program that needs getopt, called by
another program which itself needs getopt.
Will the linker complain about duplicate
symbols for getopt? We’ll soon find out!
*/
extern char *optarg;
extern int optind;

int test1()
{
int i;
char *c;

i=optind;
c=optarg;

getopt(0,0,0);

return 0;
}

$ cat conftest2.c

/*
Test program that not only needs getopt,
but also calls another program which also
needs getopt. Will linker complain about
duplicate symbols for getopt? Let’s see.
*/
extern char *optarg;
extern int optind;
extern int test2();

int test2()
{
int i;
char *c;

i=optind;
c=optarg;

getopt(0,0,0);
test1();

return 0;
}

I usually run 'top' in another console. Often, you will find an
instance of clang running the analyzer. It is usually taking a fair
amount of CPU and memory.

If this is the case, then you may be able to look at the command line to
see which part of the configure is causing the slow build.

Hi,

I'm trying to analyze a certain project [1] with the clang-analyzer.
But at a certain step [2] during 'scan-build ./configure', the command
appears to hang (or at least perform so slowly that it appears to
hang). If I just run './configure' without scan-build, the configure
finishes quite fast and as expected. I'm running the latest svn
version (r252789) of llvm/clang/scan-build on Fedora 23.

I aborted the scan-build and took a look at 'config.log' but must
admit I'm not quite sure what to look for.

Any and all help to figure out what is going on here, and help fix it,
is appreciated.

I think you ought to be running scan-build on the resulting makefiles, not on configure itself (unless you intend to analyze the code that configure uses to feature-test the compiler).

Jon

It is sometimes important to run scan-build on ./configure as well because configure often generates Makefiles that have paths that are hard-wired to the compiler, which scan-build interposes. There are more details about this at <http://clang-analyzer.llvm.org/scan-build.html#recommended_autoconf>.

Devin

Hi,

I think you ought to be running scan-build on the resulting makefiles, not on configure itself (unless you intend to analyze the code that configure uses to feature-test the compiler).

Well it that case, ive been doing it wrong for years now.
:wink:

I thought the reason for running configure through scan-build, is because configure generates the makefiles that contain CC= (and friends) that will give you gcc instead of ccc-analyzer if you dont run ‘scan-build ./configure’, so that you can just do :

$ scan-build -o /dir1/dir2 ./configure

$ scan-build make

Of course, I may be wrong.

  • Maarten

I think you ought to be running scan-build on the resulting makefiles, not on configure itself (unless you intend to analyze the code that configure uses to feature-test the compiler).

It is sometimes important to run scan-build on ./configure as well because configure often generates Makefiles that have paths that are hard-wired to the compiler, which scan-build interposes. There are more details about this at <http://clang-analyzer.llvm.org/scan-build.html#recommended_autoconf>.

Devin

Ah. Thanks for that. I thought I was losing it there for a second.
:wink:

  • Maarten

Hi,

>
> I think you ought to be running scan-build on the resulting
makefiles, not on configure itself (unless you intend to analyze the
code that configure uses to feature-test the compiler).
>

Well it that case, ive been doing it wrong for *years* now.
:wink:

I thought the reason for running configure through scan-build, is
because configure generates the makefiles that contain CC= (and friends)
that will give you gcc instead of ccc-analyzer if you dont run
'scan-build ./configure', so that you can just do :

$ scan-build -o /dir1/dir2 ./configure
$ scan-build make

Of course, I may be wrong.

Oh, yeah, you're right.

Jon

Well, I guess Ill go open a bug report then.

Thanks for the help.

  • Maarten

Done. : https://llvm.org/bugs/show_bug.cgi?id=25502

  • Maarten