Nabble - Gnu - cFlow - Discuss

Re: how to handle redefines, in particular the ellipsis symbol

2009-11-08T16:13:10Z

Larry Evans <cppljevans@...> ha escrit:

> evansl@evansl-desktop:~$ cflow --version
> cflow (GNU cflow) 1.2

That version is old, but it turned out that 1.3 performs poorly on
gcc sources as well. Thanks for reporting. This led me to fixing
a minor bug in the parser and improving performance on deeply nested
recursive calls. The fixed version is available here:

ftp://download.gnu.org.ua/pub/alpha/cflow/cflow-1.3.1-20091109.tar.bz2

Please give it a try.

> This is given by the attached cflow.mk file.

Oh my :) That's clearly an overkill. You are trying to define
all preprocessor symbols instead of leaving this job to the cpp.

I used the following cflow.rc (of course, you would need to
adjust include paths):

# cflow.rc begins
-I /home/gray/src/gcc
-I /home/gray/src/gcc/gcc
-I /home/gray/src/gcc/include
-I /home/gray/src/gcc/host-i686-pc-linux-gnu/gcc
-I /home/gray/src/gcc/libcpp/include/
--symbol __const:type
--symbol __restrict:type
-D__extension__=
-D__attribute__\$c\$=
-D__asm__\$c\$=
-D__inline__
-D__inline
# cflow.rc ends

Cflow was called from /home/gray/src/gcc/gcc/cp this way:

CFLOWRC=./cflow.rc cflow -b *.c > out.cf

The version 1.3.1 produced a flowchart without warnings.

Regards,
Sergey

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: how to handle redefines, in particular the ellipsis symbol

2009-11-08T08:47:23Z

Hi Larry,

Cflow handles ellipsis by default, since it is required by the standard.
If it fails to do so, that's probably some preceding symbol that makes the
things go out of whack. You have not given enough information for
me to be able to reproduce the situation. In particular, you have
forgotten to say: (1) what version of GNU cflow you are using, (2) how
do you invoke it, and (3) what is the contents of gcc/cp/pt.c.

Regards,
Sergey

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

how to handle redefines, in particular the ellipsis symbol

2009-11-08T07:46:19Z

While running cflow on gcc's preprocessed gcc/cp/pt.c, I get:

> cflow:/usr/include/stdio.h:404: .../-1 redefined
> cflow:/usr/include/stdio.h:362: this is the place of previous definition
> cflow:/usr/include/fcntl.h:120: .../-1 redefined
> cflow:/usr/include/stdio.h:404: this is the place of previous definition
> cflow:/usr/include/malloc.h:50: malloc/1 redefined
> cflow:/usr/include/stdlib.h:471: this is the place of previous definition
> cflow:/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/../include/libiberty.h:149:
> .../-1 redefined
> cflow:/usr/include/fcntl.h:120: this is the place of previous definition
> cflow:/usr/include/gmp.h:1643: __gmpz_fits_ulong_p/1 redefined
> cflow:/usr/include/gmp.h:845: this is the place of previous definition

I attempted to workaround the problem by using a cflow option:

--symbol <SomeRedefinedSymbol>:wrapper

where <SomeRedefinedSymbol> is one of the symbols preceding the
'/-redefined'
in the aforementioned error messages. This seems to work for some
symbols; however, for ..., it doesn't. I tried:

--symbol ...:type

and:

--symbol \.\.\.:type

however, neither worked.

How can I get cflow to not diagnose ... as a redefined symbol?
My Makefile, cflow.mk, and a perl program, cflow.redefined.pl,
used to generate the --symbol options, are attached.

TIA.

-regards,
Larry

SRC.name=pt
TAR.path=cp
SRC.dir=/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc

CFLOW.redefined.syms:= $(shell cat cflow.redefined.out)

CFLOW.wrappers= \
--symbol GTY:wrapper \
--symbol __MALLOC_P:wrapper \
--symbol __attribute_malloc__:wrapper \
--symbol \.\.\.:type \
$(CFLOW.redefined.syms)

.PHONY: cflow.redefined.inp

###The following was based on copying part of the output from:
#
# make -W ./gcc/cp/pt.c -n
#
#The part copied was the output showing the command line for
#compiling cp/pt.c
#

#C.flags= -DIN_GCC -DHAVE_CONFIG_H -I. -Icp -I/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc -I/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp -I/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/../include -I/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/../libcpp/include -I/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/../libdecnumber -I/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/../libdecnumber/bid -I../libdecnumber

C.flags=-g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -Icp -I/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc -I/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/cp -I/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/../include -I/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/../libcpp/include -I/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/../libdecnumber -I/home/evansl/download/gcc/svn/patch.none.gdb/build/../src/gcc/../libdecnumber/bid -I../libdecnumber

###Create preprocessor output files.
%.E.c: %.c
gcc -E $(C.flags) $< -o $@

###The following is based on:
#
# http://www.gnu.org/software/cflow/manual/cflow.html#Makefiles
#
GCC.srcs=$(SRC.dir)/$(TAR.path)/$(SRC.name).E.c

cflow.gcc: $(GCC.srcs) cflow.mk cflow.redefined.out
cflow $(CFLOW.wrappers) -o $@ $(GCC.srcs)

cflow.redefined.inp:
cflow $(CFLOW.wrappers)-o /dev/null $(GCC.srcs) 2> $@.temp
cat $@.temp>>$@

cflow.redefined.out: cflow.redefined.inp cflow.redefined.pl
./cflow.redefined.pl < $< > $@

echo:
@echo CFLOW.redefined.syms=$(CFLOW.redefined.syms)

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

cflow.redefined.pl (932 bytes) Download Attachment

GNU cflow-1.3 released

2009-07-11T13:49:58Z

Hello,

I am pleased to announce the release of GNU cflow 1.3.

GNU cflow analyzes a collection of C source files and prints a graph
charting control flow within the program. It can produce both direct and
inverted flowgraphs for C sources, or optionally generate a cross-reference
listing. It implements POSIX and GNU (extended) output formats. Input files
can optionally be preprocessed before analyzing. The package also provides an
Emacs major mode, which facilitates navigating the produced flowcharts
in Emacs.

This release contains a number of improvements which result in
a considerable performance gain compared with the previous 1.2 release.

Here are the compressed sources:
ftp://ftp.gnu.org/gnu/cflow/cflow-1.3.tar.gz (745KB)
ftp://ftp.gnu.org/gnu/cflow/cflow-1.3.tar.bz2 (589KB)

Here are the GPG detached signatures[*]:
ftp://ftp.gnu.org/gnu/cflow/cflow-1.3.tar.gz.sig
ftp://ftp.gnu.org/gnu/cflow/cflow-1.3.tar.bz2.sig

Here are the MD5 and SHA1 checksums:

9a763fe2c3245234711cd31e21e14dd3 cflow-1.3.tar.gz
b3fe4bfba9d648447065b3c2d73ae66c cflow-1.3.tar.bz2
8cc32e7e75f6b1ecbd90d7699cdd859d9419c28c cflow-1.3.tar.gz
c7f4d7c36f4e94f7f28fa20d140a8c137661622c cflow-1.3.tar.bz2

