Le 20/11/2020 à 16:34, Kornel Benko a écrit :
Fixed at 5474c3fb
Sorry about that. A last minute change.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Fri, 20 Nov 2020 16:24:32 +0100
schrieb Kornel Benko :
> Compiled with --std=c++17
>
> /usr2/src/lyx/lyx-git/src/frontends/qt/GuiView.cpp: In member function ‘void
> lyx::frontend::GuiView::updateDialogs()’:
> /usr2/src/lyx/lyx-git/src/frontends/qt/GuiView.cpp:4903:2:
> warning: this ‘for’ cl
Compiled with --std=c++17
/usr2/src/lyx/lyx-git/src/frontends/qt/GuiView.cpp: In member function ‘void
lyx::frontend::GuiView::updateDialogs()’:
/usr2/src/lyx/lyx-git/src/frontends/qt/GuiView.cpp:4903:2:
warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
for(auto const &
dl
Le 28 juillet 2018 01:33:24 GMT+02:00, "Uwe Stöhr" a écrit :
>After a long time I could compile LyX. While the 2.3.x branch works
>well, I get these compilation errors in current master:
>
> D:\LyXGit\Master\src\insets\InsetTabular.cpp(6575): error C2664:
>'void
Am Samstag, den 28.07.2018, 01:33 +0200 schrieb Uwe Stöhr:
> After a long time I could compile LyX. While the 2.3.x branch works
> well, I get these compilation errors in current master:
Should be fixed now.
Jürgen
signature.asc
Description: This is a digitally signed message part
After a long time I could compile LyX. While the 2.3.x branch works
well, I get these compilation errors in current master:
D:\LyXGit\Master\src\insets\InsetTabular.cpp(6575): error C2664:
'void lyx::swap(lyx::Counters &,lyx::Counters &)': cannot convert
argument 1 fro
Am Dienstag, 2. Januar 2018 um 16:05:38, schrieb Jean-Marc Lasgouttes
> Le 02/01/2018 à 07:40, Kornel Benko a écrit :
> > Regarding the error message
> > "class lyx::frontend::Application * __cdecl lyx::theApp(void)"
> > is referenced. But we declare in dummy_dunctions.cpp
> > "struct {bo
Le 02/01/2018 à 07:40, Kornel Benko a écrit :
Regarding the error message
"class lyx::frontend::Application * __cdecl lyx::theApp(void)"
is referenced. But we declare in dummy_dunctions.cpp
"struct {bool cancel_export;} * theApp()"
So maybe this is the conflict?
I think you git
Am Montag, 1. Januar 2018 um 16:39:23, schrieb Uwe Stöhr
> El 23.12.2017 a las 08:23, Uwe Stöhr escribió:
>
> > I regenerated CMake and built LyX from scratch and the problem persists.
> > If I undo the changes to SystemCall*.cpp/.h from commit
> >
> > 165c9e92a400e8fdc00ef3e74eb68b34bfbcc6d5
>
El 23.12.2017 a las 08:23, Uwe Stöhr escribió:
I regenerated CMake and built LyX from scratch and the problem persists.
If I undo the changes to SystemCall*.cpp/.h from commit
165c9e92a400e8fdc00ef3e74eb68b34bfbcc6d5
it compiles fine.
I reported this compilation error now:
https://www.lyx.o
I regenerated CMake and built LyX from scratch and the problem persists.
If I undo the changes to SystemCall*.cpp/.h from commit
165c9e92a400e8fdc00ef3e74eb68b34bfbcc6d5
it compiles fine.
regards Uwe
El 23.12.2017 a las 04:07, Richard Heck escribió:
I don't know why that is supposed to be unsafe, but I've fixed it.
Thanks.
I've sent a separate note about that one. I do not know the test code
well enough to fix this myself.
You could try adding this to both files:
struct App {
b
On 12/22/2017 02:56 PM, Uwe Stöhr wrote:
> After the recent changes I get 2 compilation errors and 2 warnings:
>
> 2 warnings:
> D:\LyXGit\Master\src\LaTeX.cpp(420): warning C4805: '|=': unsafe mix
> of type 'bool' and type 'int' in operation
> [D:\L
After the recent changes I get 2 compilation errors and 2 warnings:
2 warnings:
D:\LyXGit\Master\src\LaTeX.cpp(420): warning C4805: '|=': unsafe mix of
type 'bool' and type 'int' in operation
[D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
D:\LyXGit\Master\src
Am 05.03.2017 um 08:48 schrieb Guillaume Munch:
git grep LyXToolBox does not return anything. Probably the build is not
clean.
Hi Guillaume,
thanks for having a look. I already deleted the CMake cache. Now I
updated CMake to the latest version and again deleted its cache and now
it works.
Le 05/03/2017 à 03:27, Uwe Stöhr a écrit :
I compiled today's master and get an error:
xgettext: error while opening "src/frontends/qt4/LyXToolBox.cpp" for
reading: No such file or directory
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5): error
MSB6006:
I compiled today's master and get an error:
xgettext: error while opening "src/frontends/qt4/LyXToolBox.cpp" for
reading: No such file or directory
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" wurde mit dem Code 1 beendet.
Am 24.09.2016 um 00:52 schrieb Guillaume Munch:
Should be fixed now.
Many thanks Guillaume. It works now.
regards Uwe
Le 24/09/2016 à 00:40, Uwe Stöhr a écrit :
with today's git master i get this:
TexRow.cpp
D:\LyXGit\Master\src\TexRow.cpp(68): error C3861: 'back_inserter':
identifier not found [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
D:\LyXGit\Master\src\TexRow.cpp(185): error C3861: 'back_inserter':
Le 24/09/2016 à 00:40, Uwe Stöhr a écrit :
with today's git master i get this:
TexRow.cpp
D:\LyXGit\Master\src\TexRow.cpp(68): error C3861: 'back_inserter':
identifier not found [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
D:\LyXGit\Master\src\TexRow.cpp(185): error C3861: 'back_inserter':
with today's git master i get this:
TexRow.cpp
D:\LyXGit\Master\src\TexRow.cpp(68): error C3861: 'back_inserter':
identifier not found [D:\LyXGit\Master\compile-2015\src\LyX.vcxproj]
D:\LyXGit\Master\src\TexRow.cpp(185): error C3861: 'back_inserter':
identifier not found [D:\LyXGit\Master\com
Am 08.12.2015 um 02:40 schrieb Kornel Benko:
Try this patch.
With a clean tree I applied the attached cmake patch. Now CXX11 is true
but I get many of these compilation errors:
"D:\LyXGit\Master\compile-2013\lyx.sln" (ALL_BUILD Ziel) (1) ->
"D:\LyXGit\M
Am Dienstag, 8. Dezember 2015 um 02:38:10, schrieb Uwe Stöhr
> Am 08.12.2015 um 02:30 schrieb Kornel Benko:
>
> > We have to set also CXX11COMPILER_FOUND
> >
> > set(LYX_USE_CXX11 1)
> > set(CXX11_FLAG "")
> > set(CXX11COMPILER_FOUND 1)
>
> This doesn't solve the problem.
>
> defined(LYX_USE_CXX11
Am 08.12.2015 um 02:30 schrieb Kornel Benko:
We have to set also CXX11COMPILER_FOUND
set(LYX_USE_CXX11 1)
set(CXX11_FLAG "")
set(CXX11COMPILER_FOUND 1)
This doesn't solve the problem.
defined(LYX_USE_CXX11)
is still false in regex.h
regards Uwe
Am Dienstag, 8. Dezember 2015 um 02:20:25, schrieb Kornel Benko
> Am Dienstag, 8. Dezember 2015 um 02:09:55, schrieb Uwe Stöhr
>
> > Am 08.12.2015 um 02:07 schrieb Uwe Stöhr:
> >
> > > I applied Kornel's patch for FindCXX11Compiler.cmake and I have there
> > >
> > > set(LYX_USE_CXX11 1)
> > > s
Am Dienstag, 8. Dezember 2015 um 02:09:55, schrieb Uwe Stöhr
> Am 08.12.2015 um 02:07 schrieb Uwe Stöhr:
>
> > I applied Kornel's patch for FindCXX11Compiler.cmake and I have there
> >
> > set(LYX_USE_CXX11 1)
> > set(CXX11_FLAG "")
>
> Of course I uncommented the IF for MSVC 2010 since I use MS
Am 08.12.2015 um 02:07 schrieb Uwe Stöhr:
I applied Kornel's patch for FindCXX11Compiler.cmake and I have there
set(LYX_USE_CXX11 1)
set(CXX11_FLAG "")
Of course I uncommented the IF for MSVC 2010 since I use MSVC 2013. So
set(LYX_USE_CXX11 1)
should always be executed but apparently it is no
Am 07.12.2015 um 21:03 schrieb Georg Baum:
Yes, that is correct. Unfortunately I am now out of ideas.
I found now the problem:
LYX_USE_CXX11
is never set.
I can test this by uncommenting this in line 15 of regex.h then the
comilation works.
I applied Kornel's patch for FindCXX11Compiler.
Uwe Stöhr wrote:
> Now i erased everything again, applied your patches and get e.g. for
> support.lib:
>
> support.lib(_allinone_const.obj) : error LNK2019: unresolved external
> symbol "private: class boost::basic_regex boost::regex_traits > > &
> __thiscall boost::basic_regex boost::w32_regex_t
Am 06.12.2015 um 21:08 schrieb Georg Baum:
But I started yesterday from scratch because I updated to MSVC 2013 and
Qt 5.5.1. so everything is 100% new.
And you did not run cmake and/or MSVC without the patches first?
I started at first with your patches. Since I got compilation errors i
Uwe Stöhr wrote:
> Am 06.12.2015 um 15:27 schrieb Georg Baum:
>
>> I still believe that you have left overs from previous compilations.
>> Please start again from an empty build directory and tell us the result.
>
> But I started yesterday from scratch because I updated to MSVC 2013 and
> Qt 5.5
Am 06.12.2015 um 15:27 schrieb Georg Baum:
I still believe that you have left overs from previous compilations. Please
start again from an empty build directory and tell us the result.
But I started yesterday from scratch because I updated to MSVC 2013 and
Qt 5.5.1. so everything is 100% new.
Uwe Stöhr wrote:
> Am 04.12.2015 um 20:53 schrieb Georg Baum:
>
>> This is mot likely caused by an incomplete rebuild. Does it work if you
>> rebuild the projects that appear in the error messages (the first one I
>> could see was insets.lib)?
>
> No this doesn't work. The first library with an
Am 05.12.2015 um 20:39 schrieb Uwe Stöhr:
No this doesn't work. The first library with an error is biblio. Forcing
its creation leads to the same errors as before:...
I am now able to compile with Qt 5.5.1 and MSVC 2013. As soon as I use
std_regex 1 in CMake (your and Kornel's patches applied
Am 04.12.2015 um 20:53 schrieb Georg Baum:
This is mot likely caused by an incomplete rebuild. Does it work if you
rebuild the projects that appear in the error messages (the first one I
could see was insets.lib)?
No this doesn't work. The first library with an error is biblio. Forcing
its cr
Uwe Stöhr wrote:
> with your patches I get now only 48 instead of 135 errors. So it was a
> step in the right direction. the errors I get now are in this form
> (seems that there are traces of boost):
>
> --
>insets.lib(ExternalTransforms.obj) : error LNK2001: Nicht aufge
Am 01.12.2015 um 22:56 schrieb Kornel Benko:
There is missing the patch for searching c++11 flags. They are not needed,
but ATM this info is ignored by our script.
Additional to your patch we need probably also the attached:
many thanks Georg and Kornel,
with your patches I get now only 48 i
Kornel Benko wrote:
> Am Dienstag, 1. Dezember 2015 um 22:06:40, schrieb Georg Baum
>
>
> There is missing the patch for searching c++11 flags. They are not needed,
> but ATM this info is ignored by our script.
>
> Additional to your patch we need probably also the attached:
Yes, setting CXX11
Am Dienstag, 1. Dezember 2015 um 22:06:40, schrieb Georg Baum
> Uwe Stöhr wrote:
>
> > Am 29.11.2015 um 22:30 schrieb Kornel Benko:
> >
> >> The problem may also be usage (respective non-usage) of --std=c++11.
> >> I already asked, what to do to allow MSVC to use this flag, but got no
> >> answer
Uwe Stöhr wrote:
> Am 29.11.2015 um 22:30 schrieb Kornel Benko:
>
>> The problem may also be usage (respective non-usage) of --std=c++11.
>> I already asked, what to do to allow MSVC to use this flag, but got no
>> answer. ATM the windows compilation is probably without, setting the
>> 'LYX_USE_C
Am Sonntag, 29. November 2015 um 23:44:54, schrieb Uwe Stöhr
> Am 29.11.2015 um 22:30 schrieb Kornel Benko:
>
> > The problem may also be usage (respective non-usage) of --std=c++11.
> > I already asked, what to do to allow MSVC to use this flag, but got no
> > answer.
> > ATM the windows compil
Am 29.11.2015 um 22:30 schrieb Kornel Benko:
The problem may also be usage (respective non-usage) of --std=c++11.
I already asked, what to do to allow MSVC to use this flag, but got no answer.
ATM the windows compilation is probably without, setting the 'LYX_USE_CXX11' to 0
The changes could be
Am Sonntag, 29. November 2015 um 21:50:24, schrieb Uwe Stöhr
> As suggested in
> http://www.lyx.org/trac/ticket/9373
> I tried to compile LyX on Windows with std_regex. When doing this, i get
> these error messages (and many more):
>
The problem may also be usage (respective non-usage) of --std
As suggested in
http://www.lyx.org/trac/ticket/9373
I tried to compile LyX on Windows with std_regex. When doing this, i get
these error messages (and many more):
---
"D:\LyXGit\Master\compile-result\src\tex2lyx\tex2lyx.vcxproj"
(Standardziel) (23) ->
supp
Am Donnerstag, 1. Oktober 2015 um 22:22:18, schrieb Guillaume Munch
> Le 30/09/2015 17:18, Jean-Marc Lasgouttes a écrit :
> > Le 30/09/2015 18:08, Guillaume Munch a écrit :
> >> Surely more difficult than my patch. Also it's pointless spending too
> >> much effort since support/shared_ptr.h will
Le 30/09/2015 17:18, Jean-Marc Lasgouttes a écrit :
Le 30/09/2015 18:08, Guillaume Munch a écrit :
Surely more difficult than my patch. Also it's pointless spending too
much effort since support/shared_ptr.h will disappear in 2.3.
Yes, but I dislike solutions that require to check compiler ver
Le 30/09/2015 18:08, Guillaume Munch a écrit :
Surely more difficult than my patch. Also it's pointless spending too
much effort since support/shared_ptr.h will disappear in 2.3.
Yes, but I dislike solutions that require to check compiler version
number in code. I think we have the same proble
Le 30/09/2015 15:53, Jean-Marc Lasgouttes a écrit :
Le 28/09/2015 19:11, Guillaume Munch a écrit :
What about using explicitely lyx::make_shared in the TocBackend
code? Doesn't it solve the ambiguity?
Yes, I can accept this solution given that we won't have to
support c++98 for very long. The
Le 28/09/2015 19:11, Guillaume Munch a écrit :
What about using explicitely lyx::make_shared in the TocBackend code?
Doesn't it solve the ambiguity?
Yes, I can accept this solution given that we won't have to support
c++98 for very long. The drawback is that the issue might pop-up again
in the
Le 28/09/2015 16:32, Jean-Marc Lasgouttes a écrit :
Le 21/09/2015 00:40, Guillaume Munch a écrit :
Can you please test the attached patch and report if it fixes the
compilation in c++98 mode? (with up-to-date master)
What about using explicitely lyx::make_shared in the TocBackend code?
Doesn't
Le 21/09/2015 00:40, Guillaume Munch a écrit :
Can you please test the attached patch and report if it fixes the
compilation in c++98 mode? (with up-to-date master)
What about using explicitely lyx::make_shared in the TocBackend code?
Doesn't it solve the ambiguity?
JMarc
Le 20/09/2015 23:40, Guillaume Munch a écrit :
Le 20/09/2015 17:05, Uwe Stöhr a écrit :
I get 2 compilation errors with current master:
..\..\src\TocBackend.cpp(191): error C2668: 'boost::make_shared':
ambiguous call of an overloaded function
[D:\LyXGit\Master\compile-result\src\L
Le 20/09/2015 17:05, Uwe Stöhr a écrit :
I get 2 compilation errors with current master:
..\..\src\TocBackend.cpp(191): error C2668: 'boost::make_shared':
ambiguous call of an overloaded function
[D:\LyXGit\Master\compile-result\src\LyX.vcxproj]
..\..\src\TocBackend.cpp(191): e
Am Sonntag, 20. September 2015 um 17:51:34, schrieb Guillaume Munch
> Le 20/09/2015 17:05, Uwe Stöhr a écrit :
> > I get 2 compilation errors with current master:
> >
> >..\..\src\TocBackend.cpp(191): error C2668: 'boost::make_shared':
> > ambiguous
Le 20/09/2015 17:05, Uwe Stöhr a écrit :
I get 2 compilation errors with current master:
..\..\src\TocBackend.cpp(191): error C2668: 'boost::make_shared':
ambiguous call of an overloaded function
[D:\LyXGit\Master\compile-result\src\LyX.vcxproj]
..\..\src\TocBackend.cpp(191): e
I get 2 compilation errors with current master:
..\..\src\TocBackend.cpp(191): error C2668: 'boost::make_shared':
ambiguous call of an overloaded function
[D:\LyXGit\Master\compile-result\src\LyX.vcxproj]
..\..\src\TocBackend.cpp(191): error C2228: left of ".first&qu
Am 17.02.2012 15:16, schrieb Vincent van Ravesteijn:
This is something we discussed also previously.
Yes.
Why don't you create two MSVC projects. One for trunk and one for branch ?
I already have them. I don't understand your concerns. We discussed the topic already and as result
peter cr
Op 17-2-2012 1:04, Uwe Stöhr schreef:
Am 16.02.2012 20:53, schrieb André Pönitz:
Maybe you can save some time by using different checkouts
for trunk and branch
I always use different checkouts.
regards Uwe
This is something we discussed also previously.
Why don't you create two MSVC proje
Am 16.02.2012 20:53, schrieb André Pönitz:
Maybe you can save some time by using different checkouts
for trunk and branch
I always use different checkouts.
regards Uwe
On Thu, Feb 16, 2012 at 12:13:18AM +0100, Uwe Stöhr wrote:
> Am 15.02.2012 12:02, schrieb Vincent van Ravesteijn:
>
> >I still don't understand why you insist on using the build scripts. Why not
> >just using an IDE ?
>
> Because I have to compile both, branch and trunk quite frequently.
> Using
Le 16/02/2012 00:13, Uwe Stöhr a écrit :
Besides, the warning is quite clear what the problem is.
"does not define any previously undefined public symbol"
is not clear to me. A white car is also not a previously non-white
truck. (The logic in the warning sentence is illogical.)
It measn that
Am 15.02.2012 12:02, schrieb Vincent van Ravesteijn:
I still don't understand why you insist on using the build scripts. Why not
just using an IDE ?
Because I have to compile both, branch and trunk quite frequently. Using the IDE took ages and one
had to reset everything when switching from
Op 14-2-2012 0:35, Uwe Stöhr schreef:
Am 14.02.2012 00:16, schrieb Uwe Stöhr:
Peter could help me.
I still don't understand why you insist on using the build scripts. Why
not just using an IDE ?
Except of this warning that still appears in any case:
"D:\LyXSVN\lyx-devel\compile-result\b
Am 14.02.2012 00:16, schrieb Uwe Stöhr:
Peter could help me.
Except of this warning that still appears in any case:
"D:\LyXSVN\lyx-devel\compile-result\boost\libs\regex\boost_regex.vcxproj" (default
target) (7) ->
(Lib target) ->
static_mutex.obj : warning LNK4221: This object file does no
Am 12.02.2012 23:03, schrieb Uwe Stöhr:
When I compile trunk in install mode I get these compiler errors:
Peter could help me. The reason was that our standard compilation batch script creates a merged
build. This requires to remerge from time to time but this is not done by default.
So perha
When I compile trunk in install mode I get these compiler errors:
1.
mathed.lib(_allinone_const.obj) : error LNK2019: unresolved external symbol "pu
blic: __thiscall lyx::InsetMathCancelto::InsetMathCancelto(class lyx::Buffer *)
" (??0InsetMathCancelto@lyx@@QAE@PAVBuffer@1@@Z) referenced in funct
Hi Peter,
> I assume it links against the wrong libiconv. I tried to fix this it
> yesterday when I had the same error.
> Building with internal libintl it should work with /usr/lib/libiconv.dylib,
> you could set the library
> with -DICONV_LIBRARY=/usr/lib/libiconv.dylib. If it doesn't work wit
On 14.05.2011 01:01, Rob Oakes wrote:
Thanks Peter,
It's fixed. It's possible to build with external and internal libintl now.
Thanks for taking a look at it. For some reason, I still kept having problems
(even after deleting my build directory and CMakeLists.txt.user). It still kept
trying
On 14.05.2011 01:12, Rob Oakes wrote:
It's fixed. It's possible to build with external and internal libintl now.
Thanks for taking a look at it. For some reason, I still kept having problems
(even after deleting my build directory and CMakeLists.txt.user). It still kept
trying to use the exte
>> It's fixed. It's possible to build with external and internal libintl now.
>
> Thanks for taking a look at it. For some reason, I still kept having problems
> (even after deleting my build directory and CMakeLists.txt.user). It still
> kept trying to use the external libintl.
>
> So ... I we
Thanks Peter,
> It's fixed. It's possible to build with external and internal libintl now.
Thanks for taking a look at it. For some reason, I still kept having problems
(even after deleting my build directory and CMakeLists.txt.user). It still kept
trying to use the external libintl.
So ... I
Any thoughts as to what I might be doing wrong? Do I need to change the
compilation flags? A quick Google search shows that Mac doesn't seem to
ship with libintl. Might the configuration on Mac OS X be reverting to
the generic Linux? (Sorry, cmake is mostly black magic to me.)
Cheers,
Rob
Do
On 12.05.2011 19:16, Kornel wrote:
Am Donnerstag, 12. Mai 2011 schrieb Peter Kümmel:
On 12.05.2011 18:04, Rob Oakes wrote:
Dear LyX Developers,
Is anyone else getting compilation errors on Mac OS X after the cmake
directory cleanup? I just merged with the most recent SVN, and this is
what
Am Donnerstag, 12. Mai 2011 schrieb Peter Kümmel:
> On 12.05.2011 18:04, Rob Oakes wrote:
> > Dear LyX Developers,
> >
> > Is anyone else getting compilation errors on Mac OS X after the cmake
> > directory cleanup? I just merged with the most recent SVN, and this is
On 12.05.2011 18:04, Rob Oakes wrote:
Dear LyX Developers,
Is anyone else getting compilation errors on Mac OS X after the cmake directory
cleanup? I just merged with the most recent SVN, and this is what I'm getting
(after reconfiguring with cmake):
/Users/RobOakes/Developer/LyX-Ou
Dear LyX Developers,
Is anyone else getting compilation errors on Mac OS X after the cmake directory
cleanup? I just merged with the most recent SVN, and this is what I'm getting
(after reconfiguring with cmake):
/Users/RobOakes/Developer/LyX-Outline/LyX-Outline-Devel/src/su
On 02.09.2010 09:29, Stephan Witt wrote:
> Am 02.09.2010 um 09:03 schrieb Peter Kümmel:
>
>> On 02.09.2010 07:54, Stephan Witt wrote:
>>> Am 01.09.2010 um 08:01 schrieb Abdelrazak Younes:
>>>
On 09/01/2010 01:38 AM, Uwe Stöhr wrote:
>
> However, this compilation error remains:
>
>
On 02.09.2010 07:54, Stephan Witt wrote:
> Am 01.09.2010 um 08:01 schrieb Abdelrazak Younes:
>
>> On 09/01/2010 01:38 AM, Uwe Stöhr wrote:
>>>
>>> However, this compilation error remains:
>>>
>>> 10>..\..\src\LyX.cpp(288) : error C4101: 'message' : unreferenced local
>>> variable
>>>
>>> The atta
Am 01.09.2010 um 08:01 schrieb Abdelrazak Younes:
> On 09/01/2010 01:38 AM, Uwe Stöhr wrote:
>>
>> However, this compilation error remains:
>>
>> 10>..\..\src\LyX.cpp(288) : error C4101: 'message' : unreferenced local
>> variable
>>
>> The attached patch fixes also this error for me (debug and
> using msvc this warning as handled as error.
> but it's fixed now.
Many thanks!
regards Uwe
> First -Dmerge=0 and then -Dmerge_rebuild=1? This seems fishy...
>
> In general when you are developping for debug, disable merge build. For
> release mode I agree that this is faster.
>
> Abdel.
>
these options are obsolete now. all options now start with LYX_ see cmake output
or cmake-gui.
On 01.09.2010 01:38, Uwe Stöhr wrote:
> Am 31.08.2010 08:02, schrieb Stephan Witt:
>
>> I guess it's my change r35193.
>>
>> Please try attached patch.
>
> This fixes the setenv compilation errors -> I committed it.
>
> However, this compilation
On 08/31/2010 03:15 AM, Uwe Stöhr wrote:
Am 31.08.2010 03:04, schrieb Uwe Stöhr:
I am not able to compile LyX 2.0 using CMAKE. I get these errors:
I forgot to say that I'm using
- Microsoft Visual C++ 2008 Express Edition with SP1
- Qt 4.6.3
- Windows XP 64bit (a.k.a. Windows 2003 Server)
- CM
On 09/01/2010 01:38 AM, Uwe Stöhr wrote:
Am 31.08.2010 08:02, schrieb Stephan Witt:
I guess it's my change r35193.
Please try attached patch.
This fixes the setenv compilation errors -> I committed it.
However, this compilation error remains:
10>..\..\src\LyX.cpp(288) :
Am 01.09.2010 um 01:38 schrieb Uwe Stöhr:
> Am 31.08.2010 08:02, schrieb Stephan Witt:
>
> However, this compilation error remains:
>
> 10>..\..\src\LyX.cpp(288) : error C4101: 'message' : unreferenced local
> variable
>
> The attached patch fixes also this error for me (debug and release mode
Am 31.08.2010 08:02, schrieb Stephan Witt:
I guess it's my change r35193.
Please try attached patch.
This fixes the setenv compilation errors -> I committed it.
However, this compilation error remains:
10>..\..\src\LyX.cpp(288) : error C4101: 'message' : unreference
Am 31.08.2010 um 03:15 schrieb Uwe Stöhr:
> Am 31.08.2010 03:04, schrieb Uwe Stöhr:
>> I am not able to compile LyX 2.0 using CMAKE. I get these errors:
>
> I forgot to say that I'm using
> - Microsoft Visual C++ 2008 Express Edition with SP1
> - Qt 4.6.3
> - Windows XP 64bit (a.k.a. Windows 2003
Am 31.08.2010 03:04, schrieb Uwe Stöhr:
I am not able to compile LyX 2.0 using CMAKE. I get these errors:
I forgot to say that I'm using
- Microsoft Visual C++ 2008 Express Edition with SP1
- Qt 4.6.3
- Windows XP 64bit (a.k.a. Windows 2003 Server)
- CMake 2.8.2
and build with this batch file:
I am not able to compile LyX 2.0 using CMAKE. I get these errors:
2>..\..\..\src\support\environment.cpp(65) : error C2039: 'setenv' : is not a member of '`global
namespace''
2>..\..\..\src\support\environment.cpp(65) : error C3861: 'setenv': identifier
not found
10>..\..\src\LyX.cpp(288) : e
> identifier
> 9>..\..\intl\loadmsgcat.c(861) : error C2065: 'data' : undeclared
> identifier
> 9>..\..\intl\loadmsgcat.c(861) : warning C4047: '==' : 'int' differs in
> levels of indirection from
> 'mo_file_header *'
>
> This is an excerpt of 74 errors I get.
>
> Is this my mistake or not? If
When compiling todays' trunk using CMake I get a whole bunch of errors:
9>d:\lyxsvn\lyx-devel\intl\gettextP.h(109) : error C2054: expected '(' to
follow 'inline'
9>d:\lyxsvn\lyx-devel\intl\gettextP.h(110) : error C2085: 'SWAP' : not in
formal parameter list
9>d:\lyxsvn\lyx-devel\intl\gettextP.h
> > > In the line above I replaced g++ by g++ -E and I have removed what comes
> > > after the -c (of course).
> > >
> > > I send you the result attached. It seems that the compiler is right
> > > bad_cast is nowhere to be found...
> >
> > bad_cast come from
> > /usr/lib/gcc/i686-pc-linux-gnu/4.1.2
On Friday 21 March 2008 01:40:55 Pavel Sanda wrote:
> José Matos wrote:
> > In the line above I replaced g++ by g++ -E and I have removed what comes
> > after the -c (of course).
> >
> > I send you the result attached. It seems that the compiler is right
> > bad_cast is nowhere to be found...
>
> b
On Friday 21 March 2008 01:07:39 Pavel Sanda wrote:
> > > g++ -DHAVE_CONFIG_H -I. -I../../../../lyx/lyx-devel/src/support
> > > -I../../src -I../../../../lyx/lyx-devel/src/support/..
> > > -I../../../../lyx/lyx-devel/boost -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR
> > > -DQT_NO_STL -DQT_NO_KEYWORDS -D
José Matos wrote:
> In the line above I replaced g++ by g++ -E and I have removed what comes
> after
> the -c (of course).
>
> I send you the result attached. It seems that the compiler is right bad_cast
> is nowhere to be found...
bad_cast come from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/includ
> > I have been trying to compile the first alpha release, for that I have
> > changed
> > configure.ac changing the release from 1.6.0svn to 1.6.0alpha1, this
> > changes
> > automatically the configure flags to be in the pre-release mode.
>
> fyi i have just succesfully compiled alpha1.
> i
> On Thursday 20 March 2008 15:30:49 José Matos wrote:
> > I have been trying to compile the first alpha release, for that I have
> > changed configure.ac changing the release from 1.6.0svn to 1.6.0alpha1,
> > this changes automatically the configure flags to be in the pre-release
> > mode.
>
> I
> I have been trying to compile the first alpha release, for that I have
> changed
> configure.ac changing the release from 1.6.0svn to 1.6.0alpha1, this changes
> automatically the configure flags to be in the pre-release mode.
fyi i have just succesfully compiled alpha1.
i just changed 1.6.0a
On Thursday 20 March 2008 15:30:49 José Matos wrote:
> I have been trying to compile the first alpha release, for that I have
> changed configure.ac changing the release from 1.6.0svn to 1.6.0alpha1,
> this changes automatically the configure flags to be in the pre-release
> mode.
I have another t
I have been trying to compile the first alpha release, for that I have changed
configure.ac changing the release from 1.6.0svn to 1.6.0alpha1, this changes
automatically the configure flags to be in the pre-release mode.
Compiling the tree fails with the attached errors.
This is strange because
1 - 100 of 109 matches
Mail list logo
