Re: Compilation problems
Le 04/07/2016 à 23:47, Guillaume Munch a écrit :
But doing so I noticed the following warning with clang, in case someone
fancies fixing it:
In file included from ../../src/EnchantChecker.cpp:14:
/usr/include/enchant/enchant++.h:55:25: warning:
'enchant::Exception::what' hides
overloaded virtual function [-Woverloaded-virtual]
virtual const char * what () throw() {
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/exception:68:25:
note:
hidden overloaded virtual function 'std::exception::what' declared
here:
different qualifiers (const vs none)
virtual const char* what() const _GLIBCXX_USE_NOEXCEPT;
^
I have reported it upstream (it is an obvious mistake), but it was
decided not to fix it as it would break ABI.
https://github.com/AbiWord/enchant/issues/5
JMarc
Re: Compilation problems
Le 05/07/2016 00:55, Stephan Witt a écrit : The enchant C++ header has more serious errors than this one. Look at the method is_added … I’m really surprised it’s so common on Linux. Sorry, I missed the fact that it is not in the LyX source tree.
Re: Compilation problems
> Am 04.07.2016 um 23:47 schrieb Guillaume Munch :
>
> I tried to reproduce the compilation issues from today by compiling with
> clang, and also by changing the build type. The result is that I cannot
> reproduce the issues. Therefore, I am not going to be able adjust my
> build setup to make sure that I cause fewer such issues in the future.
>
> But doing so I noticed the following warning with clang, in case someone
> fancies fixing it:
>
>
> In file included from ../../src/EnchantChecker.cpp:14:
> /usr/include/enchant/enchant++.h:55:25: warning: 'enchant::Exception::what'
> hides
> overloaded virtual function [-Woverloaded-virtual]
>virtual const char * what () throw() {
> ^
> /usr/bin/../lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/exception:68:25:
> note:
> hidden overloaded virtual function 'std::exception::what' declared here:
> different qualifiers (const vs none)
>virtual const char* what() const _GLIBCXX_USE_NOEXCEPT;
>^
>
>
The enchant C++ header has more serious errors than this one.
Look at the method is_added …
I’m really surprised it’s so common on Linux.
> Also, in the future it would help if people included their configuration
> summary together with their reports in case it helps with reproducing.
Ok. I see.
Stephan
Compilation problems
I tried to reproduce the compilation issues from today by compiling with
clang, and also by changing the build type. The result is that I cannot
reproduce the issues. Therefore, I am not going to be able adjust my
build setup to make sure that I cause fewer such issues in the future.
But doing so I noticed the following warning with clang, in case someone
fancies fixing it:
In file included from ../../src/EnchantChecker.cpp:14:
/usr/include/enchant/enchant++.h:55:25: warning:
'enchant::Exception::what' hides
overloaded virtual function [-Woverloaded-virtual]
virtual const char * what () throw() {
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/5.3.1/../../../../include/c++/5.3.1/exception:68:25:
note:
hidden overloaded virtual function 'std::exception::what'
declared here:
different qualifiers (const vs none)
virtual const char* what() const _GLIBCXX_USE_NOEXCEPT;
^
Also, in the future it would help if people included their configuration
summary together with their reports in case it helps with reproducing.
Guillaume
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 18. Januar 2016 09:17:01 MEZ, schrieb "Uwe Stöhr" : > > >From: Peter Kümmel > >Sent: Montag, 18. Januar 2016 03:18 > > >> Something is different on your system, there should be no problem >with finding Qt 5. How actual is your cmake installation? > > >Up to date (3.4.1). Qt is in the folder you hardcoded in the script. > > >> Or do you use a years old Windows for the build? > > What do you imply with this sentence? I'm on Win7 64bit. > >> Latest build folder name should be build5-msvc2010, didn't land this >commit upstream? > > >It is. This folder. > > >However, with the build script I uploaded to git I can and could >compile LyX so we don't need to invest time in your script to release a >beta version. > Forget it, your script or system is broken. >Regards Uwe
Re: compilation problems with Qt 5.5.1 and MSVC 2010
From: Peter KümmelSent: Montag, 18. Januar 2016 03:18> Something is different on your system, there should be no problem with finding Qt 5. How actual is your cmake installation? Up to date (3.4.1). Qt is in the folder you hardcoded in the script.> Or do you use a years old Windows for the build? What do you imply with this sentence? I'm on Win7 64bit. > Latest build folder name should be build5-msvc2010, didn't land this commit upstream? It is. This folder.However, with the build script I uploaded to git I can and could compile LyX so we don't need to invest time in your script to release a beta version. Regards Uwe
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 18. Januar 2016 01:10:41 MEZ, schrieb "Uwe Stöhr" : >Am 17.01.2016 um 18:59 schrieb Peter Kümmel: > > > as you told, you have big problems in settings up clean build. >> Therefore I've changed the build5-2010.bat file you added for >building >> with MSVC2010. > >As I reported proudly I was able to get a clean build. I still have >some >troubles with CMake and reported them as >http://www.lyx.org/trac/ticket/9927 > >The script you modified is the one I uploaded after I could use it to >compile LyX with it with just a click. > >Now I cannot use the script to build LyX: double-clicking on it gives >starts a console that is clased after a few seconds. The error message >is: > >--- >CMake Error at CMakeLists.txt:561 (find_package): > By not providing "FindQt5Core.cmake" in CMAKE_MODULE_PATH this >project has > asked CMake to find a package configuration file provided by >"Qt5Core", but > CMake did not find one. > > Could not find a package configuration file provided by "Qt5Core" >with any > of the following names: > > Qt5CoreConfig.cmake > qt5core-config.cmake > > Add the installation prefix of "Qt5Core" to CMAKE_PREFIX_PATH or set > "Qt5Core_DIR" to a directory containing one of the above files. If >"Qt5Core" provides a separate development package or SDK, be sure it >has > been installed. > >-- Configuring incomplete, errors occurred! >See also "D:/LyXGit/compile-msvc2010/CMakeFiles/CMakeOutput.log". >--- > >I miss in your script a method to select to build a devel or an install > >build. >Moreover >-DLYX_MERGE_REBUILD=1 -DLYX_MERGE_FILES=1 >never worked for me. i get then compilation errors. Thus I am forced to >use >-DLYX_MERGE_REBUILD=0 -DLYX_MERGE_FILES=0 > >> I really hope this improves the current installer chaos. > >I am very thankful that you help me here but I don't understand what >you >mean with "installer chaos". I provided a buggy installer for alpha2 >because I could not test it. That was it. My main problems are to build > >LyX because of the CMake bugs and because I first need to find out that > >LyX cannot be built with MSVC 2012 or newer. > >regards Uwe Is Qt installed on D: in your system? This could be the reason that Qt is not found. Please check the Qt path bin the script. Is it a problem on your system to use Qt's default paths? Maybe you should also use a virtual machine only used for building lyx.
Re: compilation problems with Qt 5.5.1 and MSVC 2010
> >I miss in your script a method to select to build a devel or an install We need a reliable script for the installer input, which only builds lyx nothing else, this is the intention. No parameters no choice. >Moreover >-DLYX_MERGE_REBUILD=1 This flag is only needed when you rebuild again, which is the case here, each time the build dir is clean. -DLYX_MERGE_FILES=1 >never worked for me. i get then compilation errors. Thus I am forced to >use >-DLYX_MERGE_REBUILD=0 -DLYX_MERGE_FILES=0 > >> I really hope this improves the current installer chaos. > >I am very thankful that you help me here but I don't understand what >you >mean with "installer chaos". I provided a buggy installer for alpha2 >because I could not test it. That was it. My main problems are to build > >LyX because of the CMake bugs and because I first need to find out that > >LyX cannot be built with MSVC 2012 or newer. > >regards Uwe
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 18. Januar 2016 01:10:41 MEZ, schrieb "Uwe Stöhr" : >Am 17.01.2016 um 18:59 schrieb Peter Kümmel: > > > as you told, you have big problems in settings up clean build. >> Therefore I've changed the build5-2010.bat file you added for >building >> with MSVC2010. > >As I reported proudly I was able to get a clean build. I still have >some >troubles with CMake and reported them as >http://www.lyx.org/trac/ticket/9927 > >The script you modified is the one I uploaded after I could use it to >compile LyX with it with just a click. > >Now I cannot use the script to build LyX: double-clicking on it gives >starts a console that is clased after a few seconds. The error message >is: > >--- >CMake Error at CMakeLists.txt:561 (find_package): > By not providing "FindQt5Core.cmake" in CMAKE_MODULE_PATH this >project has > asked CMake to find a package configuration file provided by >"Qt5Core", but > CMake did not find one. > > Could not find a package configuration file provided by "Qt5Core" >with any > of the following names: > > Qt5CoreConfig.cmake > qt5core-config.cmake > > Add the installation prefix of "Qt5Core" to CMAKE_PREFIX_PATH or set > "Qt5Core_DIR" to a directory containing one of the above files. If >"Qt5Core" provides a separate development package or SDK, be sure it >has > been installed. > >-- Configuring incomplete, errors occurred! >See also "D:/LyXGit/compile-msvc2010/CMakeFiles/CMakeOutput.log". >--- > >I miss in your script a method to select to build a devel or an install > >build. >Moreover >-DLYX_MERGE_REBUILD=1 -DLYX_MERGE_FILES=1 >never worked for me. i get then compilation errors. Thus I am forced to >use >-DLYX_MERGE_REBUILD=0 -DLYX_MERGE_FILES=0 > >> I really hope this improves the current installer chaos. > >I am very thankful that you help me here but I don't understand what >you >mean with "installer chaos". I provided a buggy installer for alpha2 >because I could not test it. That was it. My main problems are to build > >LyX because of the CMake bugs and because I first need to find out that > >LyX cannot be built with MSVC 2012 or newer. > >regards Uwe Something is different on your system, there should be no problem with finding Qt 5. How actual is your cmake installation? Or do you use a years old Windows for the build? Latest build folder name should be build5-msvc2010, didn't land this commit upstream? Script maybe misses the correcr man dir pass this could be fixed.
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 17.01.2016 um 18:59 schrieb Peter Kümmel: > as you told, you have big problems in settings up clean build. Therefore I've changed the build5-2010.bat file you added for building with MSVC2010. As I reported proudly I was able to get a clean build. I still have some troubles with CMake and reported them as http://www.lyx.org/trac/ticket/9927 The script you modified is the one I uploaded after I could use it to compile LyX with it with just a click. Now I cannot use the script to build LyX: double-clicking on it gives starts a console that is clased after a few seconds. The error message is: --- CMake Error at CMakeLists.txt:561 (find_package): By not providing "FindQt5Core.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Qt5Core", but CMake did not find one. Could not find a package configuration file provided by "Qt5Core" with any of the following names: Qt5CoreConfig.cmake qt5core-config.cmake Add the installation prefix of "Qt5Core" to CMAKE_PREFIX_PATH or set "Qt5Core_DIR" to a directory containing one of the above files. If "Qt5Core" provides a separate development package or SDK, be sure it has been installed. -- Configuring incomplete, errors occurred! See also "D:/LyXGit/compile-msvc2010/CMakeFiles/CMakeOutput.log". --- I miss in your script a method to select to build a devel or an install build. Moreover -DLYX_MERGE_REBUILD=1 -DLYX_MERGE_FILES=1 never worked for me. i get then compilation errors. Thus I am forced to use -DLYX_MERGE_REBUILD=0 -DLYX_MERGE_FILES=0 I really hope this improves the current installer chaos. I am very thankful that you help me here but I don't understand what you mean with "installer chaos". I provided a buggy installer for alpha2 because I could not test it. That was it. My main problems are to build LyX because of the CMake bugs and because I first need to find out that LyX cannot be built with MSVC 2012 or newer. regards Uwe
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Hello Uwe, as you told, you have big problems in settings up clean build. Therefore I've changed the build5-2010.bat file you added for building with MSVC2010. This script now works with a double click, and builds LyX with MSVC2010 in a clean build directory. Three pathes are hardcoded: - Qt installation qt C:\Qt - MSVC2010 installation in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC - and the deps at the same level as the LyX sources lyx20-deps-msvc2010-x86\deps20 (I disabled the automatic download) I assume the pathes are the same on most systems. You only have to unpack the deps-msvc2010-x86 folder once at the right place. A simple double click creates the folder "build5-msvc2010" with the LYX_INSTALLED files. Please use these files for you installer. We should change this script until it also works for you. The goal is that you don't have to touch it before you execute it. I really hope this improves the current installer chaos. Peter
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 14.01.2016 um 20:58 schrieb Georg Baum: Please continue. I will have to switch to MinGW because Qt 5.6 does not support MSVC 2010 and due to a bug in our code MSVC 2012, 2013 and 2015 cannot be used to compile LyX. Do you mean http://www.lyx.org/trac/ticket/9892 or are there other bugs? I mean this bug. As I understood the comments there std::basic_istringstream is the problem. But since this affects different MSVC versions I cannot imagine that it is a bug in MSVC that so many programs/projects use to compile. If it would be it would have been fixed in MSVC. I googled a bit around and it seems that support for the basic_istringstream Class was not changed: MSVC 2010: https://msdn.microsoft.com/de-de/library/windows/hardware/czkzky67%28v=vs.100%29.aspx MSVC 2013: https://msdn.microsoft.com/de-de/library/windows/hardware/czkzky67%28v=vs.120%29.aspx However I find this warning " Reading from a stream buffer is not considered to be a read operation. Instead it is considered to be a write operation because the state of the class is changed. " in https://msdn.microsoft.com/de-de/library/windows/hardware/c9ceah3b%28v=vs.120%29.aspx The page about the basic_istringstream Members is only available for MSVC 2010 and 2012 and not 2013 and 2015: https://msdn.microsoft.com/de-de/library/windows/hardware/349xheek%28v=vs.100%29.aspx Here the general info about iostreams for MSVC: https://msdn.microsoft.com/de-de/library/windows/hardware/8e9dt98w%28v=vs.120%29.aspx In the breaking changes i cannot find something about streams, but maybe you do: MSVC 2012: https://msdn.microsoft.com/en-us/library/bb531344%28v=vs.110%29.aspx MSVC 2013: https://msdn.microsoft.com/en-us/library/bb531344%28v=vs.120%29.aspx MSVC 2015: https://msdn.microsoft.com/en-us/library/bb531344%28v=vs.140%29.aspx regards Uwe
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Uwe Stöhr wrote: > Please continue. I will have to switch to MinGW because Qt 5.6 does not > support MSVC 2010 and due to a bug in our code MSVC 2012, 2013 and 2015 > cannot be used to compile LyX. Do you mean http://www.lyx.org/trac/ticket/9892 or are there other bugs? Georg
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 13.01.2016 um 05:41 schrieb Peter Kümmel: If 5.6 is to buggy, we can also use 5.5.1 build with mingw. Apparently beta1 will be built with Qt 5.5.1. And now, after some hours of fiddling with CMake I am able to build Qt 5.5.1 with MSVC 2010 and the result looks promising - stable LyX without all the crashes I had with MSVC 2013. So to save time I will build beta with MSVC2010. But when we now decide to use only msvc2010, then I stop working on a mingw build. Please continue. I will have to switch to MinGW because Qt 5.6 does not support MSVC 2010 and due to a bug in our code MSVC 2012, 2013 and 2015 cannot be used to compile LyX. As soon as beta1 is out I will try out MinGW. many thanks and regards Uwe
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 13. Januar 2016 05:27:22 MEZ, schrieb "Peter Kümmel" : >Am 13. Januar 2016 05:19:09 MEZ, schrieb "Peter Kümmel" >: >> It is a warning only committed from me today to fix a linker error. >>>You tried it with msvc 2010? And it worked? >>> >>>Yes. I can now compile with MSVC 2010 and Qt 5.5.1. The compilation >of >> >>>Zlib and friends works here also with MSVC2013. >> >> >>Ok, then you could build an installer again with MSVC2010 and 5.5.1. >> >>But afaik Qt 5.6 will not support MSVC2010 any more. So maybe it is >>worth now to start trying with mingw, because atm the new msvc >>compilers have no real futute within lyx. I assume even clang would be >>better. >> >>Is there a recipe how to procede after the successfull build of lyx? >>How complicated is it to get an installer created? >> >>The mingw.bat works, so is it possible to add a second script which >>produces the installer?i >> >>> >>>regards Uwe If 5.6 is to buggy, we can also use 5.5.1 build with mingw. But when we now decide to use only msvc2010, then I stop working on a mingw build.
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 13. Januar 2016 05:19:09 MEZ, schrieb "Peter Kümmel" : > >>> It is a warning only committed from me today to fix a linker error. >>You tried it with msvc 2010? And it worked? >> >>Yes. I can now compile with MSVC 2010 and Qt 5.5.1. The compilation of > >>Zlib and friends works here also with MSVC2013. > > >Ok, then you could build an installer again with MSVC2010 and 5.5.1. > >But afaik Qt 5.6 will not support MSVC2010 any more. So maybe it is >worth now to start trying with mingw, because atm the new msvc >compilers have no real futute within lyx. I assume even clang would be >better. > >Is there a recipe how to procede after the successfull build of lyx? >How complicated is it to get an installer created? > >The mingw.bat works, so is it possible to add a second script which >produces the installer?i > >> >>regards Uwe
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 13.01.2016 um 01:38 schrieb Peter Kümmel: It is a warning only committed from me today to fix a linker error. You tried it with msvc 2010? And it worked? Yes. I can now compile with MSVC 2010 and Qt 5.5.1. The compilation of Zlib and friends works here also with MSVC2013. regards Uwe
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 13. Januar 2016 01:18:12 MEZ, schrieb "Uwe Stöhr" : >Am 12.01.2016 um 11:16 schrieb Peter Kümmel: > >> Yes, no Dlls any more (only the Qt related ones). > >OK. > >However I get now man times this warning: > >D:\LyXGit\Master\compile-2010\zconf.h(10): warning C4005: 'Z_PREFIX': >Makro-Neudefinition [D:\LyXGit\Master\compile-2010\src\LyX.vcxproj] > D:\LyXGit\Master\compile-2010\config.h(78): Siehe vorherige >Definition von 'Z_PREFIX' > >Can we do something against this (MSVC 2010)? > >>> thanks and regards >>> Uwe It is a warning only committed from me today to fix a linker error. You tried it with msvc 2010? And it worked?
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 12.01.2016 um 11:16 schrieb Peter Kümmel: Yes, no Dlls any more (only the Qt related ones). OK. However I get now man times this warning: D:\LyXGit\Master\compile-2010\zconf.h(10): warning C4005: 'Z_PREFIX': Makro-Neudefinition [D:\LyXGit\Master\compile-2010\src\LyX.vcxproj] D:\LyXGit\Master\compile-2010\config.h(78): Siehe vorherige Definition von 'Z_PREFIX' Can we do something against this (MSVC 2010)? thanks and regards Uwe
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 12. Januar 2016 20:24:38 MEZ, schrieb Georg Baum : >Am 12.01.2016 um 00:37 schrieb Uwe Stöhr: >> I did this now as I wrote in the >> Questions for Uwe once you are back >> thread. >> I had to delete CMake's cache first and re-run it from scratch. The >> 3rd party programs are compiled (with 134 warnings) but I don't get a > >> DLL. Is this the plan - not to rely anymore on DLLs? >> >Almost. The libs are currently compiled as static libraries. But this >is >not the most important aspect. The main goal of having these sources >included with LyX is that no externally compiled prerequisites are >needed anymore (except for qt). This has two advantages: > >1) It makes it more easy for other people to build LyX on windows, even > >if they have a different compiler than you. I hope that this will >attract other people who build on windows in the long term, so that you > >do not need to do everything alone. > >2) It eliminates all possibillities of errors that may occur because of > >different compilers. This makes it more easy for you to switch to a new > >MSVC version. But Atm all msvc > 2010 versions are broken. So the only way to go is mingw or 2010. > >If it turns out that for some reason having one of these thirdparty >libraries as dll has advantages, we could also change the build >procedure to produce dlls from the same sources. > > >Georg
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 12.01.2016 um 00:37 schrieb Uwe Stöhr: I did this now as I wrote in the Questions for Uwe once you are back thread. I had to delete CMake's cache first and re-run it from scratch. The 3rd party programs are compiled (with 134 warnings) but I don't get a DLL. Is this the plan - not to rely anymore on DLLs? Almost. The libs are currently compiled as static libraries. But this is not the most important aspect. The main goal of having these sources included with LyX is that no externally compiled prerequisites are needed anymore (except for qt). This has two advantages: 1) It makes it more easy for other people to build LyX on windows, even if they have a different compiler than you. I hope that this will attract other people who build on windows in the long term, so that you do not need to do everything alone. 2) It eliminates all possibillities of errors that may occur because of different compilers. This makes it more easy for you to switch to a new MSVC version. If it turns out that for some reason having one of these thirdparty libraries as dll has advantages, we could also change the build procedure to produce dlls from the same sources. Georg
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 12.01.2016 um 00:37 schrieb Uwe Stöhr: I had to delete CMake's cache first and re-run it from scratch. The 3rd party programs are compiled (with 134 warnings) but I don't get a DLL. Is this the plan - not to rely anymore on DLLs? Yes, no Dlls any more (only the Qt related ones). thanks and regards Uwe
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Am 11.01.2016 um 20:44 schrieb Georg Baum: welcome back and a happy new year! Thanks. The same to you. As I wrote in the "questions" mail: I am pretty sure that using the sources in 3rdparty instead of the precompiled binary dependencies will result in a better build and less work. Please try to do that by setting the 3RDPARTY_BUILD option to ON in the cmake call and unsetting the GNUWIN32_DIR variable. I did this now as I wrote in the Questions for Uwe once you are back thread. I had to delete CMake's cache first and re-run it from scratch. The 3rd party programs are compiled (with 134 warnings) but I don't get a DLL. Is this the plan - not to rely anymore on DLLs? thanks and regards Uwe
Re: compilation problems with Qt 5.5.1 and MSVC 2010
Hi Uwe, welcome back and a happy new year! Uwe Stöhr wrote: > I can compile LyX 2.2dev with > - Qt 4.8.7 and MSVC 2010 > - Qt 5.5.1 and MSVC 2013 (the resulting build has problems I already > reported in December, but the compilation itself works) > > But if I use > - Qt 5.5.1 and MSVC 2010 > I get these libiconv compilation errors: > > "D:\LyXGit\Master\compile-2010\src\LyX.vcxproj" (Standardziel) (23) -> > (Link Ziel) -> >support.lib(docstream.obj) : error LNK2019: Verweis auf nicht > aufgel÷stes externes Symbol "__imp__libiconv_open" in Funktion ""public: > __thiscall `anonymous > namespace'::iconv_codecvt_facet::iconv_codecvt_facet(class > std::basic_string,class > std::allocator > const &,int,unsigned int)" > (??0iconv_codecvt_facet@?A0x188375c2@@QAE@ABV?$basic_string@DU? $char_traits@D@std@@V?$allocator@D@2@@std@@HI@Z)". The build script looks as if it uses the old binary MSVC 2010 dependencies. They do probably intefere with the new 3rdparty directory added by Peter. As I wrote in the "questions" mail: I am pretty sure that using the sources in 3rdparty instead of the precompiled binary dependencies will result in a better build and less work. Please try to do that by setting the 3RDPARTY_BUILD option to ON in the cmake call and unsetting the GNUWIN32_DIR variable. Georg
Re: Compilation problems
> Possible :-/ How can I convert it to the 4.2 format using the 4.3 designer? afaik not possible. either downgrade to 4.2 or upgrade to 4.4 or install them locally and use only their designer. pavel
Re: Compilation problems
Stefan Schimanski wrote: > Possible :-/ How can I convert it to the 4.2 format using the 4.3 > designer? You have to use the 4.2 designer. Jürgen
Re: Compilation problems
Possible :-/ How can I convert it to the 4.2 format using the 4.3 designer? Stefan Am 10.03.2008 um 17:04 schrieb Jean-Marc Lasgouttes: I get the following. Is the UI file in qt 4.3 format? JMarc g++ -DHAVE_CONFIG_H -I. -I../../../../lyx-devel/src/frontends/qt4 - I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL - DQT_NO_KEYWORDS -I../../../../lyx-devel/src -I../../../../lyx-devel/ src/frontends -I../../../../lyx-devel/images -DQT_SHARED -I/usr/lib/ qt4/include -I/usr/lib/qt4/include/QtCore -I/usr/lib/qt4/include/ QtGui -I../../../../lyx-devel/boost -Wextra -Wall -g -O -MT GuiPrefs.lo -MD -MP -MF .deps/GuiPrefs.Tpo -c ../../../../lyx-devel/ src/frontends/qt4/GuiPrefs.cpp -o GuiPrefs.o ./ui_PrefUi.h: In member function 'void Ui_PrefUi::setupUi(QWidget*)': ./ui_PrefUi.h:92: error: 'class QGridLayout' has no member named 'setHorizontalSpacing' ./ui_PrefUi.h:93: error: 'class QGridLayout' has no member named 'setVerticalSpacing' ./ui_PrefUi.h:180: error: 'class QGridLayout' has no member named 'setHorizontalSpacing' ./ui_PrefUi.h:181: error: 'class QGridLayout' has no member named 'setVerticalSpacing' ./ui_PrefUi.h:270: error: 'class QGridLayout' has no member named 'setHorizontalSpacing' ./ui_PrefUi.h:271: error: 'class QGridLayout' has no member named 'setVerticalSpacing'
Compilation problems
I get the following. Is the UI file in qt 4.3 format? JMarc g++ -DHAVE_CONFIG_H -I. -I../../../../lyx-devel/src/frontends/qt4 -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../../lyx-devel/src -I../../../../lyx-devel/src/frontends -I../../../../lyx-devel/images -DQT_SHARED -I/usr/lib/qt4/include -I/usr/lib/qt4/include/QtCore -I/usr/lib/qt4/include/QtGui -I../../../../lyx-devel/boost -Wextra -Wall -g -O -MT GuiPrefs.lo -MD -MP -MF .deps/GuiPrefs.Tpo -c ../../../../lyx-devel/src/frontends/qt4/GuiPrefs.cpp -o GuiPrefs.o ./ui_PrefUi.h: In member function 'void Ui_PrefUi::setupUi(QWidget*)': ./ui_PrefUi.h:92: error: 'class QGridLayout' has no member named 'setHorizontalSpacing' ./ui_PrefUi.h:93: error: 'class QGridLayout' has no member named 'setVerticalSpacing' ./ui_PrefUi.h:180: error: 'class QGridLayout' has no member named 'setHorizontalSpacing' ./ui_PrefUi.h:181: error: 'class QGridLayout' has no member named 'setVerticalSpacing' ./ui_PrefUi.h:270: error: 'class QGridLayout' has no member named 'setHorizontalSpacing' ./ui_PrefUi.h:271: error: 'class QGridLayout' has no member named 'setVerticalSpacing'
Re: Compilation problems (trunk & branch)
On Sat, 2007-11-03 at 23:25 +0100, Abdelrazak Younes wrote: > Please try again with latest rev. > > Abdel. > > PS: Sorry Juergen I didn't wait but this is an urgency. Fixed. Have fun, Darren
Re: Compilation problems (trunk & branch)
Abdelrazak Younes wrote: > Please try again with latest rev. > > Abdel. > > PS: Sorry Juergen I didn't wait but this is an urgency. Thanks. I really have no explanation why this happened. Jürgen
Re: Compilation problems (trunk & branch)
Am Sonntag 04 November 2007 schrieb Dov Feldstern: > Works for me, thanks Abdel! Here too. Thanx Abdel :) > > Abdel. > > > > PS: Sorry Juergen I didn't wait but this is an urgency. !! Kornel -- Kornel Benko [EMAIL PROTECTED] pgpsmKgeJPvzd.pgp Description: PGP signature
Re: Compilation problems (trunk & branch)
Abdelrazak Younes wrote: Kornel Benko wrote: Am Samstag 03 November 2007 schrieb Dov Feldstern: Dov Feldstern wrote: Hi! I'm also having compilation trouble in both trunk and branch. I'm using Qt 4.2.1 (which is the version that debian etch offers as far as I can tell). Sorry, trunk is OK (I hadn't updated); branch still problematic, though. Same here. Qt 4.2.3, kubuntu. Please try again with latest rev. Works for me, thanks Abdel! Abdel. PS: Sorry Juergen I didn't wait but this is an urgency.
Re: Compilation problems (trunk & branch)
Kornel Benko wrote: Am Samstag 03 November 2007 schrieb Dov Feldstern: Dov Feldstern wrote: Hi! I'm also having compilation trouble in both trunk and branch. I'm using Qt 4.2.1 (which is the version that debian etch offers as far as I can tell). Sorry, trunk is OK (I hadn't updated); branch still problematic, though. Same here. Qt 4.2.3, kubuntu. Please try again with latest rev. Abdel. PS: Sorry Juergen I didn't wait but this is an urgency.
Re: Compilation problems (trunk & branch)
Am Samstag 03 November 2007 schrieb Dov Feldstern: > Dov Feldstern wrote: > > Hi! > > > > I'm also having compilation trouble in both trunk and branch. I'm using > > Qt 4.2.1 (which is the version that debian etch offers as far as I can > > tell). > > Sorry, trunk is OK (I hadn't updated); branch still problematic, though. Same here. Qt 4.2.3, kubuntu. Kornel -- Kornel Benko [EMAIL PROTECTED] pgpo7sIE3s8Yz.pgp Description: PGP signature
Re: Compilation problems (trunk & branch)
Dov Feldstern wrote: Hi! I'm also having compilation trouble in both trunk and branch. I'm using Qt 4.2.1 (which is the version that debian etch offers as far as I can tell). Sorry, trunk is OK (I hadn't updated); branch still problematic, though. * branch: g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_ST R -DQT_NO_STL -DQT_NO_KEYWORDS -Winvalid-pch --include=./pch.h -I../../../src -I ../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/qt4 -I/usr/i nclude/qt4/QtCore -I/usr/include/qt4/QtGui -I../../../boost -I../../../src/front ends/controllers -Wextra -Wall -g -O -MT Dialogs.lo -MD -MP -MF .deps/Dialogs.Tp o -c Dialogs.cpp -o Dialogs.o ui/PrefUi.h: In member function 'void Ui_QPrefUi::setupUi(QWidget*)': ui/PrefUi.h:123: error: 'class QGridLayout' has no member named 'setLeftMargin' ui/PrefUi.h:124: error: 'class QGridLayout' has no member named 'setTopMargin' ui/PrefUi.h:125: error: 'class QGridLayout' has no member named 'setRightMargin' ui/PrefUi.h:126: error: 'class QGridLayout' has no member named 'setBottomMargin ' ui/PrefUi.h:127: error: 'class QGridLayout' has no member named 'setHorizontalSp acing' ui/PrefUi.h:128: error: 'class QGridLayout' has no member named 'setVerticalSpac ing' ui/PrefUi.h:158: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:159: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:160: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:161: error: 'class QHBoxLayout' has no member named 'setBottomMargin ' ui/PrefUi.h:211: error: 'class QVBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:212: error: 'class QVBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:213: error: 'class QVBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:214: error: 'class QVBoxLayout' has no member named 'setBottomMargin ' ui/PrefUi.h:223: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:224: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:225: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:226: error: 'class QHBoxLayout' has no member named 'setBottomMargin ' ui/PrefUi.h:254: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:255: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:256: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:257: error: 'class QHBoxLayout' has no member named 'setBottomMargin ' ui/PrefUi.h:281: error: 'class QVBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:282: error: 'class QVBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:283: error: 'class QVBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:284: error: 'class QVBoxLayout' has no member named 'setBottomMargin ' make[7]: *** [Dialogs.lo] Error 1
Compilation problems (trunk & branch)
Hi! I'm also having compilation trouble in both trunk and branch. I'm using Qt 4.2.1 (which is the version that debian etch offers as far as I can tell). * trunk: g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_ST R -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends -I../../. ./images -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include /qt4/QtGui -I../../../boost -I../../../src/frontends/controllers -Wextra -Wall - g -O -MT GuiHyperlink.lo -MD -MP -MF .deps/GuiHyperlink.Tpo -c GuiHyperlink.cpp -o GuiHyperlink.o ui_HyperlinkUi.h: In member function 'void Ui_HyperlinkUi::setupUi(QDialog*)': ui_HyperlinkUi.h:102: error: 'class QHBoxLayout' has no member named 'setLeftMar gin' ui_HyperlinkUi.h:103: error: 'class QHBoxLayout' has no member named 'setTopMarg in' ui_HyperlinkUi.h:104: error: 'class QHBoxLayout' has no member named 'setRightMa rgin' ui_HyperlinkUi.h:105: error: 'class QHBoxLayout' has no member named 'setBottomM argin' make[6]: *** [GuiHyperlink.lo] Error 1 --- * branch: g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_ST R -DQT_NO_STL -DQT_NO_KEYWORDS -Winvalid-pch --include=./pch.h -I../../../src -I ../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/qt4 -I/usr/i nclude/qt4/QtCore -I/usr/include/qt4/QtGui -I../../../boost -I../../../src/front ends/controllers -Wextra -Wall -g -O -MT Dialogs.lo -MD -MP -MF .deps/Dialogs.Tp o -c Dialogs.cpp -o Dialogs.o ui/PrefUi.h: In member function 'void Ui_QPrefUi::setupUi(QWidget*)': ui/PrefUi.h:123: error: 'class QGridLayout' has no member named 'setLeftMargin' ui/PrefUi.h:124: error: 'class QGridLayout' has no member named 'setTopMargin' ui/PrefUi.h:125: error: 'class QGridLayout' has no member named 'setRightMargin' ui/PrefUi.h:126: error: 'class QGridLayout' has no member named 'setBottomMargin ' ui/PrefUi.h:127: error: 'class QGridLayout' has no member named 'setHorizontalSp acing' ui/PrefUi.h:128: error: 'class QGridLayout' has no member named 'setVerticalSpac ing' ui/PrefUi.h:158: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:159: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:160: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:161: error: 'class QHBoxLayout' has no member named 'setBottomMargin ' ui/PrefUi.h:211: error: 'class QVBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:212: error: 'class QVBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:213: error: 'class QVBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:214: error: 'class QVBoxLayout' has no member named 'setBottomMargin ' ui/PrefUi.h:223: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:224: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:225: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:226: error: 'class QHBoxLayout' has no member named 'setBottomMargin ' ui/PrefUi.h:254: error: 'class QHBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:255: error: 'class QHBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:256: error: 'class QHBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:257: error: 'class QHBoxLayout' has no member named 'setBottomMargin ' ui/PrefUi.h:281: error: 'class QVBoxLayout' has no member named 'setLeftMargin' ui/PrefUi.h:282: error: 'class QVBoxLayout' has no member named 'setTopMargin' ui/PrefUi.h:283: error: 'class QVBoxLayout' has no member named 'setRightMargin' ui/PrefUi.h:284: error: 'class QVBoxLayout' has no member named 'setBottomMargin ' make[7]: *** [Dialogs.lo] Error 1
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
"Honest Guvnor" <[EMAIL PROTECTED]> writes: > On 10/17/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: >> The reason seems to be that configure recognizes the compiler as gcc >> whereas it is not gcc. Could you send (privately maybe) your >> config.log file so that I investigate this? > > The compiler is gcc 3.3 with some modifications by Apple. Bennett is > stating that gcc 4.0 is required and the use of gcc 4.0 specific flags > in the configure script would be inline with this. I do not think there is any gcc4 specific flags in the configure script. If I remember correctly, the problem with gcc3 was when linking, not compiling. > I am happy to send you the log file but it may be wise to check with > the people experienced with the Mac port about how locked in they > are to the latest 10.4 version of OSX. Concerning your config.log entry, the problem seems to be: configure:26619: gcc -o conftest -O2 -I/usr/X11R6/include conftest.c -lSM -lICE -lm -liconv -lz -L/usr/X11R6/lib -lX11 -framework ApplicationServices -F/usr/local/Trolltech/Qt-4.3.2/lib Carbon AppKit QtCore >&5 gcc: Carbon: No such file or directory gcc: AppKit: No such file or directory gcc: QtCore: No such file or directory The is because you have an old version of pkg-config installed. Remove it, or install a newer one. > Alternatively, if someone can confirm that I can still build an X > version of lyx without the Apple stuff then I will keep going trying > to compile lyx now and again. I think it should work JMarc
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
On 10/17/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > The reason seems to be that configure recognizes the compiler as gcc > whereas it is not gcc. Could you send (privately maybe) your > config.log file so that I investigate this? The compiler is gcc 3.3 with some modifications by Apple. Bennett is stating that gcc 4.0 is required and the use of gcc 4.0 specific flags in the configure script would be inline with this. I am happy to send you the log file but it may be wise to check with the people experienced with the Mac port about how locked in they are to the latest 10.4 version of OSX. Alternatively, if someone can confirm that I can still build an X version of lyx without the Apple stuff then I will keep going trying to compile lyx now and again.
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
"Honest Guvnor" <[EMAIL PROTECTED]> writes: > On 10/16/07, Honest Guvnor <[EMAIL PROTECTED]> wrote: >> Enrico wrote: >> > Have you seen the following post? >> > >> > http://article.gmane.org/gmane.editors.lyx.devel/96913/ >> > >> > I think you are using wrong flags for gcc. >> >> Yes I had read the post but I am not explicitly setting any optimising >> flags for gcc. > > I have checked config.log and indeed a substantial number of tests are > failing because of incorrect flags and not because of what is being > tested. The reason seems to be that configure recognizes the compiler as gcc whereas it is not gcc. Could you send (privately maybe) your config.log file so that I investigate this? JMarc
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
On 10/16/07, Honest Guvnor <[EMAIL PROTECTED]> wrote: > Enrico wrote: > > Have you seen the following post? > > > > http://article.gmane.org/gmane.editors.lyx.devel/96913/ > > > > I think you are using wrong flags for gcc. > > Yes I had read the post but I am not explicitly setting any optimising > flags for gcc. I have checked config.log and indeed a substantial number of tests are failing because of incorrect flags and not because of what is being tested.
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
Enrico wrote: > Have you seen the following post? > > http://article.gmane.org/gmane.editors.lyx.devel/96913/ > > I think you are using wrong flags for gcc. Yes I had read the post but I am not explicitly setting any optimising flags for gcc. I am letting configure do its natural thing but I would agree that it is clearly failing to function correctly and this may be due to incorrect flags. Unfortunately, if the lyx written code requires gcc 4.0 which is not part of the gcc compiler on OSX 10.3 then I am unable to compile lyx anyway without considerable effort. In addition, the knowledge gained would be largely useless because all the others with OSX 10.3 would not be able to compile without repeating the same efforts. Lyx would seem to require the latest version of OSX and the behaviour I am seeing with the binary may well be related to this.
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
On Tue, Oct 16, 2007 at 07:26:38AM +0200, Honest Guvnor wrote: > On 10/16/07, Bennett Helm <[EMAIL PROTECTED]> wrote: > > > > I haven't had any of these problems on Intel, and neither has Anders > > on PPC. > > Possibly but somone using a Sun was reporting similar problems a few > threads below. Have you seen the following post? http://article.gmane.org/gmane.editors.lyx.devel/96913/ I think you are using wrong flags for gcc. -- Enrico
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
"Honest Guvnor" <[EMAIL PROTECTED]> writes: > I was not disputing the dependency on gcc 4.0 but asking if it can be > avoided by building an X version (i.e. using essentially the same code > as linux) and avoiding the OSX-specific code. I am asking because the > main INSTALL file does not appear to have the dependency. I think the exact required version is not clear today. All I can say is that I build LyX on gcc 3.4.1 on linux without any problem. Many of the problems with older gcc versions can probably be solved (at least for the X11 version) with a little help from the people who encounter problems. JMarc
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
On 10/16/07, Bennett Helm <[EMAIL PROTECTED]> wrote: > On Oct 16, 2007, at 9:00 AM, Honest Guvnor wrote: > > >> That's the problem. You need 4.0 or greater. > > > > How can lyx depend on gcc 4.0? It was only released 5 minutes ago. > > I believe gcc 4.0 has been out for over 2 years on Mac. I suspect we come from rather different generations of programmers. > > The main INSTALL file says gcc 2.8 does not work and so is gcc 4.0 > > only a requirement peculiar to the OSX port? If so, will the X build > > work? > > INSTALL.MacOSX says: I was not disputing the dependency on gcc 4.0 but asking if it can be avoided by building an X version (i.e. using essentially the same code as linux) and avoiding the OSX-specific code. I am asking because the main INSTALL file does not appear to have the dependency.
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
On Oct 16, 2007, at 9:00 AM, Honest Guvnor wrote: That's the problem. You need 4.0 or greater. How can lyx depend on gcc 4.0? It was only released 5 minutes ago. I believe gcc 4.0 has been out for over 2 years on Mac. The main INSTALL file says gcc 2.8 does not work and so is gcc 4.0 only a requirement peculiar to the OSX port? If so, will the X build work? INSTALL.MacOSX says: You will need the MacOSX development tools. The procedure described here builds LyX linked with a static Qt library. Also note that building LyX/Mac requires gcc version 4.0 or higher. (You can check your version by entering "gcc -v" in the Terminal; you can change your gcc version to version 4.0, for example, by entering "sudo gcc_select 4.0".) Bennett
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
> That's the problem. You need 4.0 or greater. How can lyx depend on gcc 4.0? It was only released 5 minutes ago. The main INSTALL file says gcc 2.8 does not work and so is gcc 4.0 only a requirement peculiar to the OSX port? If so, will the X build work?
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
On Oct 16, 2007, at 1:26 AM, Honest Guvnor wrote: On 10/16/07, Bennett Helm <[EMAIL PROTECTED]> wrote: What version of gcc are you using? bolt:~/pub/lyx-1.5.2 andy$ gcc --version gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1495) Copyright (C) 2002 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. That's the problem. You need 4.0 or greater. Bennett
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
On 10/16/07, Bennett Helm <[EMAIL PROTECTED]> wrote: > > I haven't had any of these problems on Intel, and neither has Anders > on PPC. Possibly but somone using a Sun was reporting similar problems a few threads below. > What version of gcc are you using? bolt:~/pub/lyx-1.5.2 andy$ gcc --version gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1495) Copyright (C) 2002 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.
Re: Lyx 1.5.2 compilation problems on OSX 10.3.9
On Oct 15, 2007, at 5:24 PM, Honest Guvnor wrote: Lyx 1.5.2, OSX 10.3.9, PowerPC G4 In an effort to investigate the odd behaviour of the binary version (reported on users list) I have been unsuccessfully trying to compile lyx 1.5.2. Points to note: The config.h file is badly wrong. The following were not defined: setenv, putenv, popen, pclose, mkdir, getpid, mktemp, open, close. Defining them allowed the code in support to compile but I suspect there is no chance that everything else is defined correctly. Make then fails in qt4/ui as follows (snipped early bit): I haven't had any of these problems on Intel, and neither has Anders on PPC. What version of gcc are you using? Bennett
Lyx 1.5.2 compilation problems on OSX 10.3.9
Lyx 1.5.2, OSX 10.3.9, PowerPC G4 In an effort to investigate the odd behaviour of the binary version (reported on users list) I have been unsuccessfully trying to compile lyx 1.5.2. Points to note: The config.h file is badly wrong. The following were not defined: setenv, putenv, popen, pclose, mkdir, getpid, mktemp, open, close. Defining them allowed the code in support to compile but I suspect there is no chance that everything else is defined correctly. Make then fails in qt4/ui as follows (snipped early bit): Making all in frontends make all-recursive Making all in controllers make all-recursive Making all in tests make all-am make[8]: Nothing to be done for `all-am'. make[7]: Nothing to be done for `all-am'. Making all in qt4 make all-recursive Making all in ui make all-am make[8]: Nothing to be done for `all-am'. /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/local/Trolltech/Qt-4.3.2/include -I/usr/local/Trolltech/Qt-4.3.2/include/QtCore -I/usr/local/Trolltech/Qt-4.3.2/include/QtGui -I../../../boost -I../../../src/frontends/controllers -I/usr/X11R6/include -O2 -MT GuiApplication.lo -MD -MP -MF .deps/GuiApplication.Tpo -c -o GuiApplication.lo GuiApplication.cpp g++ -DHAVE_CONFIG_H -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../../src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/local/Trolltech/Qt-4.3.2/include -I/usr/local/Trolltech/Qt-4.3.2/include/QtCore -I/usr/local/Trolltech/Qt-4.3.2/include/QtGui -I../../../boost -I../../../src/frontends/controllers -I/usr/X11R6/include -O2 -MT GuiApplication.lo -MD -MP -MF .deps/GuiApplication.Tpo -c GuiApplication.cpp -o GuiApplication.o In file included from ../../../boost/boost/type_traits/is_arithmetic.hpp:13, from ../../../boost/boost/type_traits/is_enum.hpp:15, from ../../../boost/boost/type_traits/composite_traits.hpp:17, from ../../../boost/boost/function/function_base.hpp:21, from ../../../boost/boost/function/detail/prologue.hpp:16, from ../../../boost/boost/function.hpp:22, from ../../../src/frontends/Application.h:14, from GuiApplication.h:22, from GuiApplication.cpp:15: ../../../boost/boost/type_traits/is_float.hpp:21: warning: use of `long double' type; its size may change in a future release ../../../boost/boost/type_traits/is_float.hpp:21: warning: (Long double usage is reported only once for each file. ../../../boost/boost/type_traits/is_float.hpp:21: warning: To disable this warning, use -Wno-long-double.) ../../../boost/boost/checked_delete.hpp: In function `void boost::checked_delete(T*) [with T = lyx::frontend::MenuTranslator]': GuiApplication.cpp:77: instantiated from `boost::scoped_ptr::~scoped_ptr() [with T = lyx::frontend::MenuTranslator]' GuiApplication.cpp:77: instantiated from `boost::scoped_ptr::~scoped_ptr() [with T = lyx::frontend::MenuTranslator]' GuiApplication.cpp:97: instantiated from here ../../../boost/boost/checked_delete.hpp:32: error: invalid application of ` sizeof' to an incomplete type ../../../boost/boost/checked_delete.hpp:32: error: creating array with size zero (`-1') ../../../boost/boost/checked_delete.hpp:33: error: invalid application of ` sizeof' to an incomplete type ../../../boost/boost/checked_delete.hpp:33: error: creating array with size zero (`-1') ../../../boost/boost/checked_delete.hpp:30: warning: `x' has incomplete type GuiApplication.h:39: warning: forward declaration of `struct lyx::frontend::MenuTranslator' make[7]: *** [GuiApplication.lo] Error 1 make[6]: *** [all-recursive] Error 1 make[5]: *** [all] Error 2 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 bolt:~/pub/lyx-1.5.2 andy$
Re: Compilation problems
Thank you very much! I'll try. Angus Leeming wrote: Kostantino wrote: Hi guys. I tried to compile lyx-1.3.6 for my Slackware 10.1. Configure runs fine with the options: g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src -I../../../src/frontends -I../../../images -I./qt2 -I/usr/lib/qt/include -I../../../boost -I../../../src/frontends/controllers -isystem /usr/X11R6/include -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_THREAD_SUPPORT -O3 -MT QPrefs.lo -MD -MP -MF .deps/QPrefs.Tpo -c QPrefs.C http://marc.theaimsgroup.com/?l=lyx-users&m=112160435622015 Angus
Re: Compilation problems
> "Kostantino" == Kostantino <[EMAIL PROTECTED]> writes: Kostantino> Hi guys. I tried to compile lyx-1.3.6 for my Slackware Kostantino> 10.1. Yes, this is unfortunate. I alreday fixed it in cvs, but you can follow Georg Baum's advice here: http://www.mail-archive.com/lyx-users@lists.lyx.org/msg40655.html JMarc
Re: Compilation problems
Kostantino wrote: Hi guys. I tried to compile lyx-1.3.6 for my Slackware 10.1. Configure runs fine with the options: g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src -I../../../src/frontends -I../../../images -I./qt2 -I/usr/lib/qt/include -I../../../boost -I../../../src/frontends/controllers -isystem /usr/X11R6/include -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_THREAD_SUPPORT -O3 -MT QPrefs.lo -MD -MP -MF .deps/QPrefs.Tpo -c QPrefs.C http://marc.theaimsgroup.com/?l=lyx-users&m=112160435622015 Angus
Compilation problems
Hi guys. I tried to compile lyx-1.3.6 for my Slackware 10.1. Configure runs fine with the options: /configure --enable-optimization=-O3 --with-frontend=qt --with-x --enable-shared --with-packaging=posix or, instead: /configure --enable-optimization=-O3 --with-frontend=qt --with-x but in evry case the compilation aborts with the output: g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src -I../../../src/frontends -I../../../images -I./qt2 -I/usr/lib/qt/include -I../../../boost -I../../../src/frontends/controllers -isystem /usr/X11R6/include -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_THREAD_SUPPORT -O3 -MT QPrefs.lo -MD -MP -MF .deps/QPrefs.Tpo -c QPrefs.C QPrefs.C: In function `void ::setComboxFont(QComboBox*, const std::string&, const std::string&, QFont::StyleHint)': QPrefs.C:350: error: no match for 'operator==' in 'QComboBox::text(int) const(i) == default_font_name' ../../../src/lyxlength.h:85: error: candidates are: bool operator==(const LyXLength&, const LyXLength&) ../../../src/lyxgluelength.h:67: error: bool operator==(const LyXGlueLength&, const LyXGlueLength&) ../../../src/Spacing.h:76: error: bool operator==(const Spacing&, const Spacing&) ../../../src/Bullet.h:48: error: bool operator==(const Bullet&, const Bullet&) ../../../src/lyxfont.h:438: error: bool operator==(const LyXFont&, const LyXFont&) ../../../src/lyxfont.h:427: error: bool operator==(const LyXFont::FontBits&, const LyXFont::FontBits&) /usr/lib/qt/include/qcstring.h:299: error: bool operator==(const QCString&, const QCString&) /usr/lib/qt/include/qcstring.h:302: error: bool operator==(const QCString&, const char*) /usr/lib/qt/include/qcstring.h:305: error: bool operator==(const char*, const QCString&) /usr/lib/qt/include/qstring.h:303: error: bool operator==(char, QChar) /usr/lib/qt/include/qstring.h:308: error: bool operator==(QChar, char) /usr/lib/qt/include/qstring.h:313: error: bool operator==(QChar, QChar) /usr/lib/qt/include/qstring.h:1015: error: bool operator==(const QString&, const QString&) /usr/lib/qt/include/qstring.h:1022: error: bool operator==(const QString&, const char*) /usr/lib/qt/include/qstring.h:1028: error: bool operator==(const char*, const QString&) /usr/lib/qt/include/qpoint.h:148: error: bool operator==(const QPoint&, const QPoint&) /usr/lib/qt/include/qsize.h:162: error: bool operator==(const QSize&, const QSize&) /usr/lib/qt/include/qrect.h:151: error: bool operator==(const QRect&, const QRect&) make[5]: *** [QPrefs.lo] Error 1 make[5]: Leaving directory `/usr/local/src/lyx-1.3.6/src/frontends/qt2' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/usr/local/src/lyx-1.3.6/src/frontends/qt2' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/src/lyx-1.3.6/src/frontends' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/lyx-1.3.6/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/src/lyx-1.3.6/src' make: *** [all-recursive] Error 1 Remeber: lyx-1.3.5 compiled fine with the same options: any suggestions? best regards Costantino
Re: FreeBSD compilation problems with boost stuff
Lars Gullik Bjønnes wrote: > Rob <[EMAIL PROTECTED]> writes: > > | Hi, > > | There are few clashes with LyX's boost stuff on the FreeBSD system. > | I use compiler gcc 3.4.2. > > | 1. Following patch is needed to have cstdint.hpp compile without > |error message (I have tried to investigate where exactly uintmax_t > |is already defined on my system, but to no avail; I've already > |reported this some time ago). > > Can you report it to the boost list as well? > (your fix might be our breakage) > > | 2. After above patch, I now get following problems: > > | /usr/local/bin/g++34 -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost > | -I/opt/include -I/usr/local/include -I/usr/X11R6/include -Winvalid-pch > | --include=./pch.h > | -g -O -fno-exceptions -Wextra -Wall -c tostr.C -MT tostr.lo -MD -MP -MF > | .deps/tostr.TPlo -o tostr.o > | In file included from tostr.C:14: > | ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a > | member of `std' > > Hmm we define BOOST_NO_WSTRING in config.h so there should be no > way for you to get the "wstring" stuff at all. What gives? > Ok I see... there is a template3 specialization in lexical_cast that > is not protected by DISABLE_WIDE_CHAR_SUPPORT. > > I'll send a msg to the boost list about this one. Meanwhile I have communicated this to the boost list and got following two answers: - 1) Could be related to the following g++ problem. Scheduled to be fixed in gcc 3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17005 2) FreeBSD's wchar_t support is limited, so GCC does not enable any wide-char support in the C++ stdlib All uses of wstring/char_t/wstream etc. are be guarded by BOOST_NO_WSTRING so they aren't compiled on platforms without wchar support in the stdlib. BOOST_NO_WSTRING will get set automatically because the stdlib does not define _GLIBCXX_USE_WCHAR_T on FreeBSD. However, Boost 1.31 was released before GCC 3.4.1, which changed the stdlib macros from _GLIBCPP_blahblah to _GLIBCXX_blahblah and so Boost's config fails to configure correctly for this compiler. You could try taking the boost/config/stdlib/libstdcppv3.hpp header from CVS, but note that there are additional problems with GCC 3.4.x and Boost due to GCC 3.4 unconditionally defining _REENTRANT. See GCC PR 11953 for details. (I've written a summary of this issue, but it's sitting on my hard drive at home somewhere. I need to send it to this list...) In short, you must define either BOOST_DISABLE_THREADS or compile with -pthreads to avoid linker errors from the pthread_xxx functions. - Does that give a clue to you LyX/Boost gurus? Or will it be for FreeBSD just a matter of waiting for 3.5 to be released? Unfortunately, the soon upcoming release branch 5.X of FreeBSD ships with GCC 3.4.2. So the problem may persist for quite some time. Rob.
Re: FreeBSD compilation problems with boost stuff
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | | In file included from tostr.C:14: | | ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a | | member of `std' > | Hmm we define BOOST_NO_WSTRING in config.h so there should be no | way for you to get the "wstring" stuff at all. What gives? | Ok I see... there is a template3 specialization in lexical_cast that | is not protected by DISABLE_WIDE_CHAR_SUPPORT. Actually I don't see how this happens. Only a wchar_t is unguarded, and you get errors about wstring. Can you investigate a bit? -- Lgb
Re: FreeBSD compilation problems with boost stuff
Rob <[EMAIL PROTECTED]> writes: | Hi, > | There are few clashes with LyX's boost stuff on the FreeBSD system. | I use compiler gcc 3.4.2. > | 1. Following patch is needed to have cstdint.hpp compile without |error message (I have tried to investigate where exactly uintmax_t |is already defined on my system, but to no avail; I've already |reported this some time ago). Can you report it to the boost list as well? (your fix might be our breakage) | 2. After above patch, I now get following problems: > | /usr/local/bin/g++34 -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost | -I/opt/include -I/usr/local/include -I/usr/X11R6/include -Winvalid-pch | --include=./pch.h | -g -O -fno-exceptions -Wextra -Wall -c tostr.C -MT tostr.lo -MD -MP -MF | .deps/tostr.TPlo -o tostr.o | In file included from tostr.C:14: | ../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a | member of `std' Hmm we define BOOST_NO_WSTRING in config.h so there should be no way for you to get the "wstring" stuff at all. What gives? Ok I see... there is a template3 specialization in lexical_cast that is not protected by DISABLE_WIDE_CHAR_SUPPORT. I'll send a msg to the boost list about this one. -- Lgb
FreeBSD compilation problems with boost stuff
Hi,
There are few clashes with LyX's boost stuff on the FreeBSD system.
I use compiler gcc 3.4.2.
1. Following patch is needed to have cstdint.hpp compile without
error message (I have tried to investigate where exactly uintmax_t
is already defined on my system, but to no avail; I've already
reported this some time ago).
Index: boost/boost/cstdint.hpp
===
RCS file: /cvs/lyx/lyx-devel/boost/boost/cstdint.hpp,v
retrieving revision 1.5
diff -u -r1.5 cstdint.hpp
--- boost/boost/cstdint.hpp 2004/02/05 09:14:14 1.5
+++ boost/boost/cstdint.hpp 2004/09/08 11:26:07
@@ -118,7 +118,7 @@
typedef uint64_t uint_fast64_t;
typedef int64_t intmax_t;
- typedef uint64_t uintmax_t;
+// typedef uint64_t uintmax_t;
# else
2. After above patch, I now get following problems:
/usr/local/bin/g++34 -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost
-I/opt/include -I/usr/local/include -I/usr/X11R6/include -Winvalid-pch
--include=./pch.h
-g -O -fno-exceptions -Wextra -Wall -c tostr.C -MT tostr.lo -MD -MP -MF
.deps/tostr.TPlo -o tostr.o
In file included from tostr.C:14:
../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a member of `std'
../../boost/boost/lexical_cast.hpp:102: error: `wstring' is not a member of `std'
../../boost/boost/lexical_cast.hpp:103: error: template argument 1 is invalid
../../boost/boost/lexical_cast.hpp:103: error: explicit specialization of
non-template `'
../../boost/boost/lexical_cast.hpp:162: error: declaration of `operator>>' as
non-function
../../boost/boost/lexical_cast.hpp:162: error: expected `;' before '(' token
../../boost/boost/lexical_cast.hpp:168: error: expected `;' before "private"
Regards,
Rob.
Re: Compilation problems in CutAndPaste.C
On Wed, Jun 18, 2003 at 01:05:16PM +0200, Lars Gullik Bjønnes wrote: > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > | I get the following with gcc 2.95.2 and gcc 2.96: > [...] > | > | What can this be? > > Antiquated compilers with antiquated std libs. Short of requiring gcc-3, what is the fix? -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: Compilation problems in CutAndPaste.C
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I get the following with gcc 2.95.2 and gcc 2.96: [...] | | What can this be? Antiquated compilers with antiquated std libs. -- Lgb
Compilation problems in CutAndPaste.C
I get the following with gcc 2.95.2 and gcc 2.96: ../../lyx-devel/src/CutAndPaste.C: In function `vector > CutAndPaste::availableSelections (const Buffer &)': ../../lyx-devel/src/CutAndPaste.C:60: result of `operator->()' yields non-pointer result /usr/include/g++-3/stl_deque.h: In method `_Ptr _Deque_iterator<_Tp, _Ref, _Ptr, __bufsiz>::operator-> () const [with _Tp = pair, _Ref = const pair &, _Ptr = const pair &, unsigned int __bufsiz = 0]': ../../lyx-devel/src/CutAndPaste.C:60: instantiated from here /usr/include/g++-3/stl_deque.h:138: could not convert `this->_Deque_iterator, const pair &, const pair &, 0>::_M_cur' to `const pair &' make[3]: *** [CutAndPaste.o] Error 1 What can this be? JMarc
compilation problems
I have been trying to port LyX-1.1.6fix4 to a Hewlett-Packard workstation (HP-UX 10.20). There is a minor difficulty with configure: libXpm and perl are only recognized, if they can be found under /usr/local/lib or /usr/localbin, resp., irrespeective of what the configure flags (--with-extra-lib ...), the PERL variable, or the PATH variable are. The compilation (using gcc-3.0.1) succeeds, but the loader reports unsatisfies symbols and a segmentation fault: ld terminated with signal 11 [Segmentation fault] /usr/ccs/bin/ld: Unsatisfied symbols: virtual thunk to SigC::Object::~Object()(data) virtual thunk to SigC::Object::~Object()(data) virtual thunk to FormBase::~FormBase()(data) typeinfo for InsetButton(data) virtual thunk to FormBase::~FormBase()(data) Any ideas what is going wrong? Regards, Ulrich Deiters
Re: mathed compilation problems
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | cxx does not like inline methods without a definition: | | cxx: Error: ../../../lyx-devel/src/mathed/math_xiter.h, line 41: function | "MathedXIter::GetPos" was referenced but not defined | void GetPos(int &, int &) const; | -^ | cxx: Warning: ../../../lyx-devel/src/mathed/math_spaceinset.h, line 18: virtual | inline function "MathSpaceInset::Metrics" was never defined | inline void Metrics(); | ^ | cxx: Error: ../../../lyx-devel/src/mathed/math_spaceinset.h, line 20: | function "MathSpaceInset::SetSpace" was referenced but not defined | inline void SetSpace(int sp); | ^ | | Do these methods really need to be inline? If they do, then the | definition should be in the header. No these should not be marked as inline. Lgb
mathed compilation problems
cxx does not like inline methods without a definition: cxx: Error: ../../../lyx-devel/src/mathed/math_xiter.h, line 41: function "MathedXIter::GetPos" was referenced but not defined void GetPos(int &, int &) const; -^ cxx: Warning: ../../../lyx-devel/src/mathed/math_spaceinset.h, line 18: virtual inline function "MathSpaceInset::Metrics" was never defined inline void Metrics(); ^ cxx: Error: ../../../lyx-devel/src/mathed/math_spaceinset.h, line 20: function "MathSpaceInset::SetSpace" was referenced but not defined inline void SetSpace(int sp); ^ Do these methods really need to be inline? If they do, then the definition should be in the header. JMarc
Compilation problems in 1.1.6.pre2
Dear Listmembers, hopefully I do not bore you with too often answered questions, but anyway. I have scanned the mailing list archive but did not find any reference to my problem. I am using S.u.S.E Linux 7.0, xforms 0.88. I successfully ran configure: ./configure --prefix=/usr --bindir=/usr/bin/X11 During compilation I get the following message: make[2]: Entering directory `/home/work/lyx-1.1.6pre2/lib' ./build-listerrors . lyx: SIGSEGV signal caught Sorry, you have found a bug in LyX. If possible, please read 'Known bugs' under the Help menu and then send us a full bug report. Thanks! Bye. ./build-listerrors: line 24: 4729 Aborted$lyx --export literate $dir/examples/Literate.lyx make[2]: Leaving directory `/home/work/lyx-1.1.6pre2/lib' uname -a: Linux djunix 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 GMT 2000 i586 unknown version of libforms: 0.88 gcc -v gives me: gcc version 2.95.2 19991024 (release) what else could I provide? Any help is greatly appreciated; many thanks for your efforts (and your very nice program) in advance, take care Dieter Jurzitza --- E-Mail: Dr. Ing. Dieter Jurzitza <[EMAIL PROTECTED]> Date: 08-Jan-01 Time: 21:18:01 | \ /\_/\ | | ~x~ |/-\ / \ /- \_/ ^^__ _/ _ / <°°__ \- \_/ | |/| | || || _| _|_| _| if you really want to see the pictures above - use some font with constant spacing like courier! :-) --- config.log
Re: small compilation problems
Lior Silberman <[EMAIL PROTECTED]> writes: | Hello everyone, | | I have two small problems compiling CVS. | | 1. sigc++/thread.h doesn't include the declaration for struct timespec, | 2. in filedlg.C there is an inline function (GroupCache::find) which isn't | handled properly on compilation with -g. | | Details: | | I configure CVS with CXXFLAGS=-g (no -O), and --with-warnings so the | command is: | | g++ -DHAVE_CONFIG_H -I. -I.. -isystem /usr/X11R6/include -g -ansi -W -Wall | -Wno-return-type Can you add -Winline also? Also: we do not support compiles without optimizations. Gcc behaves strangely sometimes without -O and severeal errors are not reported. Unless you have a very good reason you should always use -O. Lgb
Re: small compilation problems
On Thu, 21 Sep 2000, Allan Rae wrote: > On Wed, 20 Sep 2000, Lior Silberman wrote: > > > 1. sigc++/thread.h doesn't include the declaration for struct timespec, > > Did you report this to libsigc++? I notice it's been fixed in their > repository so I'll do up a new sigc++ mini-dist. > > Allan. (ARRae) > > Allan Thanks! I didn't know sigc++ wasn't part of the LyX project, so I didn't report this to anyone before yesterday. Lior.
Re: small compilation problems
On Wed, 20 Sep 2000, Lior Silberman wrote: > 2. src/filedlg.C compiles ok, but during the link phase, I get: > filedlg.o: In function `LyXFileDlg::Reread(void)': > filedlg.C:245: undefined reference to `GroupCache::find(unsigned int) const > > I think this is beacuse g++ -g does not expand GroupCache::find inline, > and therefore it's missing from the object file. Compiling this file > separately with (-g -O) solves the problem. I wonder why this happens, > since there is no complaint about UserCache::find. > I have the exact same problem. I have to apply a patch to filedlg.C each time. Unfortunately no-one else on the list can see this (Except you ;) thanks john
Re: small compilation problems
On Wed, 20 Sep 2000, Lior Silberman wrote: > 1. sigc++/thread.h doesn't include the declaration for struct timespec, Did you report this to libsigc++? I notice it's been fixed in their repository so I'll do up a new sigc++ mini-dist. Allan. (ARRae)
small compilation problems
Hello everyone, I have two small problems compiling CVS. 1. sigc++/thread.h doesn't include the declaration for struct timespec, 2. in filedlg.C there is an inline function (GroupCache::find) which isn't handled properly on compilation with -g. Details: I configure CVS with CXXFLAGS=-g (no -O), and --with-warnings so the command is: g++ -DHAVE_CONFIG_H -I. -I.. -isystem /usr/X11R6/include -g -ansi -W -Wall -Wno-return-type 1. in sigc++/thread.h:124 , there is a declaration: int wait(Mutex &m, timespec* spec); but my compiler (egcs-2.91.66) complains: ../sigc++/thread.h:124: type specifier omitted for parameter The following works without a hitch: int wait(Mutex &m, struct timespec* spec); ^^ 2. src/filedlg.C compiles ok, but during the link phase, I get: filedlg.o: In function `LyXFileDlg::Reread(void)': filedlg.C:245: undefined reference to `GroupCache::find(unsigned int) const I think this is beacuse g++ -g does not expand GroupCache::find inline, and therefore it's missing from the object file. Compiling this file separately with (-g -O) solves the problem. I wonder why this happens, since there is no complaint about UserCache::find. Any ideas? Thanks, Lior.
Re: LyX 1.1.5: compilation problems on IBM AIX
> "Serge" == Serge Winitzki <[EMAIL PROTECTED]> writes: Serge> Line 361 of spellchecker.C contains Serge> FD_ZERO(&infds); Serge> I temporarily fixed it by adding "#include " to Serge> spellchecker.C (AIX's man page says this about bzero) but I'm Serge> not sure what's going on. That's IMO brokenness from AIX part (FD_ZERO uses bzero, but does not make sure it is defined), but I added that line. JMarc
LyX 1.1.5: compilation problems on IBM AIX
Hi, Trying to compile LyX release 1.1.5 on AIX... and getting a strange error message when compiling "spellchecker.C"; (please disregard this message if you already fixed this problem) spellchecker.C: In function `void create_ispell_pipe(const BufferParams &, const string &)': spellchecker.C:361: implicit declaration of function `int bzero(...)' Line 361 of spellchecker.C contains FD_ZERO(&infds); I temporarily fixed it by adding "#include " to spellchecker.C (AIX's man page says this about bzero) but I'm not sure what's going on. Regards, -- Serge
Re: Compilation problems
Jules Bean <[EMAIL PROTECTED]> writes: | Did you mean '...in only one function'? Yes. | I'm talking about having a simple using declaration for types referenced | in this file. I can't see that that's unacceptable. I am very fond of the idea of keeping the global namespace as clean as possible, I realize that with current compilers this is very hard, but I still find it a nice goal. So when putting "things" into a namespace, be it global or other we keep the scope of that alias as small as possible. | There are lots of actions you take in C++ which bring things into your | namespace. Every header file you include typically puts hundreds of | symbols into your namespace, so I can't see why you shouldn't put a simple | declaration which imports 1, or 2, or 3, symbols.. Perhaps not. | But, it's you project ;-) You set the coding rules, I'll follow them if I | submit a patch... Please :-) Lgb
Re: Compilation problems
On 3 Feb 2000, Lars Gullik Bjønnes wrote: > > | I'm talking about having a simple using declaration for types referenced > | in this file. I can't see that that's unacceptable. > > I am very fond of the idea of keeping the global namespace as clean as > possible, I realize that with current compilers this is very hard, but > I still find it a nice goal. > > So when putting "things" into a namespace, be it global or other we > keep the scope of that alias as small as possible. (last word on this one, I promise to keep quiet now) The compromise is between clean namespace (which is very desirable, a dirty namespace will result in hard-to-track down bugs) and programmer efficiency. Anyone who has programmed java will know how much of a pain it is to type java.util.Vector all the time, and will probably have used import java.util.Vector --- or even the very eveil import java.util.* (I've done it ;-) Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Compilation problems
On 3 Feb 2000, Lars Gullik Bjønnes wrote: > Jules Bean <[EMAIL PROTECTED]> writes: > > | Surely it's perfectly acceptable to have > | > | using std::vector; > | > | at the top of a file (in filescope). > > Not if you use that vector in only one file. Did you mean '...in only one function'? I'm talking about having a simple using declaration for types referenced in this file. I can't see that that's unacceptable. There are lots of actions you take in C++ which bring things into your namespace. Every header file you include typically puts hundreds of symbols into your namespace, so I can't see why you shouldn't put a simple declaration which imports 1, or 2, or 3, symbols.. But, it's you project ;-) You set the coding rules, I'll follow them if I submit a patch... Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Compilation problems
Jules Bean <[EMAIL PROTECTED]> writes: | Surely it's perfectly acceptable to have | | using std::vector; | | at the top of a file (in filescope). Not if you use that vector in only one file. | That simply says 'in this file, I wish to introduce the type 'std::vector' | into my namespace'. That's directly comparable to what is says is "in this file I am using vector as an alias to std::vector" | extern int g_happy; | | which means 'in this file, I wish to introduce the variable g_happy into | my namespace'. not really. Lgb
Re: Compilation problems
On 28 Jan 2000, Lars Gullik Bjønnes wrote: > Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: > > | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: > | > | Lars> mmm...I want to do that...but so far I have not dared. > | Lars> Eventually "using" should not be used in headers at all, and as > | Lars> little as possible in filescope. > | > | You mean we'll be forced to add std:: in front of all STL identifiers? > | Yuck. > > No, but when I have a small func it is much more convenient to use the > std:: prefix. > > For longer funcs and inline code in headers "using" should be used in > the function body. > > Only as an exception should a "using" be used at filescope. > (and never in headers) Surely it's perfectly acceptable to have using std::vector; at the top of a file (in filescope). That simply says 'in this file, I wish to introduce the type 'std::vector' into my namespace'. That's directly comparable to extern int g_happy; which means 'in this file, I wish to introduce the variable g_happy into my namespace'. Jules /+---+-\ | Jelibean aka | [EMAIL PROTECTED] | 6 Evelyn Rd| | Jules aka | [EMAIL PROTECTED] | Richmond, Surrey | | Julian Bean | [EMAIL PROTECTED]| TW9 2TF *UK* | ++---+-+ | War doesn't demonstrate who's right... just who's left. | | When privacy is outlawed... only the outlaws have privacy. | \--/
Re: Compilation problems
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> mmm...I want to do that...but so far I have not dared. | Lars> Eventually "using" should not be used in headers at all, and as | Lars> little as possible in filescope. | | You mean we'll be forced to add std:: in front of all STL identifiers? | Yuck. No, but when I have a small func it is much more convenient to use the std:: prefix. For longer funcs and inline code in headers "using" should be used in the function body. Only as an exception should a "using" be used at filescope. (and never in headers) Lgb
Re: Compilation problems
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> mmm...I want to do that...but so far I have not dared. Lars> Eventually "using" should not be used in headers at all, and as Lars> little as possible in filescope. You mean we'll be forced to add std:: in front of all STL identifiers? Yuck. JMarc
Re: Compilation problems
Dekel Tsur <[EMAIL PROTECTED]> writes: | What I meant was that instead of |using std::copy; |using std::ostream_iterator; |copy(files.begin(), files.end(), |ostream_iterator(ofs, "\n")); | | you can write |std::copy(files.begin(), files.end(), |std::ostream_iterator(ofs, "\n")); | mmm...I want to do that...but so far I have not dared. Eventually "using" should not be used in headers at all, and as little as possible in filescope. Lgb
Re: Compilation problems
On Wed, Jan 26, 2000 at 11:39:53AM +0100, Jean-Marc Lasgouttes wrote: > > "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: > > Dekel> I can't compile the latest cvs because of the using declaration > Dekel> in lastfiles.C:85 and table.C:746 (I use an old g++ - ver. > Dekel> 2.90.29) This can the fixed by moving the using declarations to > Dekel> the global scope, or stop using 'using' (std::copy etc. are > Dekel> only used once, so the 'using' declaration is unnecessary) > > What message are you getting? Does moving the 'using' directive at the > beginning of the file (in global scope) help? > lastfiles.C: In method void LastFiles::writeFile(const class lyxstring &) lastfiles.C:85: parse error before using' Moving the 'using' to the global scope does solve the problem. > We need these directives because all STLs (notably older ones) do not > declare objects in std::. > What I meant was that instead of using std::copy; using std::ostream_iterator; copy(files.begin(), files.end(), ostream_iterator(ofs, "\n")); you can write std::copy(files.begin(), files.end(), std::ostream_iterator(ofs, "\n"));
Re: Compilation problems
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes: Dekel> I can't compile the latest cvs because of the using declaration Dekel> in lastfiles.C:85 and table.C:746 (I use an old g++ - ver. Dekel> 2.90.29) This can the fixed by moving the using declarations to Dekel> the global scope, or stop using 'using' (std::copy etc. are Dekel> only used once, so the 'using' declaration is unnecessary) What message are you getting? Does moving the 'using' directive at the beginning of the file (in global scope) help? We need these directives because all STLs (notably older ones) do not declare objects in std::. JMarc
Compilation problems
I can't compile the latest cvs because of the using declaration in lastfiles.C:85 and table.C:746 (I use an old g++ - ver. 2.90.29) This can the fixed by moving the using declarations to the global scope, or stop using 'using' (std::copy etc. are only used once, so the 'using' declaration is unnecessary)
Re: Compilation problems with cvs 99/01/24
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | Michael> I would like to have __GLIBCPP__ defined in about line 100 | Michael> and 120 (because the other code is not correct - says Sun CC | Michael> 5.0) | | We should probably have a better code the this ad-hoc ifdef, anyway. | Lars, could you explain why this is here? Because the libstdc++ don't support cctype correctly yet. I commented out the (preferred) transforms so now we use the manually coded transforms instead. Lgb
Re: Compilation problems with cvs 99/01/24
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes: Michael> a few suggestions for/from the Sun CC compiler: Michael> src/insets/figinset.C, add Michael>using std::flush; Done. Michael> src/support/lstrings.C, Michael> I would like to have __GLIBCPP__ defined in about line 100 Michael> and 120 (because the other code is not correct - says Sun CC Michael> 5.0) We should probably have a better code the this ad-hoc ifdef, anyway. Lars, could you explain why this is here? JMarc
Compilation problems with cvs 99/01/24
Hi, a few suggestions for/from the Sun CC compiler: src/insets/figinset.C, add using std::flush; src/support/lstrings.C, I would like to have __GLIBCPP__ defined in about line 100 and 120 (because the other code is not correct - says Sun CC 5.0) Michael -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de == S/MIME Cryptographic Signature
Compilation problems
Dear Jean Marc, on Fri Jan 7 21:08:23 MET 2000 I checked out lyx-devel to see whether it works better than before. Unfortunately, I still have a lot of problems with lyx-devel. These are more or less the same as before. Below, I resend a current list to you. More severe, I cannot link lyx any more. I get a long list of errors like these: ild: (error) std::numeric_limits::radix is defined in files mathed/libmathed.o and insets/libinsets.o ild: (error) __timer_gettime is defined in files mathed/libmathed.o and insets/libinsets.o ild: (error) _ltzset is defined in files mathed/libmathed.o and insets/libinsets.o When generating libmathed.o, the following messages are printed on screen: /bin/sh ../../libtool --mode=link CC -v +p +w2 -compat=5 -g -L/opt/local/lib -R/opt/local/lib -o libmathed.o formula.o formulamacro.o math_cursor.o math_delim.o math_draw.o math_forms.o math_hash.o math_inset.o math_iter.o math_macro.o math_panel.o math_parser.o math_root.o math_symbols.o math_utils.o math_write.o libtool: link: warning: `-l' and `-L' are ignored for objects libtool: link: warning: `-R' is ignored for objects CC -r -o libmathed.o formula.o formulamacro.o math_cursor.o math_delim.o math_draw.o math_forms.o math_hash.o math_inset.o math_iter.o math_macro.o math_panel.o math_parser.o math_root.o math_symbols.o math_utils.o math_write.o Somebody must have changed the code for combining object files in the past few days. Please also note that I get a lot of warnings like CC: Warning: Option -Wp,-MD,.deps/math_draw.pp passed to ld, if ld is invoked, ignored otherwise I think it is a little bit optimistic to asssume that everybody is using gcc. Good news: I will be out of office for the next 7 days. Hence no bug reports, no complaints :+) Michael PS: Has anybody looked into my mail called "Bug reports - No.3" posted to the mailing list? I think it includes a really serious bug. lyx_lex.h, line 16, add using std::istream; mathed/math_defs.h, line 32, add using std::istream; mathed/math_symbols. line 542: char * sx = const_cast(strstr(data[2], "")); support/filetools.C, line 328 int retval = putenv(const_cast(envstr.c_str())); (the macro produces "const char *") support/lstrings.h, line 11, add using std::size_t; support/lstring.C, line 115 (and some lines below again) this construct is invalid, probably because "tolower" returns int not char; the other macro alternative works perfectly even without GCCLIB support/lyxsum.C, line 23, add using std::FILE; using std::fopen; using std::fread; using std::fclose; using std::ferror; layout.C, lines 1217 and 1246, change return make_pair(true, static_cast(cit - classlist.begin())); return make_pair(true, LyXTextClass::LayoutList::size_type(LYX_DUMMY_LAYOUT)); (choose one of the two notations) lyx_gui_misc.C, line 413, change return make_pair(true, string(tmp)); ... and of course the old "kill" function problem in various files (no standard function in ). -- == Michael Schmittphone: +49 451 500 3725 Institute for Telematics secretary: +49 451 500 3721 Medical University of Luebeck fax: +49 451 500 3722 Ratzeburger Allee 160 eMail: [EMAIL PROTECTED] D-23538 Luebeck, Germany WWW: http://www.itm.mu-luebeck.de == S/MIME Cryptographic Signature
Re: Compilation problems
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes: Michael> SUN CC complains about a few more problems in the lyx-devel Michael> code dated Thu Jan 6 20:11:07 MET 2000. Please find a summary Michael> of necessary fixes below. Michael> Michael Michael> lyx_lex.h, line 16, add Michael> using std::istream; I just did. Will commit in a minute. Michael> mathed/math_defs.h, line 32, add Michael> using std::istream; ditto. Michael> mathed/math_parser.C, line 141 + line 170, change Michael> char c; // not unsigned! Lars has fixed this code yesterday evening. Please try again. Michael> support/filetools.C, line 328 Michael> int retval = putenv(const_cast(envstr.c_str())); Michael> (the macro does not work on SUN Solaris 7) That's a pity, since the macro was put there just for Solaris7 :( Could you tell me what is the value of this macro on solaris7? And what it should be? Michael> support/lstring.C, line 115 (and some lines below again) Michael> this construct is invalid, probably because "tolower" Michael> returns int not char; the other macro alternative works Michael> perfectly even without GCCLIB Michael> support/lyxsum.C, line 23, add Michael> using std::FILE; using std::fopen; using std::fread; using Michael> std::fclose; using std::ferror; I have no yet done these, because compaq cxx would not like it... I have to find a solution which would satisfy both compilers. I let lars answer to the others, since I am not sure of what good solution we should use. Michael> For some reason, a file called libsupport.la is generated in Michael> directory "support". However, this file should be called Michael> libsupport.o. (did not happen a few days ago) This should be gone in latest cvs. Michael> Besides, I get a lot of warnings. I already sorted out a Michael> bunch of messages... I'll try to look at them later. JMarc
Compilation problems
Hello, SUN CC complains about a few more problems in the lyx-devel code dated Thu Jan 6 20:11:07 MET 2000. Please find a summary of necessary fixes below. Michael lyx_lex.h, line 16, add using std::istream; mathed/math_defs.h, line 32, add using std::istream; mathed/math_parser.C, line 141 + line 170, change char c; // not unsigned! support/filetools.C, line 328 int retval = putenv(const_cast(envstr.c_str())); (the macro does not work on SUN Solaris 7) support/lstring.C, line 115 (and some lines below again) this construct is invalid, probably because "tolower" returns int not char; the other macro alternative works perfectly even without GCCLIB support/lyxsum.C, line 23, add using std::FILE; using std::fopen; using std::fread; using std::fclose; using std::ferror; (probably already fixed but not checked in) support/lstrings.h, line 11, add using std::size_t; layout.C, lines 1217 and 1246, change return make_pair(true, static_cast(cit - classlist.begin())); return make_pair(true, LyXTextClass::LayoutList::size_type(LYX_DUMMY_LAYOUT)); (choose one of the two notations) lyx_gui_misc.C, line 413, change return make_pair(true, string(tmp)); lyx_lex.C, line 200 + 253 + 335 + 449, change to (signed) char line 300: warning is not accepted For some reason, a file called libsupport.la is generated in directory "support". However, this file should be called libsupport.o. (did not happen a few days ago) Besides, I get a lot of warnings. I already sorted out a bunch of messages... "LaTeX.C", line 496: Warning: tmp hides the same name in an outer scope. "figinset.C", line 171: Warning: i hides the same name in an outer scope. "figinset.C", line 2059: Warning: pflags hides InsetFig::pflags. "figinset.C", line 589: Warning: p hides the same name in an outer scope. "filetools.C", line 364: Warning: Could not find source for std::remove(const char*). "formula.C", line 1050: Warning: result hides the same name in an outer scope. "lstrings.C", line 123: Warning: Could not find source for std::toupper(int). "lstrings.C", line 35: Warning: Could not find source for std::tolower(int). "lyxlex.h", line 140: Warning: There are two consecutive underbars in "fb__". "math_iter.h", line 262: Warning: MathedXIter::SetData hides the function MathedIter::SetData(LyxArrayBase*). "math_write.C", line 194: Warning: l hides the same name in an outer scope. "vspace.h", line 149: Warning: LyXGlueLength::operator== hides the function LyXLength::operator==(const LyXLength&) const. "buffer.C", line 1378: Warning: Could not find source for std::remove(const char*). "buffer.C", line 140: Warning: lyxrc hides the same name in an outer scope. "bufferlist.C", line 213: Warning: Could not find source for std::remove(const char*). "bufferlist.C", line 68: Warning: lyxrc hides the same name in an outer scope. "lyx_cb.C", line 1084: Warning: Could not find source for std::remove(const char*). "lyx_sendfax_main.C", line 127: Warning: Could not find source for std::remove(const char*). "lyxfont.C", line 504: Warning: tok hides the same name in an outer scope. "lyxfont.C", line 508: Warning: tok hides the same name in an outer scope. "lyxfont.C", line 512: Warning: tok hides the same name in an outer scope. "lyxfont.C", line 516: Warning: tok hides the same name in an outer scope. "lyxfont.C", line 520: Warning: tok hides the same name in an outer scope. "lyxfont.C", line 531: Warning: tok hides the same name in an outer scope. "lyxfont.C", line 550: Warning: tok hides the same name in an outer scope. "lyxfont.C", line 890: Warning: Could not find source for std::toupper(int). "lyxfr1.C", line 339: Warning: Could not find source for std::toupper(int). "lyxfunc.C", line 2220: Warning: new_inset hides the same name in an outer scope. "lyxlex.h", line 140: Warning: There are two consecutive underbars in "fb__". "paragraph.C", line 2712: Warning: tmp hides the same name in an outer scope. "paragraph.C", line 2919: Warning: depth hides LyXParagraph::depth. "paragraph.C", line 2961: Warning: The variable column has not yet been assigned a value. "paragraph.C", line 333: Warning: layout hides LyXParagraph::layout. "paragraph.C", line 4026: Warning: style hides the same name in an outer scope. "paragraph.C", line 4061: Warning: style hides the same name in an outer scope. "paragraph.C", line 958: Warning: layout hides LyXParagraph::layout. "text.C", line 2848: Warning: Could not find source for std::tolower(int). "text.C", line 2851: Warning: Could not find source for std::toupper(int). "text.C", line 3172: Warning: tmpheight hides the same name in an outer scope. "text.C", line 3262: Warning: font hides the same name in an outer scope. "text.C", line 3264: Warning: x hides the same name in an outer scope. "text.C", line 3271: Warning: font hides the same name in an outer scope. "text.C", line 3350: Warning: font hides the same name in an outer scope. "text2.C", line 1943: Warning: tmppar h
Re: Some compilation problems with latest cvs
On Thu, Oct 14, 1999 at 02:58:53PM +0200, Lars Gullik Bjønnes wrote: > John Weiss <[EMAIL PROTECTED]> writes: > > | I'm sure there are other features that haven't made it into every > | compiler yet. There are things which you can safely assume are now in > | every C++ compiler currently in use. There are other things, features > | only recently agreed upon by the ANSI committee, that haven't made > | their way in. > > Ah you mean "recently" as in "at least two years ago". :-) Unfortunately, yes. We moan about this all the time at work... -- John Weiss
Re: Some compilation problems with latest cvs
> If you'd ask me (And I'm pretty sure, you won't ;-| ): Make a single > stable release and start over from scratch. The *last* step would be to > add compatibility to the existent LyX. I always thought that's what was > intented with the old 1.1 branch? We tried that, but it didn't work. We do not have the resources to pull such a stunt through. So, now we do it in a different way that is better suited to the resources we have. Please join us in this work. Just start with a random header file, and read it. Then read the implementation, and document the header file. Maybe rename a few functions to better names, and maybe move stuff into other files that are more logical. That is easy to do, and does not require a deep understanding of LyX. And if you do this, the source will slowly be much easier to deal with. So please stop complaining and do some work. Lgb is saying that he wants to use real C++, but if you look at the source, it's not poluted with partial specialization, dynamic_cast and other stuff at all. Jean-Marc is struggling hard to get LyX to compile with DEC cxx. And when we discover a problem, we will work around it. Regarding the requirement for autoconf, automake, and gettext: We require those tools in order to allow things to be simpler. Greets, Asger
Re: Some compilation problems with latest cvs
"Andre' Poenitz" <[EMAIL PROTECTED]> writes: | > Lars> And gcc 2.8.1 shows again that it is not suited for serious C++ | > Lars> development... | > | > Somehow I knew you would say that :) | | | Me too. | = AOL | | Using bleeding edge features is *not* "serious C++ development". What bleeding edege? What you call bleeding edge in C++ was put into the draft standard for the most part over 3 years ago, and a lot of the things years before that. The standard was finished 1.5 years ago, and ratified by ANSI 1 year ago. | Serious C++ development is about modularization, lean interfaces, | design of re-usable code and stuff like that. And? What about: adhereing to a standard, portable, ease to maintain, planning for future expansion. We can't just we can't just write for GCD for ever. | Hell, you can do | "serious C++ development" in any programming language. No you can't... You can to your analyse and other pre coding development on a piece of paper, but that still don't make it C++. | But what is | currently done is far from that. My perception of the "development | process" is that five percent of the developers sprinkle bleeding edge | stuff all over the code, twenty percent try to work | around them because they have to use non-conforming compilers and the | rest struggles to keep up. This is far, far from efficient. Actaully we don't have much problems with compilers... it is some, but most of this is easy or neccessary to workaround anyway. | There are quite a few thing I'd like to improve on lyx, I'd like to have | full xfig support, "native" inclusion of .gif and .tiff, a decent file | format and things like that. Feel free to begin something like this at any time. | I have downloaded the latest CVS tree about | two dozen times now, even started a bit of coding now and then - of | course after a round of installing new stuff (be it a new autoconfig or | a new compiler) most of the time. This must have been a 10 min effort every time...Lyx has not changed in that respect in the last 1.5 years. Until very recently. [...noise...] | If you'd ask me (And I'm pretty sure, you won't ;-| ): Make a single | stable release and start over from scratch. The *last* step would be to | add compatibility to the existent LyX. I always thought that's what was | intented with the old 1.1 branch? Ever wondered why the old 1.1.x branch never took off? It existed for more than a year you know... Do you want to begin a ~70k lines project from scratch? | And no, I won't stop using LyX, because it does a pretty good job for | the things I need to do: write texts with math. But I won't stop | complaining either since I don't like to see valuable resources | (the developer's - i.e. YOUR! - work) wasted. Non-developers complaining about development style/ progression / coding style are just noise to me. Lgb
Re: Some compilation problems with latest cvs
> Lars> And gcc 2.8.1 shows again that it is not suited for serious C++ > Lars> development... > > Somehow I knew you would say that :) Me too. Using bleeding edge features is *not* "serious C++ development". Serious C++ development is about modularization, lean interfaces, design of re-usable code and stuff like that. Hell, you can do "serious C++ development" in any programming language. But what is currently done is far from that. My perception of the "development process" is that five percent of the developers sprinkle bleeding edge stuff all over the code, twenty percent try to work around them because they have to use non-conforming compilers and the rest struggles to keep up. This is far, far from efficient. There are quite a few thing I'd like to improve on lyx, I'd like to have full xfig support, "native" inclusion of .gif and .tiff, a decent file format and things like that. I have downloaded the latest CVS tree about two dozen times now, even started a bit of coding now and then - of course after a round of installing new stuff (be it a new autoconfig or a new compiler) most of the time. But I usually get fed up after a couple of hours since the sources are in a really pitiful state. Implementation of a single function is usually spread over half a dozen files, each written in a complete different coding style, internal interfaces and the GUI is a mess,... (etc ad nauseam). If you'd ask me (And I'm pretty sure, you won't ;-| ): Make a single stable release and start over from scratch. The *last* step would be to add compatibility to the existent LyX. I always thought that's what was intented with the old 1.1 branch? And no, I won't stop using LyX, because it does a pretty good job for the things I need to do: write texts with math. But I won't stop complaining either since I don't like to see valuable resources (the developer's - i.e. YOUR! - work) wasted. Andre' PS: It's Friday, you know ;-) -- Andre' Poenitz, TU Chemnitz, Fakultaet fuer Mathematik [EMAIL PROTECTED] ... +49 3727 58 1381
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> And? The cvs repository on aussie is the same as on | Lars> baywatch...ok you have a problem with the repository named in | Lars> CVS/ ok lets have reboot of baywatch and see if that fixes the | Lars> problem. | | OK, I did not know that aussie was a cvs server too. | | BTW, if I were to install ssh (just client, I guess), what version | should I use? I am a bit lost. Use the newst 2.x Anyway aussie and baywatch should be able to handle both 1.x and 2.x versions of ssh. Lgb
Re: Some compilation problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> And? The cvs repository on aussie is the same as on Lars> baywatch...ok you have a problem with the repository named in Lars> CVS/ ok lets have reboot of baywatch and see if that fixes the Lars> problem. OK, I did not know that aussie was a cvs server too. BTW, if I were to install ssh (just client, I guess), what version should I use? I am a bit lost. JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> We need to fix the check for std::string it is not good. I am | Lars> not sure what we should have it do instead. | | I do not know either... | | Lars> Test if std:: is allowed first? and then depending use stack or | Lars> std::stack | | Another idea is to test whether using works first. I suspect that | some compilers which do not support namespaces have using as a no-op. That is what I mean by the test for std:: was just a bit vague. And some compilers that supports namespaces have std:: as a no op, they allow it but does not act on it...so you can mix std::stack and stack freely. (egcs, gcc 2.95) | Lars> | The C header wrappers thing is something I intend to commit | Lars> when | I have access to cvs. | | Lars> You have access to cvs. | | No, because I (still) rely on rsh. And? The cvs repository on aussie is the same as on baywatch...ok you have a problem with the repository named in CVS/ ok lets have reboot of baywatch and see if that fixes the problem. Lgb
Re: Some compilation problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> We need to fix the check for std::string it is not good. I am Lars> not sure what we should have it do instead. I do not know either... Lars> Test if std:: is allowed first? and then depending use stack or Lars> std::stack Another idea is to test whether using works first. I suspect that some compilers which do not support namespaces have using as a no-op. Lars> | The C header wrappers thing is something I intend to commit Lars> when | I have access to cvs. Lars> You have access to cvs. No, because I (still) rely on rsh. JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> What does LyX' configure say about template support on cxx? What | Lars> about mutable? | | checking if C++ compiler supports mutable... yes | checking if C++ compiler supports partial specialization... yes | checking whether the C++ compiler understands explicit... yes | checking for broken STL stack template... yes | checking for std/bastring.h... no | checking for correct namespaces support... yes | checking for C headers wrappers... no | checking whether the C++ compiler supports RTTI... yes This seems quite good actually. We need to fix the check for std::string it is not good. I am not sure what we should have it do instead. Of course if we had a unit test for our lyxstring we could use that to test if the std::string has the needed methods and behaviour :-) | Note that the stack test is bogus, since it uses stack instead of | std::stack. Test if std:: is allowed first? and then depending use stack or std::stack | The C header wrappers thing is something I intend to commit when | I have access to cvs. You have access to cvs. Lgb
Re: Some compilation problems with latest cvs
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> What does LyX' configure say about template support on cxx? What Lars> about mutable? checking if C++ compiler supports mutable... yes checking if C++ compiler supports partial specialization... yes checking whether the C++ compiler understands explicit... yes checking for broken STL stack template... yes checking for std/bastring.h... no checking for correct namespaces support... yes checking for C headers wrappers... no checking whether the C++ compiler supports RTTI... yes Note that the stack test is bogus, since it uses stack instead of std::stack. The C header wrappers thing is something I intend to commit when I have access to cvs. JMarc
Re: Some compilation problems with latest cvs
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | | Lars> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | | Lars> Lars> Program that I'd like to have tested: (checks for anon | | Lars> Lars> namespaces in global/file scope) | | Digital cxx 6.1: | Lars> works (in all modes) | | Lars> Ok...so cxx is not too bad... | | Isn't it? Let's run some more tests on it. What does LyX' configure say about template support on cxx? What about mutable? Ad. the include issue...many compiler have problems with this and gcc's solution is just a hack until they begin requiring the std:: namespace. | Lars> | gcc 2.8.1: does not work; error message is "sorry, not | Lars> implemented: | namespace" :) | | Lars> And gcc 2.8.1 shows again that it is not suited for serious C++ | Lars> development... | | Somehow I knew you would say that :) My standard answer when it comes to 2.8.1 :-) Lgb