[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact. First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

gpg --verify cflow-1.3.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 55D0C732

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
Autoconf 2.63
Automake 1.11
Gnulib-tool 0.0.2231-836f3
Makeinfo 4.13

Regards,
Sergey

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: [PATCH] Fix Segmentation fault of -s option

2009-06-28T17:12:18Z

Hi Sergey

Thank you for your reply.
Recentry, I knew the cflow.
I like it.

Best Regards,
Naohiro Ooiwa

Sergey Poznyakoff wrote:

> Hello,
>
>> I found a little bug.
>>
>> # cflow-1.2/src/cflow -s main.c
>> Segmentation fault
>>
>> I fixed it.
>
> Thanks!
>
>> Could you please check my patch?
>
> Sure, your patch is OK. I have applied it.
>
> Best regards,
> Sergey
>

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: [PATCH] Fix Segmentation fault of -s option

2009-06-28T04:29:06Z

Hello,

> I found a little bug.
>
> # cflow-1.2/src/cflow -s main.c
> Segmentation fault
>
> I fixed it.

Thanks!

> Could you please check my patch?

Sure, your patch is OK. I have applied it.

Best regards,
Sergey

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

[PATCH] Fix Segmentation fault of -s option

2009-06-26T04:00:12Z

Hi Sergey Poznyakoff

I found a little bug.

# cflow-1.2/src/cflow -s main.c
Segmentation fault

I fixed it.
Could you please check my patch?

Best Regards,
Naohiro Ooiwa

main.c | 5 +++++
1 file changed, 5 insertions(+)

--- cflow-1.2/src/main.c.orig 2007-06-27 23:16:46.000000000 +0900
+++ cflow-1.2/src/main.c 2009-06-26 19:08:50.000000000 +0900
@@ -257,6 +257,11 @@ symbol_override(const char *str)
Symbol *sp;

ptr = strchr(str, ':');
+
+ if (ptr == NULL) {
+ error(0, 0, _("no argument of symbol"));
+ return;
+ }
if (*ptr == ':') {
type = find_option_type(symbol_optype, ptr+1, 0);
if (type == 0) {

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

#ifdef problem

2008-05-13T11:41:34Z

Sergey,

Thank you for cflow. I find it very helpful.

I ran into a problem where I was missing whole functions although the debug trace showed that they were being parsed. I finally narrowed it down to the way that #ifdef processing is being handled. When I have a code block that is begun by which branch of an #ifdef...#else...#endif, cflow does not properly handle the input. Here is a sample program that will show different behavior based on whether the duplicated if is in the code or commented out:

int main() {
#ifdef WIN32
/* commenting out the next line changes the output */
if (x > 0) { //
#else
if (x != NULL && x > 0) {
#endif
y = 1;
} else {
y = 0;
}
doit();
fake();
}

int doit() {
prinntf("Hello, world.\n");
}

int fake() {
int j = 3;
}

When cflow is run this is its output:

main() <int main () at test.c:1>:
doit()
fake()
prinntf()

which shows that it does not see the doit() and fake() functions properly. But when one of the two block opening statements is commented out, there is the output

main() <int main () at test.c:1>:
doit() <int doit () at test.c:16>:
prinntf()
fake() <int fake () at test.c:20>

which is what is expected.

Thank you for your hard work and consideration of this problem.

sola gratia, sola fide, solo Christo, sola Scriptura, soli Deo gloria,

Rich Yonts
ryonts@...

Kurie, swson me

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

a detailed control flow graph

2008-01-26T12:58:47Z

Hi,
I tried the cflow and it is cool. What I need now is a tool that can construct control flow graph for C as follows:
it identify basic blocks of C source code, the CFG is nodes and edges, that the nodes represent the basic blocks and edges represent the control flow(such as if, for etc), not only the function calls, but all statements. Can cflow achieve this? Or some other tools can achieve it?

Thank you very much!

Regards
David

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: Suggestion for cflow

2008-01-09T00:24:12Z

Jeff <j_post@...> ha escrit:

> Hi. Thanks for making cflow available.

Hi Jeff. Sorry it took me so long to reply.

> Due to the nature of software I develop, I sometimes have functions accessed
> through a pointer table. Cflow apparently only traces functions called
> directly or indirectly from main(), and outputs nothing about functions
> accessed through tables.

Yes, to tell the truth, I often have the same problem:)

> An old DOS program I used to have (I don't recall the name of it) had the
> ability to trace such "orphaned functions". Do you think that feature could
> be added to cflow?

Yes, it could. This feature is already in my TODO list. Implementing it
requires rewriting the parser to do more in-depth analysis of the
code, but, apart from that, I don't see any difficulties. I will inform
you when I have something ready for testing.

Regards,
Sergey

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Suggestion for cflow

2008-01-02T06:21:02Z

Hi. Thanks for making cflow available.

Due to the nature of software I develop, I sometimes have functions accessed
through a pointer table. Cflow apparently only traces functions called
directly or indirectly from main(), and outputs nothing about functions
accessed through tables.

An old DOS program I used to have (I don't recall the name of it) had the
ability to trace such "orphaned functions". Do you think that feature could
be added to cflow?

Thanks,
Jeff

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: compile problem flow-tools 0.68.1 - libft.a

2007-09-21T01:23:53Z

Hello,

You are writing to wrong address. This project has nothing to do with
flow-tools.

Regards,
Sergey

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

compile problem flow-tools 0.68.1 - libft.a

2007-09-20T07:12:11Z

Dear,

Have anyone tried (and managed) compile Cflow-1.053 with flow-tools-0.68.1 ?

I figured out it looks for libft.a on ../../lib (considering you are in dir contrib, as recommended on INSTALL) to "understand" to wich tool it has to be compiled for but flow-tools-0.68.1 doesn't have this lib. Actually it has libft.la

I changed Makefile.PL and at a first glance it did compiled but when I run flowscan I got this error: (probably due this "smooth" change)

Wanted function created
/usr/bin/perl: symbol lookup error: /usr/lib/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Cflow/Cflow.so: undefined symbol: fterr_setid

Any help ?

cflow: --main does not work for static functions?

2007-09-14T08:37:01Z

Hello,

apologies if I have misunderstood something.

It seems to me that cflow's `--main' option does not behave as expected
for functions declared as static.

If I take the whoami.c example in the info docs as is and run:

myhost:265> cflow --main who_am_i whoami.c
who_am_i() <int who_am_i (void) at whoami.c:8>:
getpwuid()
geteuid()
getenv()
fprintf()
printf()

I get what the info docs say.

However, if I change the definition of who_am_i from:

int
who_am_i (void)

to:

static int
who_am_i (void)

and rerun:

myhost:266> cflow --main who_am_i whoami.c
main() <int main (int argc,char **argv) at whoami.c:26>:
fprintf()
who_am_i() <int who_am_i (void) at whoami.c:8>:
getpwuid()
geteuid()
getenv()
fprintf()
printf()

I don't get the same output as before. All works as if the `--main' option
had not been given in this case.

I'm probably missing something: I've read the docs, but I don't seem to
be able to find the reason for this different output (the only ref to
static declarations I could find is about the `-i s' option, which
however should be on by default, if I have well understood...)

If you could give me some clue, it would be warmly appreciated!

Here is the version information:

myhost:263> cflow --version
cflow (GNU cflow) 1.2
Copyright (C) 2005, 2006, 2007 Sergey Poznyakoff
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Sergey Poznyakoff.

Thank you very much in advance.

ciao
gabriele

--
Gabriele Balducci - Dipartimento di Scienze Chimiche - Via L. Giorgieri 1
I-34127 TRIESTE tel: I-040-5583957 fax: I-040-5583903 e-mail: balducci@...
Please, if possible, don't send me MS Word or PowerPoint attachments
Why? See: http://www.gnu.org/philosophy/no-word-attachments.html

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Update cflow web pages

2007-09-07T06:35:04Z

Indeed, download has cflow-1.2, manual (pdf) is or 1.0, perhaps
more mismatches. I think it would be worthwhile to bring everything
to the latest level.

Best regards,

---Zdenek

-----------------------------------------------------
Zdenek Sekera | zdenek.sekera@...
LHC Computing Grid Project | tel: +41-22-767.1068
CERN - IT Division | mobile: +41-76-487.4971
CH-1211 Geneva 23 | fax: +41-22-767.4900
Switzerland |
-----------------------------------------------------

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

smime.p7s (5K) Download Attachment

RE: static function calls not being produced unless explicitly called

2007-08-21T11:31:59Z

Sergey wrote:
> Josiah Carlson (NIM) <jcarlson@...> ha escrit:
> > I have recently started using cflow, and I have noticed that it
doesn't
> > produce static definition results in the call graph unless they are
> > explicitly called by a non-static function.
>
> It does not list any function (be it static or global), unless its
> invocation can be traced up to main function (either `main' or
whatever
> given with the `--main' command line option).
>
> > Personally, I want to see all static functions in the output. I
have
> > worked around it by temporarily removing the static portion of the
> > declaration,
>
> Removing the static qualifier in your example does not change anything
> (if it does, then it is a bug). The only thing that matters is whether
> `foo' is called from `main' or not.

Running variants of the example I sent previously does not seem to show
the behavior I am experiencing when running it on a group of 20 or so
.c/.h files.

Though by your description of cflow's behavior, I shouldn't be seeing
any output, as none of the source files I am running cflow on have any
main function (they are all Python extension modules), nor have I been
passing anything with --main (unless something magical happens when you
do something like 'cflow *.[ch]' ).

I guess to get the behavior I desire I will have to change cflow to suit
my needs. Thank you for your help Sergey,

- Josiah

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: static function calls not being produced unless explicitly called

2007-08-21T02:33:49Z

Josiah Carlson (NIM) <jcarlson@...> ha escrit:

> I have recently started using cflow, and I have noticed that it doesn't
> produce static definition results in the call graph unless they are
> explicitly called by a non-static function.

It does not list any function (be it static or global), unless its
invocation can be traced up to main function (either `main' or whatever
given with the `--main' command line option).

> Personally, I want to see all static functions in the output. I have
> worked around it by temporarily removing the static portion of the
> declaration,

Removing the static qualifier in your example does not change anything
(if it does, then it is a bug). The only thing that matters is whether
`foo' is called from `main' or not.

Regards,
Sergey

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

static function calls not being produced unless explicitly called

2007-08-20T14:05:44Z

Good day,

I have recently started using cflow, and I have noticed that it doesn’t produce static definition results in the call graph unless they are explicitly called by a non-static function. For example…

When running the following source through cflow via ‘cflow test.c’…

static long

foo(void) {

return 0;

}

int

main(char** argc, int argv) {

/* uncomment the following and foo is now output */

/* foo(); */

return 1;

}

I get the following…

main() <int main (char **argc,int argv) at test.c:8>:

But when I uncomment the foo call, I get…

main() <int main (char **argc,int argv) at test.c:8>:

foo() <long foo (void) at test.c:3>

Personally, I want to see all static functions in the output. I have worked around it by temporarily removing the static portion of the declaration, but not having to do such a thing (to a few dozen files) would be nice. If this is intended behavior, then I suppose I will live with it.

Thank you,

- Josiah Carlson

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

infinite recursion

2007-08-12T11:17:21Z

I'll go build 1.2 to see if it is any better. Thanks.

(gdb) bt
#0 0x0804c308 in dirdcl (idptr=0xbf84d250) at parser.c:767
#1 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#2 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#3 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#4 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#5 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#6 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#7 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#8 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#9 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#10 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#11 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#12 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#13 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#14 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#15 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#16 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#17 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#18 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#19 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#20 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
#21 0x0804c30d in dirdcl (idptr=0xbf84d250) at parser.c:767
$ cflow --version
cflow (GNU cflow) 1.0

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

cflow 1.2 build on AIX using standard compiler

2007-07-09T06:18:53Z

Good day,

I tried without success to build GNU cflow on platform AIX 5.2 ML06
The compiler is the standard IBM compiler vac (Visual Age C) 5.0.2.0

I did not inquire into the problem further, since I was able to compile it using
gcc, but I inform you anyway. Later is a copy of the configure and make
commands.

Best regards,
Francois Chartier

***

fc@cdaix:/partage/fc/tmp/cflow-1.2> ./configure --prefix=/partage/fc/AIX
checking for a BSD-compatible install... build-aux/install-sh -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
checking for nawk... nawk
checking whether make sets $(MAKE)... yes
checking for ranlib... ranlib
checking for style of include used by make... GNU
checking for gcc... no
checking for cc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... -qlanglvl=ansi
checking dependency style of cc -qlanglvl=ansi... aix
checking how to run the C preprocessor... cc -qlanglvl=ansi -E
checking for grep that handles long lines and -e... /partage/fc/AIX/bin/grep
checking for egrep... /partage/fc/AIX/bin/grep -E
checking for AIX... yes
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for cc -qlanglvl=ansi option to accept ISO C99... unsupported
checking for cc -qlanglvl=ansi option to accept ISO C89... (cached)
-qlanglvl=ansi
checking for cc -qlanglvl=ansi -qlanglvl=ansi option to accept ISO Standard C...
(cached) -qlanglvl=ansi
checking whether we are using the GNU C compiler... (cached) no
checking whether cc accepts -g... (cached) yes
checking for cc option to accept ISO C89... (cached) -qlanglvl=ansi
checking dependency style of cc -qlanglvl=ansi... (cached) aix
checking for flex... flex
checking for yywrap in -lfl... yes
checking lex output file root... lex.yy
checking whether yytext is a pointer... yes
checking for ranlib... (cached) ranlib
checking for ANSI C header files... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking for error_at_line... no
checking for memmove... yes
checking for memset... yes
checking for strdup... yes
checking for strerror... yes
checking for strtol... yes
checking for setlocale... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for inline... __inline
checking for C/C++ restrict keyword... no
checking whether getenv is declared... yes
checking whether clearerr_unlocked is declared... no
checking whether feof_unlocked is declared... no
checking whether ferror_unlocked is declared... no
checking whether fflush_unlocked is declared... no
checking whether fgets_unlocked is declared... no
checking whether fputc_unlocked is declared... no
checking whether fputs_unlocked is declared... no
checking whether fread_unlocked is declared... no
checking whether fwrite_unlocked is declared... no
checking whether getc_unlocked is declared... yes
checking whether getchar_unlocked is declared... yes
checking whether putc_unlocked is declared... yes
checking whether putchar_unlocked is declared... yes
checking for flockfile... yes
checking for funlockfile... yes
checking for sleep... yes
checking for lstat... yes
checking for vasnprintf... no
checking features.h usability... no
checking features.h presence... no
checking for features.h... no
checking linewrap.h usability... no
checking linewrap.h presence... no
checking for linewrap.h... no
checking float.h usability... yes
checking float.h presence... yes
checking for float.h... yes
checking for stdint.h... (cached) yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking sysexits.h usability... yes
checking sysexits.h presence... yes
checking for sysexits.h... yes
checking for unistd.h... (cached) yes
checking whether system is Windows or MSDOS... no
checking build system type... powerpc-ibm-aix5.2.0.0
checking host system type... powerpc-ibm-aix5.2.0.0
checking whether // is distinct from /... no
checking whether strerror_r is declared... yes
checking for strerror_r... yes
checking whether strerror_r returns char *... no
checking whether the preprocessor supports include_next... yes
checking getopt.h usability... no
checking getopt.h presence... no
checking for getopt.h... no
checking for stdbool.h that conforms to C99... no
checking for _Bool... no
checking whether snprintf is declared... yes
checking for long long int... yes
checking for unsigned long long int... yes
checking whether strndup is declared... yes
checking whether strnlen is declared... yes
checking whether stat file-mode macros are broken... no
checking for EOVERFLOW... yes
checking for wchar_t... yes
checking for wint_t... yes
checking for size_t... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for intmax_t... yes
checking whether vsnprintf is declared... yes
checking for alloca as a compiler built-in... yes
checking whether program_invocation_name is declared... no
checking whether program_invocation_short_name is declared... no
checking whether program_invocation_name is defined... no
checking whether program_invocation_short_name is defined... no
checking whether // is distinct from /... (cached) no
checking for error_at_line... (cached) no
checking whether the compiler generally respects inline... yes
checking whether lstat dereferences a symlink specified with a trailing slash...
no
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... no
checking for mempcpy... no
checking for obstacks... no
checking for stdint.h... (cached) yes
checking for SIZE_MAX... yes
checking for snprintf... yes
checking for va_copy... yes
checking whether stdint.h conforms to C99... no
checking sys/inttypes.h usability... yes
checking sys/inttypes.h presence... yes
checking for sys/inttypes.h... yes
checking sys/bitypes.h usability... no
checking sys/bitypes.h presence... no
checking for sys/bitypes.h... no
checking for bit size of ptrdiff_t... 32
checking for bit size of sig_atomic_t... 32
checking for bit size of size_t... 32
checking for bit size of wchar_t... 16
checking for bit size of wint_t... 32
checking whether sig_atomic_t is signed... yes
checking whether wchar_t is signed... no
checking whether wint_t is signed... yes
checking for ptrdiff_t integer literal suffix... l
checking for sig_atomic_t integer literal suffix... no
checking for size_t integer literal suffix... ul
checking for wchar_t integer literal suffix... no
checking for wint_t integer literal suffix...
checking for strcasecmp... yes
checking for strncasecmp... yes
checking whether strncasecmp is declared... yes
checking for strchrnul... no
checking for working strndup... yes
checking for working strnlen... yes
checking whether mkdir is declared... yes
checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
checking for ptrdiff_t... yes
checking for snprintf... (cached) yes
checking for wcslen... yes
checking whether _snprintf is declared... no
checking for vsnprintf... yes
checking whether <wchar.h> is standalone... yes
checking for stdint.h... (cached) yes
checking for emacs... emacs
checking where .elc files should go... ${datadir}/emacs/site-lisp
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... no
checking for msgmerge... no
checking for non-GNU ld... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for shared library run path origin... done
checking for CFPreferencesCopyAppValue... no
checking for CFLocaleCopyCurrent... no
checking for GNU gettext in libc... no
checking for iconv... yes
checking for working iconv... no
checking for GNU gettext in libintl... no
checking whether to use NLS... no
configure: creating ./config.status
config.status: creating tests/Makefile
config.status: creating tests/atlocal
config.status: creating Makefile
config.status: creating lib/Makefile
config.status: creating src/Makefile
config.status: creating elisp/Makefile
config.status: creating po/Makefile.in
config.status: creating doc/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
config.status: executing tests/atconfig commands
fc@cdaix:/partage/fc/tmp/cflow-1.2> read

fc@cdaix:/partage/fc/tmp/cflow-1.2> l
total 3048
-rw-r--r-- 1 fc cgf 33 Mar 19 2005 AUTHORS
-rw-r--r-- 1 fc cgf 1312 Mar 19 2005 acinclude.m4
-rw-r--r-- 1 fc cgf 2182 Sep 25 2005 TODO
-rw-r--r-- 1 fc cgf 3186 Oct 19 2005 README
-rw-r--r-- 1 fc cgf 9416 Jun 26 2006 INSTALL
-rw-r--r-- 1 fc cgf 278 Sep 10 2006 THANKS
-rw-r--r-- 1 fc cgf 79584 May 18 14:06 ABOUT-NLS
-rw-r--r-- 1 fc cgf 937 Jun 27 16:16 Makefile.am
-rw-r--r-- 1 fc cgf 35068 Jun 29 07:45 COPYING
-rw-r--r-- 1 fc cgf 2267 Jun 29 15:31 configure.ac
-rw-r--r-- 1 fc cgf 22299 Jun 29 15:32 ChangeLog
-rw-r--r-- 1 fc cgf 1773 Jun 29 15:32 NEWS
-rw-r--r-- 1 fc cgf 39409 Jun 29 15:35 aclocal.m4
-rwxr-xr-x 1 fc cgf 622084 Jun 29 15:35 configure
-rw-r--r-- 1 fc cgf 14806 Jun 29 15:35 config.h.in
-rw-r--r-- 1 fc cgf 29474 Jun 29 15:35 Makefile.in
drwxr-sr-x 2 fc cgf 1536 Jun 29 15:36 m4
drwxr-sr-x 2 fc cgf 512 Jun 29 15:36 build-aux
drwxr-sr-x 6 fc cgf 1024 Jul 9 11:44 ..
-rwxr-xr-x 1 fc cgf 51319 Jul 9 11:47 config.status
-rw-r--r-- 1 fc cgf 27818 Jul 9 11:47 Makefile
drwxr-sr-x 2 fc cgf 512 Jul 9 11:47 elisp
drwxr-sr-x 2 fc cgf 512 Jul 9 11:47 doc
-rw-r--r-- 1 fc cgf 23 Jul 9 11:47 stamp-h1
-rw-r--r-- 1 fc cgf 15497 Jul 9 11:47 config.h
drwxr-sr-x 3 fc cgf 2048 Jul 9 11:47 lib
drwxr-sr-x 3 fc cgf 512 Jul 9 11:47 src
drwxr-sr-x 2 fc cgf 1024 Jul 9 11:47 po
drwxr-sr-x 2 fc cgf 1024 Jul 9 11:47 tests
drwxr-sr-x 10 fc cgf 1024 Jul 9 11:47 .
-rw-r--r-- 1 fc cgf 512443 Jul 9 11:47 config.log
fc@cdaix:/partage/fc/tmp/cflow-1.2> make
make all-recursive
Making all in lib
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; cat ./alloca_.h;
} > alloca.h-t
mv -f alloca.h-t alloca.h
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; cat ./getopt_.h;
} > getopt.h-t
mv -f getopt.h-t getopt.h
rm -f stdbool.h-t stdbool.h
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; sed -e
's/@''HAVE__BOOL''@/0/g' < ./stdbool_.h; } > stdbool.h-t
mv stdbool.h-t stdbool.h
rm -f stdint.h-t stdint.h
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; sed -e
's/@''HAVE_STDINT_H''@/1/g' -e 's/@''INCLUDE_NEXT''@/include_next/g' -e
's|@''NEXT_STDINT_H''@|<stdint.h>|g' -e 's/@''HAVE_SYS_TYPES_H''@/1/g' -e
's/@''HAVE_INTTYPES_H''@/1/g' -e 's/@''HAVE_SYS_INTTYPES_H''@/1/g' -e
's/@''HAVE_SYS_BITYPES_H''@/0/g' -e 's/@''HAVE_LONG_LONG_INT''@/1/g' -e
's/@''HAVE_UNSIGNED_LONG_LONG_INT''@/1/g' -e 's/@''BITSIZEOF_PTRDIFF_T''@/32/g'
-e 's/@''PTRDIFF_T_SUFFIX''@/l/g' -e 's/@''BITSIZEOF_SIG_ATOMIC_T''@/32/g' -e
's/@''HAVE_SIGNED_SIG_ATOMIC_T''@/1/g' -e 's/@''SIG_ATOMIC_T_SUFFIX''@//g' -e
's/@''BITSIZEOF_SIZE_T''@/32/g' -e 's/@''SIZE_T_SUFFIX''@/ul/g' -e
's/@''BITSIZEOF_WCHAR_T''@/16/g' -e 's/@''HAVE_SIGNED_WCHAR_T''@/0/g' -e
's/@''WCHAR_T_SUFFIX''@//g' -e 's/@''BITSIZEOF_WINT_T''@/32/g' -e
's/@''HAVE_SIGNED_WINT_T''@/1/g' -e 's/@''WINT_T_SUFFIX''@//g' < ./stdint_.h;
} > stdint.h-t
mv stdint.h-t stdint.h
rm -f stdio.h-t stdio.h
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && sed -e
's/@''INCLUDE_NEXT''@/include_next/g' -e 's|@''NEXT_STDIO_H''@|<stdio.h>|g' -e
's|@''GNULIB_FPRINTF_POSIX''@|0|g' -e 's|@''GNULIB_PRINTF_POSIX''@|0|g' -e
's|@''GNULIB_SNPRINTF''@|1|g' -e 's|@''GNULIB_SPRINTF_POSIX''@|0|g' -e
's|@''GNULIB_VFPRINTF_POSIX''@|0|g' -e 's|@''GNULIB_VPRINTF_POSIX''@|0|g' -e
's|@''GNULIB_VSNPRINTF''@|1|g' -e 's|@''GNULIB_VSPRINTF_POSIX''@|0|g' -e
's|@''GNULIB_VASPRINTF''@|0|g' -e 's|@''GNULIB_FSEEK''@|0|g' -e
's|@''GNULIB_FSEEKO''@|0|g' -e 's|@''GNULIB_FTELL''@|0|g' -e
's|@''GNULIB_FTELLO''@|0|g' -e 's|@''GNULIB_FFLUSH''@|0|g' -e
's|@''REPLACE_FPRINTF''@|0|g' -e 's|@''REPLACE_VFPRINTF''@|0|g' -e
's|@''REPLACE_PRINTF''@|0|g' -e 's|@''REPLACE_VPRINTF''@|0|g' -e
's|@''REPLACE_SNPRINTF''@|0|g' -e 's|@''HAVE_DECL_SNPRINTF''@|1|g' -e
's|@''REPLACE_VSNPRINTF''@|0|g' -e 's|@''HAVE_DECL_VSNPRINTF''@|1|g' -e
's|@''REPLACE_SPRINTF''@|0|g' -e 's|@''REPLACE_VSPRINTF''@|0|g' -e
's|@''HAVE_VASPRINTF''@|1|g' -e 's|@''REPLACE_VASPRINTF''@|0|g' -e
's|@''REPLACE_FSEEKO''@|0|g' -e 's|@''REPLACE_FSEEK''@|0|g' -e
's|@''REPLACE_FTELLO''@|0|g' -e 's|@''REPLACE_FTELL''@|0|g' -e
's|@''REPLACE_FFLUSH''@|0|g' -e '/definition of GL_LINK_WARNING/r
../build-aux/link-warning.h' < ./stdio_.h; } > stdio.h-t
mv stdio.h-t stdio.h
rm -f stdlib.h-t stdlib.h
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && sed -e
's/@''INCLUDE_NEXT''@/include_next/g' -e 's|@''NEXT_STDLIB_H''@|<stdlib.h>|g'
-e 's|@''GNULIB_GETSUBOPT''@|0|g' -e 's|@''GNULIB_MKDTEMP''@|0|g' -e
's|@''GNULIB_MKSTEMP''@|0|g' -e 's|@''HAVE_GETSUBOPT''@|1|g' -e
's|@''HAVE_MKDTEMP''@|1|g' -e 's|@''REPLACE_MKSTEMP''@|0|g' -e '/definition of
GL_LINK_WARNING/r ../build-aux/link-warning.h' < ./stdlib_.h; } > stdlib.h-t
mv stdlib.h-t stdlib.h
rm -f string.h-t string.h
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */' && sed -e
's/@''INCLUDE_NEXT''@/include_next/g' -e 's|@''NEXT_STRING_H''@|<string.h>|g'
-e 's|@''GNULIB_MBSLEN''@|0|g' -e 's|@''GNULIB_MBSNLEN''@|0|g' -e
's|@''GNULIB_MBSCHR''@|0|g' -e 's|@''GNULIB_MBSRCHR''@|0|g' -e
's|@''GNULIB_MBSSTR''@|0|g' -e 's|@''GNULIB_MBSCASECMP''@|0|g' -e
's|@''GNULIB_MBSNCASECMP''@|0|g' -e 's|@''GNULIB_MBSPCASECMP''@|0|g' -e
's|@''GNULIB_MBSCASESTR''@|0|g' -e 's|@''GNULIB_MBSCSPN''@|0|g' -e
's|@''GNULIB_MBSPBRK''@|0|g' -e 's|@''GNULIB_MBSSPN''@|0|g' -e
's|@''GNULIB_MBSSEP''@|0|g' -e 's|@''GNULIB_MBSTOK_R''@|0|g' -e
's|@''GNULIB_MEMMEM''@|0|g' -e 's|@''GNULIB_MEMPCPY''@|1|g' -e
's|@''GNULIB_MEMRCHR''@|0|g' -e 's|@''GNULIB_STPCPY''@|0|g' -e
's|@''GNULIB_STPNCPY''@|0|g' -e 's|@''GNULIB_STRCHRNUL''@|1|g' -e
's|@''GNULIB_STRDUP''@|0|g' -e 's|@''GNULIB_STRNDUP''@|1|g' -e
's|@''GNULIB_STRNLEN''@|1|g' -e 's|@''GNULIB_STRPBRK''@|0|g' -e
's|@''GNULIB_STRSEP''@|0|g' -e 's|@''GNULIB_STRCASESTR''@|0|g' -e
's|@''GNULIB_STRTOK_R''@|0|g' -e 's|@''HAVE_DECL_MEMMEM''@|1|g' -e
's|@''HAVE_MEMPCPY''@|0|g' -e 's|@''HAVE_DECL_MEMRCHR''@|1|g' -e
's|@''HAVE_STPCPY''@|1|g' -e 's|@''HAVE_STPNCPY''@|1|g' -e
's|@''HAVE_STRCASECMP''@|1|g' -e 's|@''HAVE_DECL_STRNCASECMP''@|1|g' -e
's|@''HAVE_STRCHRNUL''@|0|g' -e 's|@''HAVE_DECL_STRDUP''@|1|g' -e
's|@''HAVE_STRNDUP''@|1|g' -e 's|@''HAVE_DECL_STRNDUP''@|1|g' -e
's|@''HAVE_DECL_STRNLEN''@|1|g' -e 's|@''HAVE_STRPBRK''@|1|g' -e
's|@''HAVE_STRSEP''@|1|g' -e 's|@''HAVE_STRCASESTR''@|1|g' -e
's|@''HAVE_DECL_STRTOK_R''@|1|g' -e '/definition of GL_LINK_WARNING/r
../build-aux/link-warning.h' < ./string_.h; } > string.h-t
mv string.h-t string.h
../build-aux/install-sh -c -d sys
rm -f sys/stat.h-t sys/stat.h
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; sed -e
's/@''INCLUDE_NEXT''@/include_next/g' -e
's|@''NEXT_SYS_STAT_H''@|<sys/stat.h>|g' -e 's|@''HAVE_IO_H''@|0|g' -e
's|@''HAVE_LSTAT''@|1|g' -e 's|@''HAVE_DECL_MKDIR''@|1|g' < ./sys_stat_.h; }
> sys/stat.h-t
mv sys/stat.h-t sys/stat.h
rm -f unistd.h-t unistd.h
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; sed -e
's|@''HAVE_UNISTD_H''@|1|g' -e 's/@''INCLUDE_NEXT''@/include_next/g' -e
's|@''NEXT_UNISTD_H''@|<unistd.h>|g' -e 's|@''GNULIB_CHOWN''@|0|g' -e
's|@''GNULIB_DUP2''@|0|g' -e 's|@''GNULIB_FCHDIR''@|0|g' -e
's|@''GNULIB_FTRUNCATE''@|0|g' -e 's|@''GNULIB_GETCWD''@|0|g' -e
's|@''GNULIB_GETLOGIN_R''@|0|g' -e 's|@''GNULIB_LCHOWN''@|0|g' -e
's|@''GNULIB_LSEEK''@|0|g' -e 's|@''GNULIB_READLINK''@|0|g' -e
's|@''GNULIB_SLEEP''@|1|g' -e 's|@''HAVE_DUP2''@|1|g' -e
's|@''HAVE_FTRUNCATE''@|1|g' -e 's|@''HAVE_READLINK''@|1|g' -e
's|@''HAVE_SLEEP''@|1|g' -e 's|@''HAVE_DECL_GETLOGIN_R''@|1|g' -e
's|@''REPLACE_CHOWN''@|0|g' -e 's|@''REPLACE_FCHDIR''@|0|g' -e
's|@''REPLACE_GETCWD''@|0|g' -e 's|@''REPLACE_LCHOWN''@|0|g' -e
's|@''REPLACE_LSEEK''@|0|g' < ./unistd_.h; } > unistd.h-t
mv unistd.h-t unistd.h
make all-am
source='argp-ba.c' object='argp-ba.o' libtool=no DEPDIR=.deps
depmode=aix /bin/sh ../build-aux/depcomp cc -qlanglvl=ansi -DHAVE_CONFIG_H -I.
-I. -I.. -g -c argp-ba.c
source='argp-eexst.c' object='argp-eexst.o' libtool=no DEPDIR=.deps
depmode=aix /bin/sh ../build-aux/depcomp cc -qlanglvl=ansi -DHAVE_CONFIG_H -I.
-I. -I.. -g -c argp-eexst.c
"./stdio.h", line 31.2: 1506-218 (E) Unknown preprocessing directive
#include_next.
"./stdint.h", line 47.3: 1506-218 (E) Unknown preprocessing directive
#include_next.
"/usr/include/time.h", line 233.36: 1506-275 (S) Unexpected text 'struct'
encountered.
"/usr/include/time.h", line 233.52: 1506-275 (S) Unexpected text '*'
encountered.
"/usr/include/time.h", line 233.12: 1506-282 (S) The type of the parameters must
be specified in a prototype.
"/usr/include/time.h", line 234.37: 1506-275 (S) Unexpected text 'struct'
encountered.
"/usr/include/time.h", line 234.53: 1506-275 (S) Unexpected text '*'
encountered.
"/usr/include/time.h", line 234.12: 1506-282 (S) The type of the parameters must
be specified in a prototype.
"/usr/include/time.h", line 235.37: 1506-276 (S) Syntax error: possible missing
identifier?
"/usr/include/time.h", line 235.12: 1506-282 (S) The type of the parameters must
be specified in a prototype.
"/usr/include/time.h", line 236.49: 1506-275 (S) Unexpected text '*'
encountered.
"/usr/include/time.h", line 236.12: 1506-282 (S) The type of the parameters must
be specified in a prototype.
"/usr/include/time.h", line 241.36: 1506-276 (S) Syntax error: possible missing
identifier?
"/usr/include/time.h", line 241.12: 1506-282 (S) The type of the parameters must
be specified in a prototype.
"/usr/include/time.h", line 243.12: 1506-282 (S) The type of the parameters must
be specified in a prototype.
"/usr/include/time.h", line 244.35: 1506-275 (S) Unexpected text 'struct'
encountered.
"/usr/include/time.h", line 244.53: 1506-275 (S) Unexpected text '*'
encountered.
"/usr/include/time.h", line 244.12: 1506-282 (S) The type of the parameters must
be specified in a prototype.
"/usr/include/time.h", line 245.12: 1506-282 (S) The type of the parameters must
be specified in a prototype.
"/usr/include/time.h", line 246.35: 1506-276 (S) Syntax error: possible missing
identifier?
"/usr/include/time.h", line 246.86: 1506-335 (S) Parameter identifier list
contains multiple occurrences of itimerspec.
"/usr/include/time.h", line 246.12: 1506-282 (S) The type of the parameters must
be specified in a prototype.
"/usr/include/wchar.h", line 101.31: 1506-275 (S) Unexpected text '*'
encountered.
"/usr/include/wchar.h", line 101.47: 1506-276 (S) Syntax error: possible missing
identifier?
"/usr/include/wchar.h", line 101.17: 1506-282 (S) The type of the parameters
must be specified in a prototype.
"/usr/include/wchar.h", line 196.27: 1506-275 (S) Unexpected text '*'
encountered.
"/usr/include/wchar.h", line 196.15: 1506-282 (S) The type of the parameters
must be specified in a prototype.
"/usr/include/wchar.h", line 197.53: 1506-046 (S) Syntax error.
"/usr/include/wchar.h", line 197.72: 1506-046 (S) Syntax error.
"/usr/include/wchar.h", line 198.49: 1506-046 (S) Syntax error.
"/usr/include/wchar.h", line 198.68: 1506-046 (S) Syntax error.
"./stdlib.h", line 31.2: 1506-218 (E) Unknown preprocessing directive
#include_next.
"./unistd.h", line 23.3: 1506-218 (E) Unknown preprocessing directive
#include_next.
make: The error code from the last command is 1.

Stop.
make: The error code from the last command is 2.

Stop.
make: The error code from the last command is 1.

Stop.
make: The error code from the last command is 2.

Stop.

***

--

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

New GPLv3 release of GNU cflow

2007-06-29T11:11:41Z

Greetings,

As part of the releasing of version 3 of the GNU General Public
License, GNU cflow has been upgraded to the new license. The
release, which is a relicensed repackaging of version 1.1, is
available for downloading from ftp://ftp.gnu.org/gnu/cflow
and the mirror sites worldwide (see http://www.gnu.org/order/ftp.html
for the list of those).

The available files and their MD5 sums are:

860fc15fe9e9aaf42930af5191c518a7 cflow-1.2.tar.bz2
e0ef18aef99d1e7115b0b50d361ac6f7 cflow-1.2.tar.gz

For more information on GNU cflow including links to file downloads,
please visit http://www.gnu.org/software/cflow or the project
page http://savannah.gnu.org/projects/cflow.

Please email bugs or suggestions to <bug-cflow@...>.

Regards,
Sergey

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Running Cflow for C++ files

2007-04-08T07:32:30Z

Hi,

As part of my project for determining reuse levels in C and C++ projects, I need to find call graph for C as well C++ files. I wanted to know if cflow can be used for C++ files?

Thanks and regards,

Suvelee Sarpotdar

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

recursive includes

2007-03-23T07:05:51Z

Hi,

a segmentation fault occurs if there is a recursive include even if all
include files are instrumented with:

#ifndef foo.h
#define foo.h
[...]
#endif

OS: Windows XP Pro
Shell: Bash (Cygwin)
Call: cflow --cpp file.c

Errormessage:
14 [main] cflow 3420 _cygtls::handle_exceptions: Error while
dumping state (probably corrupted stack)
Segmentation fault (core dumped)

See also attached stackdump.

Do you need any more information? Feel free to contact me.

Best regards,
Marco Sorich

______________________________________________________________________________

Webasto AG
Sitz: Stockdorf
Handelsregister: Munchen HRB 80078
Vorsitzender des Aufsichtsrats: Werner Baier
Vorstandsmitglieder: Franz-Josef Kortum (Vorsitzender), Dr.-Ing. Helmut Leube, Phillip A. Thompson
______________________________________________________________________________

Webasto AG
Head Office: Stockdorf
Register of Companies: Munchen HRB 80078
Chairman of Supervisory Board: Werner Baier
Member of the Board: Franz-Josef Kortum (President), Dr.-Ing. Helmut Leube, Phillip A. Thompson
______________________________________________________________________________

_______________________________________________
bug-cflow mailing list
bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

cflow.exe.stackdump (1K) Download Attachment

Re: Bogus error message & cflow does not produce output

2006-11-26T05:43:33Z

Hi Bruce,

> cflow:jbodlogs.c:569: pr_start_time/-1 redefined
> cflow:jbodlogs.c:450: this is the place of previous definition

Have you tried preprocessing your input files? (command line option --cpp
or -I, see also
http://www.gnu.org/software/cflow/manual/html_node/Preprocessing.html#Preprocessing)

Regards,
Sergey

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Bogus error message & cflow does not produce output

2006-11-06T13:21:03Z

I got a mess of these:

cflow:jbodlogs.c:569: pr_start_time/-1 redefined
cflow:jbodlogs.c:450: this is the place of previous definition

It is complaining because static-local variables of the same
name are defined in multiple procedures. Do you have a mechanism
for saving information by an alias-name and aliasing these with
some prefix like __FUNCTION__:: ??

It had similar problems with inline stuff:

inline static int
pr_tableids_equal(pr_tableid *t1, pr_tableid *t2)
{
return ((t1->nid == t2->nid) && (t1->incn == t2->incn) &&
(t1->id == t2->id));
}

I am guessing that these problems suppressed any output. :(

Also, a minor complaint about initialization: the order of
environment variables before config files is wrong. Since
environment variables are easier to manipulate, they should
take precedence over config files. There should also be a
more obvious way to suppress config file loading than
export CFLOWRC=/dev/null

Thanks -Bruce

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: Documentation bug and help

2006-09-20T06:36:24Z

Miguel Angel Cabrera <mad_aluche@...> wrote:

> http://www.gnu.org/software/cflow/manual/cflow.html#Makefiles
>
> there is a missing '@' in this line "cflow -o$ $(CFLOW_FLAGS) $(DEFS) \"

Yes, indeed. Thanks for noticing.

> by the way, could you explain a bit more cflow with Makefiles?

No problem. What part exactly do you need to be explained?

Regards,
Sergey

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Documentation bug and help

2006-09-19T13:25:50Z

Hi,

i think there is a bug in documentation, in this section

http://www.gnu.org/software/cflow/manual/cflow.html#Makefiles

there is a missing '@' in this line "cflow -o$ $(CFLOW_FLAGS) $(DEFS) \"

by the way, could you explain a bit more cflow with Makefiles?

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: cflow-1.1 doesn't find main

2006-09-11T14:14:51Z

Sergey Poznyakoff <gray@...> wrote:

> Right from the top of my head I'd
> propose an option telling cflow to display only those symbols
> that are defined anywhere in the sources it is given in the command
> line. Will such an option help?

As a test implementation of this thought, please try the enclosed
patch. It adds the new symbol class 'u', which stands for 'undefined
symbols'. Running `cflow -i^u' will omit from the output all symbols,
not defined in the sources.

Regards,
Sergey

Index: src/main.c
===================================================================
RCS file: /cvsroot/cflow/cflow/src/main.c,v
retrieving revision 1.38
diff -p -u -r1.38 main.c
--- src/main.c 11 Sep 2006 18:28:51 -0000 1.38
+++ src/main.c 11 Sep 2006 20:11:05 -0000
@@ -214,11 +214,13 @@ int omit_symbol_names_option; /* Omit sy
#define SM_STATIC 0x0004
#define SM_UNDERSCORE 0x0008
#define SM_TYPEDEF 0x0010
+#define SM_UNDEFINED 0x0020

#define CHAR_TO_SM(c) ((c)=='x' ? SM_DATA : \
(c)=='_' ? SM_UNDERSCORE : \
(c)=='s' ? SM_STATIC : \
- (c)=='t' ? SM_TYPEDEF : 0)
+ (c)=='t' ? SM_TYPEDEF : \
+ (c)=='u' ? SM_UNDEFINED : 0)
#define SYMBOL_INCLUDE(c) (symbol_map |= CHAR_TO_SM(c))
#define SYMBOL_EXCLUDE(c) (symbol_map &= ~CHAR_TO_SM(c))
int symbol_map; /* A bitmap of symbols included in the graph. */
@@ -593,6 +595,7 @@ parse_opt (int key, char *arg, struct ar
case '_':
case 's':
case 't':
+ case 'u':
if (num)
SYMBOL_INCLUDE(*arg);
else
@@ -710,6 +713,10 @@ include_symbol(Symbol *sym)
type |= SM_DATA;
else if (sym->arity >= 0)
type |= SM_FUNCTIONS;
+
+ if (!sym->source)
+ type |= SM_UNDEFINED;
+
} else if (sym->type == SymToken) {
if (sym->token_type == TYPE && sym->source)
type |= SM_TYPEDEF;
@@ -755,7 +762,7 @@ main(int argc, char **argv)
register_output("gnu", gnu_output_handler, NULL);
register_output("posix", posix_output_handler, NULL);

- symbol_map = SM_FUNCTIONS|SM_STATIC;
+ symbol_map = SM_FUNCTIONS|SM_STATIC|SM_UNDEFINED;

if (getenv("POSIXLY_CORRECT")) {
if (select_output_driver("posix"))

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: cflow-1.1 doesn't find main

2006-09-11T12:58:53Z

Robert E. Michael <rmichael2@...> wrote:

> I did notice that the printed error message now has the long
> (i.e., full path) invocation name, rather than the short name
> one usually expects. But perhaps that is what is expected of
> gnu tools.

Yes, the general principle is: the tool identifies itself with the name
under which it was invoked. Compare (on GNU system):

$ mv foobar x
mv: cannot stat `foobar': No such file or directory
$ /usr/bin/mv foobar x
/usr/bin/mv: cannot stat `foobar': No such file or directory

> it would be of great help if I had a convenient way to suppress the
> common library routines such as "strchr" (and its relatives), and
> maybe even some common IO routines line "fprintf". That way
> I can concentrate on the unique structure of that system, instead
> of being bogged down by having to scan past lots of function
> names which do not help me understand the new system.

Aha, yes, I see. Currently there is no easy way to achieve this, but it
should not be hard to implement. Right from the top of my head I'd
propose an option telling cflow to display only those symbols
that are defined anywhere in the sources it is given in the command
line. Will such an option help?

Regards,
Sergey

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: cflow-1.1 doesn't find main

2006-09-11T12:26:13Z

Sergey,

Reinstalling the patches to parser.c and symbol.c does seem
to fix the segmentation fault.
I did notice that the printed error message now has the long
(i.e., full path) invocation name, rather than the short name
one usually expects. But perhaps that is what is expected of
gnu tools.

I have read the documentation you pointed me to because I
am looking for a way to exclude certain functions from cflow
listings. In particular, for a large system that I am trying to learn,
it would be of great help if I had a convenient way to suppress the
common library routines such as "strchr" (and its relatives), and
maybe even some common IO routines line "fprintf". That way
I can concentrate on the unique structure of that system, instead
of being bogged down by having to scan past lots of function
names which do not help me understand the new system. I read about
the --include=spec command line switch, but it doesn't look like
that really does what I want. Is there a way?

Bob Michael

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: cflow-1.1 doesn't find main

2006-09-11T11:34:29Z

Sergey,
The alpha 20060910 works a little better in that it prints error
messages without me having to supply a --program-name. But
it still gets a segmentation fault on the c.c file. The fault is at line
276 in output.c. The value of sym is 0x318, and trying to print
sym->type gets a message from gdb "cannot access memory at
address 0x31c.
I did a compare of all the files in the src directory and found that
the patches you previously sent for symbol.c and parser.c are not
present in the alpha source. I will try putting them back in and see
if that fixes everything.

Bob Michael

Sergey Poznyakoff wrote:

> Robert E. Michael <rmichael2@...> wrote:
>
> > So program_invocation_name is defined, but it is set to NULL,
>
> Yes, you are right. Please try the following snapshot:
>
> ftp://download.gnu.org.ua/pub/alpha/cflow/cflow-1.1-20060910.tar.bz2
>
> Regards,
> Sergey
>

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: cflow-1.1 doesn't find main

2006-09-10T04:40:44Z

Robert E. Michael <rmichael2@...> wrote:

> So program_invocation_name is defined, but it is set to NULL,

Yes, you are right. Please try the following snapshot:

ftp://download.gnu.org.ua/pub/alpha/cflow/cflow-1.1-20060910.tar.bz2

Regards,
Sergey

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: cflow-1.1 doesn't find main

2006-09-09T13:37:59Z

Sergey,

#define program_name program_invocation_name
is already in my config.h file. That is why when I stop at line 275
and try to print program_name, gdb replies:
No symbol "program_name" in current context
But when I print program_invocation_name, gdb replies:
$10 = 0x0
So program_invocation_name is defined, but it is set to NULL,
rather than the actual program name or the value of argv[0].
So, no, it does not fix the core dump from cflow. In fact, as far
as I can tell (in argp-parse.c line 947), program_invocation_name
is only set if I set it when I execute cflow, as in:
cflow --program-name cflow c.c
That works, and I get the name I supply printed in the error
messages.

There is another curiosity that I am having trouble explaining.
In the nohup output from ./configure --enable-debug, I find the
following statements:
checking whether program_invocation_name is declared... no
checking whether program_invocation_short_name is declared... no
But in the config.h file,
HAVE_DECL_PROGRAM_INVOCATION_NAME is defined to 1,
while HAVE_DECL_PROGRAM_INVOCATION_SHORT_NAME
is defined to 0. When I write a two line program that has the statements:
extern char *program_invocation_name;
printf(%s\n",program_invocation_name);
and compile it with gcc, the linker complains that
"program_invocation_name is undefined. Thus the output from the
configure script is correct, but the config.h variable
HAVE_DECL_PROGRAM_INVOCATION_NAME is set anyway.
Perhaps that is because program_invocation_name is always defined
in pin.c. But shouldn't there be some code somewhere that sets
program_invocation_name to the contents of argv[0]? Otherwise,
a user who does not supply a command line --program-name,
and whose C file or files has an error will get a core dump rather
than an error message. There is some code in argp-parse.c between
lines 556 and 569 that tries to look at argv[0], but it does not set
program_invocation_name. Instead it sets parser->state.name,
which is not used anywhere. And there is a comment around line
1689 in argp-help.c that suggests that something is broken in
this whole mess about getting a printable program name. Since
always including the variable "program_invocation_name" is
already a kludge, then its definition in pin.c should be:
char *program_invocation_name = "cflow";
That way, error messages will not cause a segmentation fault,
and the user can still supply a program name with the command
line --program-name option.

Bob Michael

Sergey Poznyakoff wrote:

> Robert E. Michael <rmichael2@...> wrote:
>
> > So there
> > seems to be something wrong with the definition of _LIBC, such
> > that it allows the alias of program_name to program_invocation_name,
> > but somehow program_invocation_name is never set.
>
> In fact, _LIBC is never defined, so this part of code is not
> compiled. What happens is that program_invocation_name *is* set
> (lib/argp-pin.c), whereas program_name is not. The define you are
> talking about was designed to compensate for it in case of glibc code,
> but it has no force otherwise. That is why placing `#define
> program_name program_invocation_name' in your config.h should fix it.
> Actually, that should have been done by configure, but somehow I
> forgotten to make it there:)
>
> > If I place "if (program_name != NULL)" before line 275 and
> > recompile, then cflow runs and generates dozens of "redefined"
> > error messages. I am not sure I understand enough about the
> > details of how cflow handles compiler variables like __STDC__
> > and __cplusplus.
>
> Yes, this is described in detail in the documentation (chapter 8,
> "Running Preprocessor". The online copy available at
> http://www.gnu.org/software/cflow/manual). Run it with preprocessor and
> the messages will go away. E.g.:
>
> $ cd cflow-1.1/src
> $ cflow -I.. -I. c.c
>
> Regards,
> Sergey
>

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: cflow-1.1 doesn't find main

2006-09-08T21:51:49Z

Robert E. Michael <rmichael2@...> wrote:

> So there
> seems to be something wrong with the definition of _LIBC, such
> that it allows the alias of program_name to program_invocation_name,
> but somehow program_invocation_name is never set.

In fact, _LIBC is never defined, so this part of code is not
compiled. What happens is that program_invocation_name *is* set
(lib/argp-pin.c), whereas program_name is not. The define you are
talking about was designed to compensate for it in case of glibc code,
but it has no force otherwise. That is why placing `#define
program_name program_invocation_name' in your config.h should fix it.
Actually, that should have been done by configure, but somehow I
forgotten to make it there:)

> If I place "if (program_name != NULL)" before line 275 and
> recompile, then cflow runs and generates dozens of "redefined"
> error messages. I am not sure I understand enough about the
> details of how cflow handles compiler variables like __STDC__
> and __cplusplus.

Yes, this is described in detail in the documentation (chapter 8,
"Running Preprocessor". The online copy available at
http://www.gnu.org/software/cflow/manual). Run it with preprocessor and
the messages will go away. E.g.:

$ cd cflow-1.1/src
$ cflow -I.. -I. c.c

Regards,
Sergey

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow

Re: cflow-1.1 doesn't find main

2006-09-08T21:39:40Z

Robert E. Michael <rmichael2@...> wrote:

> The output you requested is in the attached file.

Thank you. Please add the following line to your config.h:

#define program_name program_invocation_name

and recompile the program. Does it fix the problem?

Regards,
Sergey

_______________________________________________
Bug-cflow mailing list
Bug-cflow@...
http://lists.gnu.org/mailman/listinfo/bug-cflow