Am Thu, 20 Jan 2022 18:47:43 +0100
schrieb Jean-Marc Lasgouttes :
> Le 20/01/2022 à 18:16, Scott Kostyshak a écrit :
> >> JMarc any objection to Kornel's patch?
> >
> > Ping to JMarc.
>
> Go ahead.
>
> JMarc
Committed at 2764ed20.
Kornel
pgpFnFZWOW5Jy.pgp
Description: Digitale S
Le 20/01/2022 à 18:16, Scott Kostyshak a écrit :
JMarc any objection to Kornel's patch?
Ping to JMarc.
Go ahead.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Fri, Nov 05, 2021 at 09:18:05PM -0400, Scott Kostyshak wrote:
> On Wed, Sep 22, 2021 at 07:08:48PM +0200, Kornel Benko wrote:
> > Am Wed, 22 Sep 2021 10:28:44 +0200
> > schrieb Jean-Marc Lasgouttes :
> >
> > > Le 21/09/2021 à 16:52, Scott Kostyshak a écrit :
> > > >> Some debugging lead to foll
On Wed, Sep 22, 2021 at 07:08:48PM +0200, Kornel Benko wrote:
> Am Wed, 22 Sep 2021 10:28:44 +0200
> schrieb Jean-Marc Lasgouttes :
>
> > Le 21/09/2021 à 16:52, Scott Kostyshak a écrit :
> > >> Some debugging lead to following observation:
> > >> Each inserted branch add a color to the list. The o
Am Wed, 22 Sep 2021 10:28:44 +0200
schrieb Jean-Marc Lasgouttes :
> Le 21/09/2021 à 16:52, Scott Kostyshak a écrit :
> >> Some debugging lead to following observation:
> >> Each inserted branch add a color to the list. The original enum defined
> >> colors (about
> >> 102), last Color_ignore.
> >
Le 22/09/2021 à 16:04, Scott Kostyshak a écrit :
I do have 25+ branches.
OK, forget what I wrote ;)
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Wed, Sep 22, 2021 at 10:28:44AM +0200, Jean-Marc Lasgouttes wrote:
> Le 21/09/2021 à 16:52, Scott Kostyshak a écrit :
> > > Some debugging lead to following observation:
> > > Each inserted branch add a color to the list. The original enum defined
> > > colors (about
> > > 102), last Color_igno
Le 21/09/2021 à 16:52, Scott Kostyshak a écrit :
Some debugging lead to following observation:
Each inserted branch add a color to the list. The original enum defined colors
(about
102), last Color_ignore.
So each branch will now get colors 103, 104, ..., and so on, so that the
original enum
(p
On Tue, Sep 21, 2021 at 10:52:34AM -0400, Scott Kostyshak wrote:
> I didn't understand how JMarc's suggestion to change the type to int would
> solve the (non) issue.
I think I understand now: the code just needs to assign some value, it doesn't
actually have to correspond to a correct color?
On Mon, Sep 20, 2021 at 06:30:14PM +0200, Kornel Benko wrote:
> Am Mon, 20 Sep 2021 11:48:37 +0200
> schrieb Kornel Benko :
>
> > Am Sun, 19 Sep 2021 20:19:15 -0400
> > schrieb Scott Kostyshak :
> >
> > > On Sun, Sep 19, 2021 at 08:37:16PM +0200, Kornel Benko wrote:
> > > > Am Sun, 19 Sep 2021
Am Mon, 20 Sep 2021 11:48:37 +0200
schrieb Kornel Benko :
> Am Sun, 19 Sep 2021 20:19:15 -0400
> schrieb Scott Kostyshak :
>
> > On Sun, Sep 19, 2021 at 08:37:16PM +0200, Kornel Benko wrote:
> > > Am Sun, 19 Sep 2021 14:15:21 -0400
> > > schrieb Scott Kostyshak :
> > >
> > > > On Sun, Sep
Am Sun, 19 Sep 2021 20:19:15 -0400
schrieb Scott Kostyshak :
> On Sun, Sep 19, 2021 at 08:37:16PM +0200, Kornel Benko wrote:
> > Am Sun, 19 Sep 2021 14:15:21 -0400
> > schrieb Scott Kostyshak :
> >
> > > On Sun, Sep 19, 2021 at 02:00:33PM +0200, Kornel Benko wrote:
> > > > Am Sun, 19 Sep 2021
Le 19/09/2021 à 20:15, Scott Kostyshak a écrit :
It seems that it is triggered with a lot of branches (or perhaps more generally
any different kind of insets?). Attached is an LFUN sequence that reproduces
it. Does it trigger the error for you?
Look at ColorSet::setColor in Color.cpp. Branche
Le 18/09/2021 à 18:46, Kornel Benko a écrit :
Am Sat, 18 Sep 2021 10:34:49 -0400
schrieb Scott Kostyshak :
I tried but failed. The problem is that tex2lyx uses
libzlibstatic.a, ../../lib/libsupport.a to link with, but these are compiled
with
-fsanitize. So the only way is to define dummy versi
On Sun, Sep 19, 2021 at 08:37:16PM +0200, Kornel Benko wrote:
> Am Sun, 19 Sep 2021 14:15:21 -0400
> schrieb Scott Kostyshak :
>
> > On Sun, Sep 19, 2021 at 02:00:33PM +0200, Kornel Benko wrote:
> > > Am Sun, 19 Sep 2021 07:45:19 -0400
> > > schrieb Scott Kostyshak :
> > >
> > > > > > > So inse
Am Sun, 19 Sep 2021 14:15:21 -0400
schrieb Scott Kostyshak :
> On Sun, Sep 19, 2021 at 02:00:33PM +0200, Kornel Benko wrote:
> > Am Sun, 19 Sep 2021 07:45:19 -0400
> > schrieb Scott Kostyshak :
> >
> > > > > > So inserting this include cured the compilation for me.
> > > > >
> > > > > Th
On Sun, Sep 19, 2021 at 02:00:33PM +0200, Kornel Benko wrote:
> Am Sun, 19 Sep 2021 07:45:19 -0400
> schrieb Scott Kostyshak :
>
> > > > > So inserting this include cured the compilation for me.
> > > >
> > > > That's great you figured it out and it doesn't add too much complexity
> > > > to
Am Sun, 19 Sep 2021 07:45:19 -0400
schrieb Scott Kostyshak :
> > > > So inserting this include cured the compilation for me.
> > >
> > > That's great you figured it out and it doesn't add too much complexity to
> > > the code.
> > > Are you sure it ended up using the -fsanitize=undefined fla
On Sun, Sep 19, 2021 at 10:35:44AM +0200, Kornel Benko wrote:
> Am Sat, 18 Sep 2021 20:52:43 -0400
> schrieb Scott Kostyshak :
>
> > On Sat, Sep 18, 2021 at 06:46:47PM +0200, Kornel Benko wrote:
> > > Am Sat, 18 Sep 2021 10:34:49 -0400
> > > schrieb Scott Kostyshak :
> > >
> > > > > I tried but
Am Sat, 18 Sep 2021 20:52:43 -0400
schrieb Scott Kostyshak :
> On Sat, Sep 18, 2021 at 06:46:47PM +0200, Kornel Benko wrote:
> > Am Sat, 18 Sep 2021 10:34:49 -0400
> > schrieb Scott Kostyshak :
> >
> > > > I tried but failed. The problem is that tex2lyx uses
> > > > libzlibstatic.a, ../../lib/l
On Sat, Sep 18, 2021 at 06:46:47PM +0200, Kornel Benko wrote:
> Am Sat, 18 Sep 2021 10:34:49 -0400
> schrieb Scott Kostyshak :
>
> > > I tried but failed. The problem is that tex2lyx uses
> > > libzlibstatic.a, ../../lib/libsupport.a to link with, but these are
> > > compiled with
> > > -fsanitiz
Am Sat, 18 Sep 2021 10:34:49 -0400
schrieb Scott Kostyshak :
> > I tried but failed. The problem is that tex2lyx uses
> > libzlibstatic.a, ../../lib/libsupport.a to link with, but these are
> > compiled with
> > -fsanitize. So the only way is to define dummy versions as Jean-Marc
> > pointed out
On Sat, Sep 18, 2021 at 04:29:40PM +0200, Kornel Benko wrote:
> Am Fri, 17 Sep 2021 16:41:09 -0400
> schrieb Scott Kostyshak :
>
> > On Fri, Sep 17, 2021 at 10:22:28PM +0200, Kornel Benko wrote:
> > > Am Fri, 17 Sep 2021 20:24:17 +0200
> > > schrieb Jean-Marc Lasgouttes :
> > >
> > > > Le 17/09
Am Fri, 17 Sep 2021 16:41:09 -0400
schrieb Scott Kostyshak :
> On Fri, Sep 17, 2021 at 10:22:28PM +0200, Kornel Benko wrote:
> > Am Fri, 17 Sep 2021 20:24:17 +0200
> > schrieb Jean-Marc Lasgouttes :
> >
> > > Le 17/09/2021 à 20:21, Scott Kostyshak a écrit :
> > > > /usr/include/c++/10/bits/st
On Fri, Sep 17, 2021 at 10:22:28PM +0200, Kornel Benko wrote:
> Am Fri, 17 Sep 2021 20:24:17 +0200
> schrieb Jean-Marc Lasgouttes :
>
> > Le 17/09/2021 à 20:21, Scott Kostyshak a écrit :
> > > /usr/include/c++/10/bits/stl_function.h:386:20: runtime error: load of
> > > value 128,
> > > which is n
Am Fri, 17 Sep 2021 20:24:17 +0200
schrieb Jean-Marc Lasgouttes :
> Le 17/09/2021 à 20:21, Scott Kostyshak a écrit :
> > /usr/include/c++/10/bits/stl_function.h:386:20: runtime error: load of
> > value 128,
> > which is not a valid value for type 'ColorCode'
> > /usr/include/c++/10/tuple:1693:70
Le 17/09/2021 à 20:21, Scott Kostyshak a écrit :
/usr/include/c++/10/bits/stl_function.h:386:20: runtime error: load of value
128, which is not a valid value for type 'ColorCode'
/usr/include/c++/10/tuple:1693:70: runtime error: load of value 128, which is
not a valid value for type 'ColorCode'
On Fri, Sep 17, 2021 at 12:11:46PM +0200, Jean-Marc Lasgouttes wrote:
> Le 16/09/2021 à 22:13, Kornel Benko a écrit :
> > Am Thu, 16 Sep 2021 15:12:34 -0400
> > schrieb Scott Kostyshak :
> >
> > > I was curious about compiling with -fsanitize=undefined.
> > >
> > > When building (with CMake), I g
Le 16/09/2021 à 22:13, Kornel Benko a écrit :
Am Thu, 16 Sep 2021 15:12:34 -0400
schrieb Scott Kostyshak :
I was curious about compiling with -fsanitize=undefined.
When building (with CMake), I get the following:
-lz /usr/bin/ld: CMakeFiles/tex2lyx.dir/dummy_impl.cpp.o:(.data.rel+0x118):
u
Am Thu, 16 Sep 2021 21:12:38 -0400
schrieb Scott Kostyshak :
> On Thu, Sep 16, 2021 at 10:13:15PM +0200, Kornel Benko wrote:
> > Am Thu, 16 Sep 2021 15:12:34 -0400
> > schrieb Scott Kostyshak :
> >
> > > I was curious about compiling with -fsanitize=undefined.
> > >
> > > When building (with C
On Thu, Sep 16, 2021 at 10:13:15PM +0200, Kornel Benko wrote:
> Am Thu, 16 Sep 2021 15:12:34 -0400
> schrieb Scott Kostyshak :
>
> > I was curious about compiling with -fsanitize=undefined.
> >
> > When building (with CMake), I get the following:
> >
> > [ 93%] Linking CXX executable ../../bin/t
Am Thu, 16 Sep 2021 15:12:34 -0400
schrieb Scott Kostyshak :
> I was curious about compiling with -fsanitize=undefined.
>
> When building (with CMake), I get the following:
>
> [ 93%] Linking CXX executable ../../bin/tex2lyx
> cd /home/scott/lyxbuilds/master/CMakeBuild/src/tex2lyx && /usr/bin/cm
I was curious about compiling with -fsanitize=undefined.
When building (with CMake), I get the following:
[ 93%] Linking CXX executable ../../bin/tex2lyx
cd /home/scott/lyxbuilds/master/CMakeBuild/src/tex2lyx && /usr/bin/cmake -E
cmake_link_script CMakeFiles/tex2lyx.dir/link.txt --verbose=1
/usr
Le 06/06/2011 17:56, Uwe Stöhr a écrit :
Am 06.06.2011 17:53, schrieb Jean-Marc Lasgouttes:
However, I'm using Qt 4.7.3.
Better now?
Sure. But reverting the change in the .h file would have been enough.
It would not link for me anyway...
JMarc
Am 06.06.2011 17:53, schrieb Jean-Marc Lasgouttes:
However, I'm using Qt 4.7.3.
Better now?
Sure. But reverting the change in the .h file would have been enough.
regards Uwe
Le 06/06/2011 17:39, Uwe Stöhr a écrit :
Am 06.06.2011 16:28, schrieb Jean-Marc Lasgouttes:
What Qt version? Could the problem be r38963? I could not compile with
4.5.
Sorry, read it too late.
However, I'm using Qt 4.7.3.
Better now?
JMarc
Am 06.06.2011 16:28, schrieb Jean-Marc Lasgouttes:
What Qt version? Could the problem be r38963? I could not compile with 4.5.
Sorry, read it too late.
However, I'm using Qt 4.7.3.
regards Uwe
Le 06/06/2011 14:30, Richard Heck a écrit :
CXXLD lyx
frontends/qt4/liblyxqt4.a(FancyLineEdit.o): In function `IconButton':
/cvs/lyx/src/frontends/qt4/FancyLineEdit.cpp:267: undefined reference to
`vtable for lyx::frontend::IconButton'
/cvs/lyx/src/frontends/qt4/FancyLineEdit.cpp:267: undefined
rgheck wrote:
> CXXLD lyx
> frontends/qt4/liblyxqt4.a(GuiView.o): In function
> `lyx::frontend::GuiView::build(std::basic_string std::char_traits, std::allocator > const&)':
> /cvs/lyx-devel/trunk/src/frontends/qt4/GuiView.cpp:3478: undefined
> reference to `lyx::frontend::createGuiProgress(lyx:
CXXLD lyx
frontends/qt4/liblyxqt4.a(GuiView.o): In function
`lyx::frontend::GuiView::build(std::basic_stringstd::char_traits, std::allocator > const&)':
/cvs/lyx-devel/trunk/src/frontends/qt4/GuiView.cpp:3478: undefined
reference to `lyx::frontend::createGuiProgress(lyx::frontend::GuiView&)'
On Fri, Sep 07, 2007 at 06:03:00PM +1000, Darren Freeman wrote:
> On Thu, 2007-09-06 at 20:32 +0200, Andre Poenitz wrote:
> > ccache is dead easy.
> >
> > As root
> >
> > ln -s /usr/local/bin/gcc /usr/bin/ccache
> > ln -s /usr/local/bin/g++ /usr/bin/ccache
>
> Oh god no! You'll (try to) overw
On Fri, 2007-09-07 at 09:25 +0100, José Matos wrote:
> On Friday 07 September 2007 08:25:30 Darren Freeman wrote:
> > Check out gcc's new precompiled header functionality.
> > http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
> >
> > Basically gcc-3.4 and newer allow you to dump the state
On Friday 07 September 2007 08:25:30 Darren Freeman wrote:
> Check out gcc's new precompiled header functionality.
> http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
>
> Basically gcc-3.4 and newer allow you to dump the state of the compiler
> to disc after your headers are compiled, and
On Thu, 2007-09-06 at 20:32 +0200, Andre Poenitz wrote:
> ccache is dead easy.
>
> As root
>
> ln -s /usr/local/bin/gcc /usr/bin/ccache
> ln -s /usr/local/bin/g++ /usr/bin/ccache
Oh god no! You'll (try to) overwrite /usr/bin/ccache!
:)
Have fun,
Darren
PS. I do that too, sometimes :D
On Thu, 2007-09-06 at 18:51 +0100, José Matos wrote:
> I am not reticent. I am still compiling. :-(
>
> That is why I like André's goal to reduce the compile time. Does anyone has
> some simple step by step procedure to make ccache (or any other compiler
> cache) work. It is really frustrati
On Thu, Sep 06, 2007 at 06:51:27PM +0100, José Matos wrote:
> On Thursday 06 September 2007 18:10:57 Enrico Forestieri wrote:
> > So, Jean-Marc, would you like to pursue some other option or may I
> > apply my patch? It works for me, works for Darren, and I am sure that
> > it also works for José,
On Thursday 06 September 2007 15:25:48 Jean-Marc Lasgouttes wrote:
> José Matos <[EMAIL PROTECTED]> writes:
> > Should I test your patch or Jean-Marc's?
> >
> > I am confused now. :-)
>
> Try Enrico's. I suspect that my approach is wrong.
>
> JMarc
OK, it works for me as well. :-)
--
José Abílio
On Thursday 06 September 2007 18:10:57 Enrico Forestieri wrote:
> So, Jean-Marc, would you like to pursue some other option or may I
> apply my patch? It works for me, works for Darren, and I am sure that
> it also works for José, even if he is reticent ;-)
I am not reticent. I am still compilin
On Fri, Sep 07, 2007 at 02:51:33AM +1000, Darren Freeman wrote:
> On Thu, 2007-09-06 at 18:23 +0200, Enrico Forestieri wrote:
> > On Fri, Sep 07, 2007 at 12:28:45AM +1000, Darren Freeman wrote:
> >
> > > I have been getting away with "patch > > filenames manually. However in that one case, it de
On Thu, Sep 06, 2007 at 11:40:08AM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> > As QtGui will be brought by the frontend, it will not hurt at all now.
>
> But does it hurt the non-gui programs in terms of start-up time on
> some platforms?
I don't thin
On Thu, 2007-09-06 at 18:23 +0200, Enrico Forestieri wrote:
> On Fri, Sep 07, 2007 at 12:28:45AM +1000, Darren Freeman wrote:
>
> > I have been getting away with "patch > filenames manually. However in that one case, it decided to use the
> > Makefile.am in a higher directory than the one it shou
On Fri, Sep 07, 2007 at 12:28:45AM +1000, Darren Freeman wrote:
> I have been getting away with "patch filenames manually. However in that one case, it decided to use the
> Makefile.am in a higher directory than the one it should have, hence not
> finding the section to modify.
That's error pron
On Thu, 2007-09-06 at 15:08 +0200, Enrico Forestieri wrote:
> On Thu, Sep 06, 2007 at 09:40:15PM +1000, Darren Freeman wrote:
>
> > On Thu, 2007-09-06 at 04:45 +0200, Enrico Forestieri wrote:
> > > Please, try the attached patch.
> >
> > BTW I am using autoconf-2.60-21 and automake-1.9.6-35.
> >
José Matos <[EMAIL PROTECTED]> writes:
> Should I test your patch or Jean-Marc's?
>
> I am confused now. :-)
Try Enrico's. I suspect that my approach is wrong.
JMarc
On Thursday 06 September 2007 14:55:24 Enrico Forestieri wrote:
> Anyway, does the updated patch work for you?
>
> --
> Enrico
Should I test your patch or Jean-Marc's?
I am confused now. :-)
--
José Abílio
On Thu, Sep 06, 2007 at 02:16:26PM +0100, José Matos wrote:
> On Thursday 06 September 2007 14:06:22 Enrico Forestieri wrote:
> > I only know what you say or what I can experiment, and you didn't
> > say that it wasn't lyxclient that was failing...
>
> The first instance to fail depended on the
On Thursday 06 September 2007 14:06:22 Enrico Forestieri wrote:
> I only know what you say or what I can experiment, and you didn't
> say that it wasn't lyxclient that was failing...
The first instance to fail depended on the use of make -j where is
usually 2 or 3.
Nevertheless it was the s
On Thu, Sep 06, 2007 at 03:08:29PM +0200, Enrico Forestieri wrote:
> On Thu, Sep 06, 2007 at 09:40:15PM +1000, Darren Freeman wrote:
>
> > On Thu, 2007-09-06 at 04:45 +0200, Enrico Forestieri wrote:
> > > Please, try the attached patch.
> >
> > BTW I am using autoconf-2.60-21 and automake-1.9.6-
On Thu, Sep 06, 2007 at 09:40:15PM +1000, Darren Freeman wrote:
> On Thu, 2007-09-06 at 04:45 +0200, Enrico Forestieri wrote:
> > Please, try the attached patch.
>
> BTW I am using autoconf-2.60-21 and automake-1.9.6-35.
>
> The attachment shows the rejected change from your patch, because the
>
On Thu, Sep 06, 2007 at 09:43:21AM +0100, José Matos wrote:
> On Thursday 06 September 2007 03:44:24 Enrico Forestieri wrote:
> > Are you sure that it was not failing later on tex2lyx?
>
> Sure it was. But I guess you knew that. :-)
I only know what you say or what I can experiment, and you di
On Thu, Sep 06, 2007 at 11:21:51AM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> > Jean-Marc Lasgouttes wrote:
> >> Enrico Forestieri <[EMAIL PROTECTED]> writes:
> >>
> >>> Anyway, I was getting the same failure on solaris and the attached
> >>> patch solv
On Thu, 2007-09-06 at 04:45 +0200, Enrico Forestieri wrote:
> Please, try the attached patch.
BTW I am using autoconf-2.60-21 and automake-1.9.6-35.
The attachment shows the rejected change from your patch, because the
relevant target wasn't there to patch.
Still failed with the same problem.
H
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
As QtGui will be brought by the frontend, it will not hurt at all now.
But does it hurt the non-gui programs in terms of start-up time on
some platforms?
But, longer term, when/if we create a support dll, this dll sho
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> As QtGui will be brought by the frontend, it will not hurt at all now.
But does it hurt the non-gui programs in terms of start-up time on
some platforms?
> But, longer term, when/if we create a support dll, this dll should
> link with QtCore only.
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Jean-Marc Lasgouttes wrote:
Enrico Forestieri <[EMAIL PROTECTED]> writes:
Anyway, I was getting the same failure on solaris and the attached
patch solves the problem for me.
Please do not apply the patch right now. I
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>>> Please do not apply the patch right now. I think it is better to link
>>> libsupport against QT_LIB instead of QT_CORE_LIB.
>>
>> Surely you mean the opposite aren't you?
>
> No, actually, what I mean is really the patch below.
Hmpf.
svndiff sr
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Enrico Forestieri <[EMAIL PROTECTED]> writes:
>>
>>> Anyway, I was getting the same failure on solaris and the attached
>>> patch solves the problem for me.
>>
>> Please do not apply the patch right now. I think it is b
Jean-Marc Lasgouttes wrote:
Enrico Forestieri <[EMAIL PROTECTED]> writes:
Anyway, I was getting the same failure on solaris and the attached
patch solves the problem for me.
Please do not apply the patch right now. I think it is better to link
libsupport against QT_LIB instead of QT_CORE_LIB.
On Thursday 06 September 2007 03:44:24 Enrico Forestieri wrote:
> Are you sure that it was not failing later on tex2lyx?
Sure it was. But I guess you knew that. :-)
--
José Abílio
On Thu, Sep 06, 2007 at 10:29:55AM +0200, Jean-Marc Lasgouttes wrote:
> Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> > Anyway, I was getting the same failure on solaris and the attached
> > patch solves the problem for me.
>
> Please do not apply the patch right now. I think it is better to
Enrico Forestieri <[EMAIL PROTECTED]> writes:
> Anyway, I was getting the same failure on solaris and the attached
> patch solves the problem for me.
Please do not apply the patch right now. I think it is better to link
libsupport against QT_LIB instead of QT_CORE_LIB.
JMarc
On Wed, Sep 05, 2007 at 06:33:13AM -0400, Richard Heck wrote:
> José Matos wrote:
> > On Wednesday 05 September 2007 02:55:46 Enrico Forestieri wrote:
> >
> >> You are missing -lfontconfig, apparently. Please, see whether the attach
> >> patch helps. If yes, please apply it yourself as I will
On Wed, Sep 05, 2007 at 08:35:41PM +1000, Darren Freeman wrote:
> On Tue, 2007-09-04 at 18:44 -0400, Richard Heck wrote:
> > On Linux. It links fine in src/ itself.
>
> Hi all,
>
> I just updated to the latest SVN, r20063, of the 1.5 branch and hit make
> (Linux). Only change was to os_unix.cpp
On Wed, Sep 05, 2007 at 11:20:59AM +0100, José Matos wrote:
> On Wednesday 05 September 2007 02:55:46 Enrico Forestieri wrote:
> > You are missing -lfontconfig, apparently. Please, see whether the attach
> > patch helps. If yes, please apply it yourself as I will be away for one
> > or two days.
>
On Tue, 2007-09-04 at 18:44 -0400, Richard Heck wrote:
> On Linux. It links fine in src/ itself.
Hi all,
I just updated to the latest SVN, r20063, of the 1.5 branch and hit make
(Linux). Only change was to os_unix.cpp . It was clearly running the
config script again as it did a lot of checks befo
José Matos wrote:
On Wednesday 05 September 2007 02:55:46 Enrico Forestieri wrote:
You are missing -lfontconfig, apparently. Please, see whether the attach
patch helps. If yes, please apply it yourself as I will be away for one
or two days.
It does not work, it fails with the same err
On Wednesday 05 September 2007 02:55:46 Enrico Forestieri wrote:
> You are missing -lfontconfig, apparently. Please, see whether the attach
> patch helps. If yes, please apply it yourself as I will be away for one
> or two days.
It does not work, it fails with the same error.
If I add fontcon
On Tue, Sep 04, 2007 at 06:44:21PM -0400, Richard Heck wrote:
> On Linux. It links fine in src/ itself.
>
> make[2]: Entering directory `/cvs/lyx-devel/trunk/src/client'
> /bin/sh ../../libtool --tag=CXX --mode=link g++ -g -O -o lyxclient
> boost.o client.o debug.o gettext.o Messages.o
> ..
On Linux. It links fine in src/ itself.
make[2]: Entering directory `/cvs/lyx-devel/trunk/src/client'
/bin/sh ../../libtool --tag=CXX --mode=link g++ -g -O -o lyxclient
boost.o client.o debug.o gettext.o Messages.o
../../src/support/liblyxsupport.la ../../boost/liblyxboost.la -laspell
-
José Matos wrote:
On Friday 31 August 2007 11:06:25 Helge Hafting wrote:
I happen to have the required boost libraries,
so I tried configuring --without-included-boost.
I assume using the shared boost libraries saves memory
if I get some other app that also uses them.
The final linking then
Helge Hafting wrote:
> I happen to have the required boost libraries,
> so I tried configuring --without-included-boost.
> I assume using the shared boost libraries saves memory
> if I get some other app that also uses them.
Note that boost is mostly c++ templates... so you shouldn't save much.
On Friday 31 August 2007 11:06:25 Helge Hafting wrote:
> I happen to have the required boost libraries,
> so I tried configuring --without-included-boost.
> I assume using the shared boost libraries saves memory
> if I get some other app that also uses them.
>
> The final linking then died with lot
I happen to have the required boost libraries,
so I tried configuring --without-included-boost.
I assume using the shared boost libraries saves memory
if I get some other app that also uses them.
The final linking then died with lots of
protests about missing boost functions.
Adding
-lboost_fil
FYI: I am able to compile LyX 1.5.0svn again on SuSE 9.3 :-)
That is good to know, but I still have problems with SuSE10. I guess
you are still using gcc 3.x on SuSE9.3, right?
Bo
Bo Peng wrote:
scons now removes the fast_start option so it is 'from scratch' every
time. Anyway, I will try it today on a SuSE.
FYI: I am able to compile LyX 1.5.0svn again on SuSE 9.3 :-)
There seems to be some problem with CPPFLAGS="-gstabs -O". Don't ask me
any details, scons option mod
Anyway, I will try it today on a SuSE.
I have had a bunch of problems in the process of compiling lyx on suse 10.
1. when installing scons, python does not find distutils. It took me a
while to figure out that I need to install python-devel package.
2. qt is also divided into several smaller p
Georg Baum <[EMAIL PROTECTED]> writes:
| Michael Gerz wrote:
|
| > Georg,
| >
| > I get these link errors:
|
|
|
| This is what I get for a successfull build, using the include boost:
Right incompabilities between compiler/linker/binutils.
--
Lgb
> I compile with scons. Maybe I have
> to rebuild everything from scratch...
scons now removes the fast_start option so it is 'from scratch' every
time. Anyway, I will try it today on a SuSE.
Cheers,
Bo
Michael Gerz wrote:
> Georg,
>
> I get these link errors:
This is what I get for a successfull build, using the include boost:
/usr/lib/gcc-lib/i586-suse-linux/3.3.5/../../../../i586-suse-linux/bin/ld:
`.gnu.linkonce.t._ZN5boost9re_detail21basic_regex_formatterINS0_19string_out_iteratorISsEEN
Am Sonntag, 15. Oktober 2006 13:31 schrieb Michael Gerz:
> Georg,
>
> I get these link errors:
>
> debug/libs/libsupport.a(docstream.o)
(.gnu.linkonce.t._ZN65_GLOBAL__N__home_software_lyx_trunk_src_support_docstre
> am.CD0sejc18utf8_codecvt_facetC1ESt13_Ios_Openmodej+0xb6): In function
> `(anony
Georg,
I get these link errors:
debug/libs/libsupport.a(docstream.o)(.gnu.linkonce.t._ZN65_GLOBAL__N__home_software_lyx_trunk_src_support_docstre
am.CD0sejc18utf8_codecvt_facetC1ESt13_Ios_Openmodej+0xb6): In function
`(anonymous namespace)::utf8_codecvt_facet
::do_max_length() const':
/home/so
Am Samstag, 14. Oktober 2006 16:02 schrieb Michael Gerz:
> Well, link fails indeed :-( With million of warnings, it is impossible
> to determine what went wrong.
make >o.log 2>e.log
and looking at the first lines in e.log/o.log works for me in such cases.
> Did you really succeed on SuSE 9.3?
Georg Baum schrieb:
Does the link fail not? If it does not fail ignore this. I get similar
messages on my SuSE 9.3 box, the reason is a gcc/binutils compatibility
problem that is solved in newer versions. As long as the link succeeeds I
have never seen any problems resulting from this.
Well,
Am Samstag, 14. Oktober 2006 14:31 schrieb Michael Gerz:
> Hi,
>
> since about 2 days I cannot link any more (SuSE Linux 9.3). I get
> millions of uncomprehensible console messages:
>
> /usr/lib/gcc-lib/i586-suse-linux/3.3.5/../../../../i586-suse-linux/bin/ld:
>
`.gnu.linkonce.t._ZN5boost9re_d
Hi,
since about 2 days I cannot link any more (SuSE Linux 9.3). I get
millions of uncomprehensible console messages:
/usr/lib/gcc-lib/i586-suse-linux/3.3.5/../../../../i586-suse-linux/bin/ld:
`.gnu.linkonce.t._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_m
On Fri, Sep 09, 2005 at 04:53:11PM +0200, Jean-Marc Lasgouttes wrote:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Georg> Jean-Marc Lasgouttes wrote:
> >> Actually, I tried it, and it seems to just work.
> >>
> >> Comments?
>
> Georg> I did not test it, but the code looks good.
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Jean-Marc Lasgouttes wrote:
>> Actually, I tried it, and it seems to just work.
>>
>> Comments?
Georg> I did not test it, but the code looks good.
I committed it.
JMarc
Jean-Marc Lasgouttes wrote:
> Actually, I tried it, and it seems to just work.
>
> Comments?
I did not test it, but the code looks good.
Georg
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> I have a better solution, which is to move enumLabel out of
Jean-Marc> Counters, where it does not belong anyway. The code should
Jean-Marc> go in
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> I have a better solution, which is to move enumLabel out of
Jean-Marc> Counters, where it does not belong anyway. The code should
Jean-Marc> go in buffer_funcs.C.
Jean-Marc> I'll post a patch.
Here is an untested pa
1 - 100 of 111 matches
Mail list logo
