Re: What Magic Compiler Is Needed for LyX?
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> | Sorry John, but andreas is right. Here is what the GNU Lars> standards | texinfo file has to say Lars> Why is the GNU standards texinfo file really appropriate in this Lars> case? I really hope that document then also talks about autoconf Lars> and automake. Actually, it is the autoconf docs that points to standards.texi, which itself points to make-stds.texi (both are bundled with autoconf). Anyway, I think this is a perfectly reasonable convention. JMarc
Re: What Magic Compiler Is Needed for LyX?
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "John" == John Levon <[EMAIL PROTECTED]> writes: | | John> On Fri, Feb 07, 2003 at 12:30:12PM -0600, Andreas Pour wrote: | >> For SuSE 8.0, the compile is broken if you set CXXFLAGS in your | >> env. This is | | John> IF you're fiddling with CXXFLAGS you should know what you're | John> doing. | | Sorry John, but andreas is right. Here is what the GNU standards | texinfo file has to say Why is the GNU standards texinfo file really appropriate in this case? I really hope that document then also talks about autoconf and automake. | If there are C compiler options that *must* be used for proper |compilation of certain files, do not include them in `CFLAGS'. Users |expect to be able to specify `CFLAGS' freely themselves. Instead, |arrange to pass the necessary options to the C compiler independently |of `CFLAGS', by writing them explicitly in the compilation commands or |by defining an implicit rule, like this: | | CFLAGS = -g | ALL_CFLAGS = -I. $(CFLAGS) | .c.o: | $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $< | | Do include the `-g' option in `CFLAGS', because that is not |*required* for proper compilation. You can consider it a default that |is only recommended. If the package is set up so that it is compiled |with GCC by default, then you might as well include `-O' in the default |value of `CFLAGS' as well. | | And I think this completely makes sense. I don't know what other | variable we could use for this, though. I have a solution... but I guess you will find it fragile again... :-) -- Lgb
Re: What Magic Compiler Is Needed for LyX?
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> On Fri, Feb 07, 2003 at 12:30:12PM -0600, Andreas Pour wrote: >> For SuSE 8.0, the compile is broken if you set CXXFLAGS in your >> env. This is John> IF you're fiddling with CXXFLAGS you should know what you're John> doing. Sorry John, but andreas is right. Here is what the GNU standards texinfo file has to say If there are C compiler options that *must* be used for proper compilation of certain files, do not include them in `CFLAGS'. Users expect to be able to specify `CFLAGS' freely themselves. Instead, arrange to pass the necessary options to the C compiler independently of `CFLAGS', by writing them explicitly in the compilation commands or by defining an implicit rule, like this: CFLAGS = -g ALL_CFLAGS = -I. $(CFLAGS) .c.o: $(CC) -c $(CPPFLAGS) $(ALL_CFLAGS) $< Do include the `-g' option in `CFLAGS', because that is not *required* for proper compilation. You can consider it a default that is only recommended. If the package is set up so that it is compiled with GCC by default, then you might as well include `-O' in the default value of `CFLAGS' as well. And I think this completely makes sense. I don't know what other variable we could use for this, though. JMarc
Re: What Magic Compiler Is Needed for LyX?
> On Fri, Feb 07, 2003 at 12:30:12PM -0600, Andreas Pour wrote: > > > For SuSE 8.0, the compile is broken if you set CXXFLAGS in your env. This is > > IF you're fiddling with CXXFLAGS you should know what you're doing. Hi, As it happens I know what I am doing, and hence I know that I should not have to read Makefiles to divine needed but obscure compile flags. If you do not care to document your project fully or have your build system comply with standards, that is your perogative, of course, but I would suggest that belittling those who try to help the project is not productive for anyone. [ ... ] Ciao, Dre
Re: What Magic Compiler Is Needed for LyX?
On Fri, Feb 07, 2003 at 12:30:12PM -0600, Andreas Pour wrote: > For SuSE 8.0, the compile is broken if you set CXXFLAGS in your env. This is IF you're fiddling with CXXFLAGS you should know what you're doing. > For Mandrake 9.0 and RH 8.0, the problem is that you need to add > "-DHAVE_STRERROR" to the compile flags, both systems include strerror() in Fixed already. john
Re: What Magic Compiler Is Needed for LyX?
Hi, Thanks for the various responses. I have now managed to compile LyX on SuSE 8.0 and Mandrake 9.0 (I assume RH 8.0 will also now compile and I guess SuSE 8.1 needs a compiler upgrade). The problems appear to be in the build system, and/or lack of documenation in the INSTALL files to work around these problems. For SuSE 8.0, the compile is broken if you set CXXFLAGS in your env. This is the proper way for someone compiling to set the proper compile flags and hence setting this to typical values should not break a compile. If you use an unusual option, such as '-ftemplate-depth-30', I suggest you get it into the CXXFLAGS some other way (by appending it to the CXXFLAGS in the Makefile.am, for example), or make it clear in the documentation this option needs to be specifically included. For Mandrake 9.0 and RH 8.0, the problem is that you need to add "-DHAVE_STRERROR" to the compile flags, both systems include strerror() in /usr/include/string.h. For some reason the build system does not add it based on the configure values (it stems from configure.ac). Not sure how to fix it, I am far from an autoconf guru, but at least I can report the problem :-). Hope this is helpful, Dre Jean-Marc Lasgouttes wrote: > > > "Andreas" == Andreas Pour <[EMAIL PROTECTED]> writes: > > Andreas> Hi, > > Andreas> g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost > Andreas> -isystem /usr/X11R6/include -O2 -march=i386 -mcpu=i386 > Andreas> -DNDEBUG -O2 -march=i386 -mcpu=i386 -D_GNU_SOURCE -DNDEBUG > Andreas> -DNO_DEBUG -D_REENTRANT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT > Andreas> -pipe -c insetbib.C -Wp,-MD,.deps/insetbib.TPlo > Andreas> ../../boost/boost/shared_ptr.hpp:203: template instantiation > Andreas> depth exceeds maximum of 17 > > How did you do the compilation? It is not LyX that adds the > -march=i386 -mcpu=i386 thingies, as far as I know... > > OTOH, LyX does add to CXXFLAGS options like -ftemplate-depth-30 that > would avoid this error. > > JMarc
Re: What Magic Compiler Is Needed for LyX?
> "Andreas" == Andreas Pour <[EMAIL PROTECTED]> writes: Andreas> Hi, Andreas> g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost Andreas> -isystem /usr/X11R6/include -O2 -march=i386 -mcpu=i386 Andreas> -DNDEBUG -O2 -march=i386 -mcpu=i386 -D_GNU_SOURCE -DNDEBUG Andreas> -DNO_DEBUG -D_REENTRANT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT Andreas> -pipe -c insetbib.C -Wp,-MD,.deps/insetbib.TPlo Andreas> ../../boost/boost/shared_ptr.hpp:203: template instantiation Andreas> depth exceeds maximum of 17 How did you do the compilation? It is not LyX that adds the -march=i386 -mcpu=i386 thingies, as far as I know... OTOH, LyX does add to CXXFLAGS options like -ftemplate-depth-30 that would avoid this error. JMarc
Re: What Magic Compiler Is Needed for LyX?
On Thu, Feb 06, 2003 at 10:42:35PM -0600, Andreas Pour wrote: > What compiler is recommended, BTW? 2.95.3 works. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: What Magic Compiler Is Needed for LyX?
On Fri, Feb 07, 2003 at 08:20:06AM +0100, Moritz Moeller-Herrmann wrote: > The lyx developers are aware of the fact, that their code is too good for > any shipped compiler This is not even close to being true... john
Re: What Magic Compiler Is Needed for LyX?
2.95.4 works for me on Debian. If you're using QT, make sure that it was compiled with the same version compiler as you're trying to compile lyx with. On Fri, 7 Feb 2003, Georg Baum wrote: > > Unfortunately > > for me > > compilation failed on the three major Linux commercial > > distros with > > the attached > > logs: > > > > * SuSE 8.0: gcc2.95.3.log > > * SuSE 8.1: gcc3.2-suse81.log > > I had the same problem with this compiler. The > internal compiler error is introduced by one of the > patches SuSE applied, search the gcc bug database > for boost if you want to know more. > > Use gcc 3.2 fom FSF, that one is reported to work. > > Georg > > > > _ rod | "Beneath the waves, the waves / That's where I will be / | I'm going to see the cow beneath the sea." | They Might Be Giants, Lincoln
Re: What Magic Compiler Is Needed for LyX?
> Unfortunately > for me > compilation failed on the three major Linux commercial > distros with > the attached > logs: > > * SuSE 8.0: gcc2.95.3.log > * SuSE 8.1: gcc3.2-suse81.log I had the same problem with this compiler. The internal compiler error is introduced by one of the patches SuSE applied, search the gcc bug database for boost if you want to know more. Use gcc 3.2 fom FSF, that one is reported to work. Georg
Re: What Magic Compiler Is Needed for LyX?
Andreas Pour wrote: > > Hi, > > Congrats on the release and porting LyX to Qt :-). Unfortunately for me > compilation failed on the three major Linux commercial distros with the > attached logs: > > * SuSE 8.0: gcc2.95.3.log > * SuSE 8.1: gcc3.2-suse81.log > * Mandrake 9.0 / RedHat 8.0: gcc3.2-mand90-rh80.log > > What compiler is recommended, BTW? For SuSE-8.1 you can find a fixed compiler in ftp://ftp.gwdg.de/linux/suse/ftp.suse.com/projects/gcc/8.1 The lyx developers are aware of the fact, that their code is too good for any shipped compiler, but decided to have correct rather than easily compilable code. -- Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. (ANATOLE FRANCE)
What Magic Compiler Is Needed for LyX?
Hi, Congrats on the release and porting LyX to Qt :-). Unfortunately for me compilation failed on the three major Linux commercial distros with the attached logs: * SuSE 8.0: gcc2.95.3.log * SuSE 8.1: gcc3.2-suse81.log * Mandrake 9.0 / RedHat 8.0: gcc3.2-mand90-rh80.log What compiler is recommended, BTW? Ciao, Dre Making all in insets make[3]: Entering directory `/usr/src/packages/BUILD/lyx-1.3.0/src/insets' source='insetbib.C' object='insetbib.lo' libtool=yes \ depfile='.deps/insetbib.Plo' tmpdepfile='.deps/insetbib.TPlo' \ depmode=gcc /bin/sh ../../config/depcomp \ /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -isystem /usr/X11R6/include -O2 -march=i386 -mcpu=i386 -DNDEBUG -O2 -march=i386 -mcpu=i386 -D_GNU_SOURCE -DNDEBUG -DNO_DEBUG -D_REENTRANT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -pipe -c -o insetbib.lo `test -f 'insetbib.C' || echo './'`insetbib.C g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -isystem /usr/X11R6/include -O2 -march=i386 -mcpu=i386 -DNDEBUG -O2 -march=i386 -mcpu=i386 -D_GNU_SOURCE -DNDEBUG -DNO_DEBUG -D_REENTRANT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -pipe -c insetbib.C -Wp,-MD,.deps/insetbib.TPlo ../../boost/boost/shared_ptr.hpp:203: template instantiation depth exceeds maximum of 17 ../../boost/boost/shared_ptr.hpp:203: (use -ftemplate-depth-NN to increase the maximum) ../../boost/boost/shared_ptr.hpp:203: instantiating `boost::detail::shared_ptr_traits >' ../../boost/boost/shared_ptr.hpp:203: instantiated from `boost::shared_ptr >' ../../boost/boost/signals/detail/slot_call_iterator.hpp:42: instantiated from `boost::signals::detail::slot_call_policies::caller > >,_Rb_tree_iterator,pair &,pair *> >' ../../boost/boost/type_traits/is_convertible.hpp:124: instantiated from `boost::detail::is_convertible_impl::caller > >,_Rb_tree_iterator,pair &,pair *> > &,boost::detail::int_convertible>' ../../boost/boost/type_traits/is_enum.hpp:91: instantiated from `boost::is_convertible::caller > >,_Rb_tree_iterator,pair &,pair *> > &,boost::detail::int_convertible>' ../../boost/boost/type_traits/is_enum.hpp:91: instantiated from `boost::detail::is_enum_helper::type::caller > >,_Rb_tree_iterator,pair &,pair *> > &>' ../../boost/boost/type_traits/is_enum.hpp:91: instantiated from `boost::detail::is_enum_impl::caller > >,_Rb_tree_iterator,pair &,pair *> > >' ../../boost/boost/type_traits/is_scalar.hpp:36: instantiated from `boost::is_enum::caller > >,_Rb_tree_iterator,pair &,pair *> > >' ../../boost/boost/type_traits/is_scalar.hpp:36: instantiated from `boost::detail::is_scalar_impl::caller > >,_Rb_tree_iterator,pair &,pair *> > >' ../../boost/boost/type_traits/is_class.hpp:73: instantiated from `boost::is_scalar::caller > >,_Rb_tree_iterator,pair &,pair *> > >' ../../boost/boost/type_traits/is_class.hpp:73: instantiated from `boost::detail::is_class_impl::caller > >,_Rb_tree_iterator,pair &,pair *> > >' ../../boost/boost/type_traits/is_empty.hpp:74: instantiated from `boost::is_class::caller > >,_Rb_tree_iterator,pair &,pair *> > >' ../../boost/boost/type_traits/is_empty.hpp:74: instantiated from `boost::detail::is_empty_impl::caller > >,_Rb_tree_iterator,pair &,pair *> > >' ../../boost/boost/iterator_adaptors.hpp:844: instantiated from `boost::is_empty::caller > >,_Rb_tree_iterator,pair &,pair *> > >' ../../boost/boost/iterator_adaptors.hpp:844: instantiated from `boost::compressed_pair<_Rb_tree_iterator,pair &,pair *>,boost::signals::detail::slot_call_policies::caller > >,_Rb_tree_iterator,pair &,pair *> > >' ../../boost/boost/iterator_adaptors.hpp:844: instantiated from `boost::iterator_adaptor<_Rb_tree_iterator,pair &,pair *>,boost::signals::detail::slot_call_policies::caller > >,_Rb_tree_iterator,pair &,pair *> >,boost::signals::detail::unusable,boost::signals::detail::unusable &,boost::signals::detail::unusable *,input_iterator_tag,boost::detail::default_argument>' ../../boost/boost/signals/detail/slot_call_iterator.hpp:109: instantiated from `boost::signals::detail::make_slot_call_iterator::caller > >, _Rb_tree_iterator,pair &,pair *> >(_Rb_tree_iterator,pair &,pair *>, _Rb_tree_iterator,pair &,pair *>, boost::signals::detail::call_bound0::caller > >)' ../../boost/boost/signals/signal_template.hpp:305: instantiated from `boost::signal0,int,less,boost::function0 > >::operator ()()' insetcommand.h:39: instantiated from here ../../boost/boost/shared_ptr.hpp:203: invalid use of undefined type `struct boost::detail::shared_ptr_traits >' ../../boost/boost/shared_ptr.hpp:52: forward declaration of `struct boost::detail::shared_ptr_traits >' ../../boost/boost/shared_ptr.hpp:203: `boost::shared_ptr >::operator *(...)' must have an argument of class or enumerated type ../../boost/boost/shared_ptr.hpp:203: `boost::shared_ptr >::operator *(...)' must take either one or two arguments make[3]: *** [insetbib.lo] Error 1 Making a
