[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GLR and strdup (Was: [GNU Bison 1.75a] testsuite: 89 90 91 92 93 94 95
GLR and strdup (Was: [GNU Bison 1.75a] testsuite: 89 90 91 92 93 94 95 96 97 failed)
24 Oct 2002 13:32:45 +0200
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)
| As per your request. This is on dec-mips-ultrix. Do you want me to try
| other platforms here?
Well, beta testers are always extremely appreciated :)
| BTW: The strdup() problem is very common on Ultrix. It's fixably by simply
| linking against libiberty. So probably nothing to worry about in general.
That's my feeling too.
| 89. cxx-type.at:226: testing GLR: Resolve ambiguity, impure, no locations...
| cxx-type.at:227: bison -o types.c types.y
| types.y: warning: 1 reduce/reduce conflict
| cxx-type.at:227: $CC $CFLAGS $CPPFLAGS types.c -o types
| types.y: In function `yylex':
| types.y:99: warning: assignment makes pointer from integer without a cast
| /usr/tmp/ccSNtKkR.o: In function `yylex':
undefined reference to `strdup'
| collect2: ld returned 1 exit status
| cxx-type.at:227: exit code was 1, expected 0
| 89. cxx-type.at:226: FAILED near `cxx-type.at:227'
I tend to think that we should not pollute the other skeletons (i.e.,
the others than yacc.c) with such portability issues. In other words,
I would suggest that the test suite itself provide the portability
glue, not the skeleton.
But if other people think the converse, let's make glr.c more
portable; but in this case, I would suggest that we go to an Autoconf
# include <config.h>
# define HAVE_STRDUP 0
# define strdup my_strdup
Re: GLR and strdup (Was: [GNU Bison 1.75a] testsuite: 89 90 91 92 93 94 95 96 97 failed), Paul Eggert, 2002/10/25