bug-gnubatch
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnubatch] GNU Batch Fails To Build


From: address@hidden
Subject: Re: [bug-gnubatch] GNU Batch Fails To Build
Date: Tue, 5 May 2015 13:52:51 -0700
User-agent: Mutt/1.5.22 (2013-10-16)

Hi,
Thanks for responding.

I actually found this exact error from 2011 so I think it's pretty
well established on Red Hat style distros. 

http://lists.gnu.org/archive/html/help-gnubatch/2011-09/msg00009.html

I did not, however, see any practical ways to fix the problem. Only a
mention of perhaps I don't have lex or bison installed.

--------------------------------------------------------------
:->[myhost][/tmp]$ bison --version
bison (GNU Bison) 2.4.1
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
:->[myhost][/tmp]$ lex --version
lex 2.5.35
--------------------------------------------------------------

If I was using some kind of OS/distro that is not commonly used for
clusters, I'd maybe not worry about it. (By the way, can anyone
recommend a build environment that does reliably compile?) 
But I would really like to get this working.

On Mon, May 04, 2015 at 11:11:55PM +0000, Smith, Ron D - Exelis wrote:
> FWIW, I tried to find '\bline_count\b' in the source code, and it is in 
> util/msglex.l.
> 
> >grep --recursive -P '\bline_count\b' .
> ./util/msgparse.y:extern        int     line_count;
> ./util/msgparse.y:      fprintf(stderr, "Parse error: %s on line %d\n", msg, 
> line_count);
> ./util/msgparse.y:                      int  lc = line_count;
> ./util/msgparse.y:                      while  (line_count == lc);
> ./util/msgparse.y:                              fprintf(stderr, "Unknown help 
> file %s on line %d\n", $1, line_count);
> ./util/alloc.c:extern   int             errors, line_count;
> ./util/alloc.c:                 fprintf(stderr, "Undefined name %s near line 
> %d\n", ve->val_un.val_name->vn_string, line_count);
> ./util/alloc.c:                 fprintf(stderr, "Macro %s is redefined line 
> %d\n", name, line_count);
> ./util/helpparse.c:extern       int     errors, line_count, pass1;
> ./util/helpparse.c:             fprintf(stderr, "Help text definition at line 
> %d not used anywhere: ", line_count);
> ./util/helpparse.c:     line_count = 1;
> ./util/msglex.l:int     line_count = 1;
> ./util/msglex.l:\n                      line_count++;
> ./util/msglex.l:                                int     start_line = 
> line_count;
> ./util/msglex.l:                                                line_count++;
> ./util/msglex.l:                                                        
> line_count++;
> ./util/msglex.l:                                                              
>  line_count, start_line);
> ./util/msglex.l:                                                              
>   line_count++;
> ./util/msglex.l:                                int     start_line = 
> line_count;
> ./util/msglex.l:                                                line_count++;
> ./util/msglex.l:                                                        
> line_count++;
> ./util/msglex.l:                                                              
>  line_count, start_line);
> ./util/msglex.l:                                                              
>   line_count++;
> ./util/msglex.l:                        fprintf(stderr, "Had a \'%c\' on line 
> %d\n", yytext[0], line_count);
> Binary file ./util/helpparse.o matches
> Binary file ./util/msgparse.o matches
> Binary file ./util/msglex.o matches
> Binary file ./util/alloc.o matches
> Binary file ./util/helpparse matches
> 
> However your log seems to be missing a lot of information because
> right after "make", it goes directly into linking for helpparse,
> without building the source code.
Is there an output I could provide that would be helpful? The full
output of ./configure too? (I put that here: http://pastebin.com/pWMudsTt ) 

> If you start with a clean tarball,
> what is the entire log?

As far as working from a clean slate here is exactly what I did and
what happened. (The configure output is as mentioned.)

--------------------------------------------------------------
:->[myhost][~/gnubatch/gnubatch-1.11]$ make
cd util;make all
make[1]: Entering directory `/cfs/xed/gnubatch/gnubatch-1.11/util'
gcc -O -g -Wall -fno-stack-protector  -I.. -I../src/hdrs   -c -o helpparse.o 
helpparse.c
bison -y -d msgparse.y
mv -f y.tab.c msgparse.c
gcc -O -g -Wall -fno-stack-protector  -I.. -I../src/hdrs   -c -o msgparse.o 
msgparse.c
flex  -t msglex.l > msglex.c
gcc -O -g -Wall -fno-stack-protector  -I.. -I../src/hdrs   -c -o msglex.o 
msglex.c
gcc -O -g -Wall -fno-stack-protector  -I.. -I../src/hdrs   -c -o alloc.o alloc.c
gcc  -o helpparse helpparse.o msgparse.o msglex.o alloc.o
msglex.o: In function `input':
/cfs/xed/gnubatch/gnubatch-1.11/util/<stdout>:1411: undefined reference to 
`yywrap'
msglex.o: In function `yylex':
/cfs/xed/gnubatch/gnubatch-1.11/util/<stdout>:1076: undefined reference to 
`yywrap'
collect2: ld returned 1 exit status
make[1]: *** [helpparse] Error 1
rm msglex.c msgparse.c
make[1]: Leaving directory `/cfs/xed/gnubatch/gnubatch-1.11/util'
make: *** [utild] Error 2
:-<[myhost][~/gnubatch/gnubatch-1.11]$ history 5
  671  tar -xvzf gnubatch-1.11.tar.gz
  672  cd gnubatch-1.11
  673  ./configure
  674  make
  675  history 5
--------------------------------------------------------------

> If you look at the symbol table for msglex.o does it have an extern
> for line_count?
I'm not sure but maybe this helps.

--------------------------------------------------------------
:->[myhost][~/gnubatch/gnubatch-1.11]$ nm util/msglex.o | grep line_count
0000000000000004 D line_count
--------------------------------------------------------------

I very much appreciate any help with this as I would love to see
GNUBatch become a viable alternative for clusters based on Red Hat,
CentOS, Scientific Linux, Rocks, et al. If there is any information I
could provide that would be helpful, please let me know.
Thanks again,
Chris

-- 
++++++++++[>++++++++++++<-]>-...<++++++[>>+++++++<<-]>>++++.<+.<++++[>
Chris X Edwards-----<-]>+.- Have a nice day. >.<-.+++++><chris AT xed.ch>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]