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
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 I'm
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 I'm getting (after r
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-Outline/LyX
> > > 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
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> but of course... I never relate to 1.2.x only to CVS.
FWIW, the dist was missing in cvs too.
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Sure?
>
| I am sure that xforms.m4 is missing from EXTRA_DIST and that Claus did
| run autogen. So it really could not work...
>
| Lars> I have seen more or less the exact s
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Sure?
I am sure that xforms.m4 is missing from EXTRA_DIST and that Claus did
run autogen. So it really could not work...
Lars> I have seen more or less the exact same because of wrong usage
Lars> of AM_CONDITIONAL
What I am
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> I find the AM_CONDITIONAL pretty nice, nicer than puting #ifdef
| Lars> compile_with_xpm_support in source files... also nicer than
| Lars> putting the files in configure
>
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I find the AM_CONDITIONAL pretty nice, nicer than puting #ifdef
Lars> compile_with_xpm_support in source files... also nicer than
Lars> putting the files in configure
In this particular case, it seems that the problem was that
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> I think I know what this problem is.
|
| Lars> It is undefined behaviour with how some AM_CONDITIONAL is used
| Lars> now.
|
| Lars> The result is that the XPM loaders i
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I think I know what this problem is.
Lars> It is undefined behaviour with how some AM_CONDITIONAL is used
Lars> now.
Lars> The result is that the XPM loaders is alwas turned on...
I'd be interested to see a fix for that. Not
"Claus Hentschel" <[EMAIL PROTECTED]> writes:
| Trying to compile release 1.2.1 on both Win32/Cygwin and SuSE 8.0 I do get
| errors, because
| #include FORMS_H_LOCATION
| can't be resolved by the C-preprocessor. A diff with 1.2.0 shows that
| src/config.h does not include any xforms stuff in
27 matches
Mail list logo
