On Wed, 19 Feb 2003, John Levon wrote:
> > ../../../lyx-1.3.0/boost/boost/shared_ptr.hpp:203:
> > template instantiation depth exceeds maximum of 17
> >
> > It seems that somewhere there is a C++ construct misunderstood by
> > gcc-2.95.3, or do you really need more than 17 template instantiation
> > levels? If so please note (quoted from gcc-info, gcc-3.2):
>
> We do. The other gcc versions define this already.
Hi John,
thanks for the prompt reply.
So you do need more than 17 template instantiation levels. If gcc-2.95.x is
known to have a default limit of 17, wouldn't it then be good to add an
apropriate compiler option for gcc2 (probably after some suitable tests in
configure). I know that's somewhat tricky to do, but should be worth it.
Or at least have a note in a prominent place stating what option is needed.
After all README says:
* A good c++ compiler. Development is being done mainly on
gcc/g++, but some others work. As of LyX 1.3.0, you need at
least gcc 2.95.X (or egcs 1.1.x). ..........
and INSTALL says:
First of all, you will also need a recent C++ compiler, where recent
means that the compilers are close to C++ standard conforming.
Compilers that are known to compile LyX are egcs 1.1.x, gcc 2.95.x and
later, ...........
BTW: What value for NN in -ftemplate-depth-NN is needed for gcc-2.95.3?
And what about "ANSI/ISO ++ conforming programs must not rely on a maximum
depth greater than 17" (quoted from gcc.info for gcc-3.2)? Is this piece of
information obsolete?
> > Adding '#define HAVE_STRERROR 1' by hand in the 'src/config.h' generated by
> > configure did the job. Please FIX your configure and config.h.in
> > accordingly.
>
> It has already been fixed.
Very good.
> > It seems that the detection of libflimage in configre is broken. Please FIX
>
> It works for me.
I get in config.log (with gcc-3.2, gcc-2.95.3 gives essentially the same):
..................
configure:11200: checking for forms.h
configure:11207: result: yes
configure:11235: checking xforms header version
configure:11256: result: 1.0.0
configure:11299: checking for flimage.h
configure:11312: gcc -c -O2 -isystem /usr/X11R6/include conftest.c >&5
configure:11315: $? = 0
configure:11318: test -s conftest.o
configure:11321: $? = 0
configure:11331: result: yes
configure:11342: checking for library containing flimage_dup
configure:11375: gcc -o conftest -O2 -isystem /usr/X11R6/include conftest.c
-lforms -lXpm -lSM -lICE -lc -lm
-L/usr/X11R6/lib -lX11 >&5
/tmp/ccyCgimh.o: In function `main':
/tmp/ccyCgimh.o(.text+0x9): undefined reference to `flimage_dup'
collect2: ld returned 1 exit status
configure:11378: $? = 1
configure: failed program was:
#line 11349 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern "C"
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char flimage_dup ();
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
flimage_dup ();
;
return 0;
}
configure:11421: gcc -o conftest -O2 -isystem /usr/X11R6/include conftest.c
-lflimage -lforms -lXpm -lSM -lICE -lc -lm
-L/usr/X11R6/lib -lX11 >&5
/usr/local/lib/libflimage.so: undefined reference to `jpeg_read_scanlines'
...................
/usr/local/lib/libflimage.so: undefined reference to `jpeg_write_scanlines'
collect2: ld returned 1 exit status
configure:11424: $? = 1
configure: failed program was:
#line 11395 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. */
#ifdef __cplusplus
extern "C"
#endif
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char flimage_dup ();
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
flimage_dup ();
;
return 0;
}
configure:11443: result: no
configure:11454: checking for jpeg_read_header in -ljpeg
...............
The first test fails because flimage_dup is not in libforms; OK. The second
test (with -lflimage -lforms) fails, because libflimage needs libjpeg but
that is not coded into libflimage. (Of course, our shared libflimage could
have that info but isn't built that way, however static libs never contain
such info.)
IMHO the tests for libforms/libflimage should come AFTER those for libjpeg!
regards
Peter
