On 10/14/20 3:25 PM, Yuriy Skalko wrote:
>> It's the other way that's needed here:
>>
>> template<>
>> unsigned long long convert(string const & s)
>>
>> {
>>
>> return strtoull(s);
>>
>> }
>>
>>
>> I assume that will fix it.
>>
>>
>> Riki
> Thanks, it helps.
Great, fixed then.
Riki
--
lyx-dev
> It's the other way that's needed here:
>
> template<>
> unsigned long long convert(string const & s)
>
> {
>
> return strtoull(s);
>
> }
>
>
> I assume that will fix it.
>
>
> Riki
Thanks, it helps.
Yuriy
diff --git a/src/support/convert.cpp b/src/support/convert.cpp
index af0ad62f2b..7
On 10/14/20 12:50 PM, José Abílio Matos wrote:
On Wednesday, October 14, 2020 4:37:18 PM WEST Richard Kimberly Heck
wrote:
> I guess size_t must be unsigned long long on your machine? Can you try
> adding a template declaration for convert to
> support/convert.cpp?
>
> Riki
It is alread
> I guess size_t must be unsigned long long on your machine? Can you try adding
> a template declaration for convert to support/convert.cpp?
>
> Riki
As José said it is already defined on my 64-bit system. Probably CMake
files (I use it for build) should be updated.
Yuriy
--
lyx-devel mailing
On Wednesday, October 14, 2020 4:37:18 PM WEST Richard Kimberly Heck wrote:
> I guess size_t must be unsigned long long on your machine? Can you try
> adding a template declaration for convert to
> support/convert.cpp?
>
> Riki
My first joke would be to replace all the code by:
#include
auto
On Wednesday, October 14, 2020 4:37:18 PM WEST Richard Kimberly Heck wrote:
> I guess size_t must be unsigned long long on your machine? Can you try
> adding a template declaration for convert to
> support/convert.cpp?
>
> Riki
It is already there:
#ifdef HAVE_LONG_LONG_INT
template<>
string con
On 10/14/20 11:12 AM, Yuriy Skalko wrote:
I have linking error after commit 28ae543a (Fix signed-ness warnings):
src/CMakeFiles/LyX2.4.dir/output_latex.cpp.obj:output_latex.cpp:(.text+0x1b1a):
undefined reference to `unsigned long long lyx::convert,
std::allocator > >(std::__cxx11::basic_string,
On 08/09/2019 20:47, pdv wrote:
On 08/09/2019 17:47, Kornel Benko wrote:
Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De
Visschere:
In the source files (ConverterCache.cpp, Application.cpp,
FileName.cpp and GuiClipboard.cpp) I don’t see macro’s which could
optionally include th
On 09/09/2019 11:49, pdv wrote:
On 08/09/2019 21:12, Jean-Marc Lasgouttes wrote:
Le 08/09/2019 à 14:14, Patrick De Visschere a écrit :
LyX includes a 3thparty boost-version (1.68), but I don’t find any
references to it in my XCode project and I think I’m actually using
my macports boost (which
On 08/09/2019 21:12, Jean-Marc Lasgouttes wrote:
Le 08/09/2019 à 14:14, Patrick De Visschere a écrit :
LyX includes a 3thparty boost-version (1.68), but I don’t find any
references to it in my XCode project and I think I’m actually using my
macports boost (which is 1.71).
This might explain it:
> On 9 Sep 2019, at 00:41, Stephan Witt wrote:
>
> Am 08.09.2019 um 22:44 schrieb Patrick De Visschere :
>>
>>
>>
>>> On 8 Sep 2019, at 21:03, Stephan Witt wrote:
>>>
>>> Am 08.09.2019 um 20:47 schrieb pdv :
On 08/09/2019 17:47, Kornel Benko wrote:
> Am Sonntag, 8. September
Am 08.09.2019 um 22:44 schrieb Patrick De Visschere :
>
>
>
>> On 8 Sep 2019, at 21:03, Stephan Witt wrote:
>>
>> Am 08.09.2019 um 20:47 schrieb pdv :
>>>
>>> On 08/09/2019 17:47, Kornel Benko wrote:
Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
> In the
> On 8 Sep 2019, at 21:03, Stephan Witt wrote:
>
> Am 08.09.2019 um 20:47 schrieb pdv :
>>
>> On 08/09/2019 17:47, Kornel Benko wrote:
>>> Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and
Le 08/09/2019 à 14:14, Patrick De Visschere a écrit :
LyX includes a 3thparty boost-version (1.68), but I don’t find any
references to it in my XCode project and I think I’m actually using my
macports boost (which is 1.71).
This might explain it: I’ve upgraded my macports boost and this breaks
Am 08.09.2019 um 20:47 schrieb pdv :
>
> On 08/09/2019 17:47, Kornel Benko wrote:
>> Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
>>> In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and
>>> GuiClipboard.cpp) I don’t see macro’s which could opti
On 08/09/2019 17:47, Kornel Benko wrote:
Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and
GuiClipboard.cpp) I don’t see macro’s which could optionally include the
relevant code which is probabl
Am 08.09.2019 um 14:14 schrieb Patrick De Visschere :
>
> Yes, I have a few different settings (but I didn’t change them recently as
> far as I know) and I’m using (gui) CMake 3.15.1
> and XCode = Version 10.3 (10G8)
I’m using
- cmake version 3.12.0
- Xcode 10.3, Build version 10G8
ATM, I’m una
Am Sonntag, 8. September 2019, 14:14:15 CEST schrieb Patrick De Visschere:
> In the source files (ConverterCache.cpp, Application.cpp, FileName.cpp and
> GuiClipboard.cpp) I don’t see macro’s which could optionally include the
> relevant code which is probably in the boost::crc module. I suppose
Yes, I have a few different settings (but I didn’t change them recently as far
as I know) and I’m using (gui) CMake 3.15.1
and XCode = Version 10.3 (10G8)
LYX_CPACK = ON : Use the CPack management (Implies LYX_INSTALL option)
LYX_LOCALVERSIONING = OFF : Add version info to created package name (o
Am 08.09.2019 um 10:02 schrieb Patrick De Visschere :
>
> Sorry, mistyped the last “f”: it should have been 01ee3bf1e5, the master
> branch on 5 sept.
I see. Yes, this is HEAD for me too. This is what works for me.
Perhaps you have different cmake flags?
I have:
-- LYX_CPACK
Sorry, mistyped the last “f”: it should have been 01ee3bf1e5, the master branch
on 5 sept.
> On 8 Sep 2019, at 09:34, Stephan Witt wrote:
>
> Am 07.09.2019 um 10:14 schrieb pdv :
>>
>> LyX fails to build on macos (Mojave, CMake, XCode) with the latest commit
>> (01ee3bf1f5) with message:
>>
Am 07.09.2019 um 10:14 schrieb pdv :
>
> LyX fails to build on macos (Mojave, CMake, XCode) with the latest commit
> (01ee3bf1f5) with message:
>
> Undefined symbols for architecture x86_64:
> "boost::assertion_failed_msg(char const*, char const*, char const*, char
> const*, long)", referenced
On 10/11/13 15:02, Jean-Marc Lasgouttes wrote:
> The best to make it work is to have a look at getStatus in
> frontends/qt4/GuiView.cpp. There you can expand the current handling
> of LFUN_DIALOG_SHOW to mark the function as disabled as needed.
>
> Then, the patch you sent should just work.
I jus
Le 10/11/2013 14:19, Tommaso Cucinotta a écrit :
On 10/11/13 13:09, Jean-Marc Lasgouttes wrote:
Or mark the lfun "unknown" when not supported.
how do I do this marking ? For now, the chat is activated via
A-x dialog-show chat
The best to make it work is to have a look at getStatus in
fr
On 10/11/13 13:09, Jean-Marc Lasgouttes wrote:
> Or mark the lfun "unknown" when not supported.
how do I do this marking ? For now, the chat is activated via
A-x dialog-show chat
it's not a real LFUN, just a request to show a specific dialog. Is OptItem
going to work in such case ?
Is the on
Or mark the lfun "unknown" when not supported.
Jmarc
Georg Baum a écrit :
>Tommaso Cucinotta wrote:
>
>> One tiny issue, though: the "LyX Chat" menu in stdmenus.inc: that is
>going
>> to be added anyway, even though the "dialog-show lyx-chat" is not
>going to
>> be anyway meaningful without US
Tommaso Cucinotta wrote:
> One tiny issue, though: the "LyX Chat" menu in stdmenus.inc: that is going
> to be added anyway, even though the "dialog-show lyx-chat" is not going to
> be anyway meaningful without USE_QXMPP ?
>
> Is there a way to get rid of the menu entry as well, in such case ?
Ye
Am Samstag, 9. November 2013 um 23:25:27, schrieb Tommaso Cucinotta
> On 09/11/13 18:56, Kornel Benko wrote:
> > /usr/src/lyx/lyx/src/frontends/qt4/GuiView.cpp:4177: undefined reference to
> > `lyx::frontend::createGuiBuddies(lyx::frontend::GuiView&)'
> > /usr/src/lyx/lyx/src/frontends/qt4/GuiVi
On 09/11/13 18:56, Kornel Benko wrote:
> /usr/src/lyx/lyx/src/frontends/qt4/GuiView.cpp:4177: undefined reference to
> `lyx::frontend::createGuiBuddies(lyx::frontend::GuiView&)'
> /usr/src/lyx/lyx/src/frontends/qt4/GuiView.cpp:4183: undefined reference to
> `lyx::frontend::createGuiChat(lyx::fron
2012/8/15 Abdelrazak Younes:
> Yes, same idiom should be used: theLaTeXFonts()
> As a matter of fact, all singletons are gathered in a single class,
> maybe you should also follow this trend.
Thanks. I've implemented the function now to LyX.cpp following the
model of the other singleton access fun
On Tue, Aug 14, 2012 at 10:10 PM, Pavel Sanda wrote:
> Abdelrazak Younes wrote:
>> Maybe it was optimized out by the linker.
>
> Yes this will the problem. If object is in library without being called it
> would be omitted
> unless you use --whole-archive for ld. So either one need to use it in c
Abdelrazak Younes wrote:
> Maybe it was optimized out by the linker.
Yes this will the problem. If object is in library without being called it
would be omitted
unless you use --whole-archive for ld. So either one need to use it in core or
move the
definition to qt4 library. Or use function to o
On 14/08/2012 16:54, Jürgen Spitzmüller wrote:
I seem to be blind. Why does the attached patch fail to link with
autotools? The error I get is
CXXLD lyx
frontends/qt4/liblyxqt4.a(GuiDocument.o): In function
`lyx::frontend::GuiDocument::updateFontlist()':
/home/jspitzm/lyx/lyx-devel/src/frontend
On 08/14/2012 10:54 AM, Jürgen Spitzmüller wrote:
I seem to be blind. Why does the attached patch fail to link with
autotools? The error I get is
CXXLD lyx
frontends/qt4/liblyxqt4.a(GuiDocument.o): In function
`lyx::frontend::GuiDocument::updateFontlist()':
/home/jspitzm/lyx/lyx-devel/src/front
Can you please check current cvs, I just added a path for darwin to
ltmain.sh there.
That works -- thanks!
Bennett
Bennett Helm <[EMAIL PROTECTED]> writes:
| touch src/lyx_main.C
| cvs up -A config/ltmain.sh
| ./configure [...]
| make
|
| fails as before.
Can you please check current cvs, I just added a path for darwin to
ltmain.sh there.
--
Lgb
On Jan 5, 2006, at 12:09 PM, Bennett Helm wrote:
On Jan 5, 2006, at 11:57 AM, Jean-Marc Lasgouttes wrote:
"Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> I'm not understanding here.
Bennett> 1.4.0pre3 works fine (and I did run autogen.sh); it's
Bennett> 1.4.0cvs that gives me
On Jan 5, 2006, at 11:57 AM, Jean-Marc Lasgouttes wrote:
"Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> I'm not understanding here.
Bennett> 1.4.0pre3 works fine (and I did run autogen.sh); it's
Bennett> 1.4.0cvs that gives me the trouble. (And I did not manually
Bennett> run
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> I'm not understanding here.
Bennett> 1.4.0pre3 works fine (and I did run autogen.sh); it's
Bennett> 1.4.0cvs that gives me the trouble. (And I did not manually
Bennett> run autogen.sh on it recently.)
Bennett> Reverting ltmain.
On Jan 5, 2006, at 4:40 AM, Jean-Marc Lasgouttes wrote:
"Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> Most recent cvs fails to link on Mac with gcc-3.3. Any hints?
Did you run autogen.sh over your 1.4.0pre3 distribution? What happens
of you don't? Nowadays, autogen replaces t
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> Most recent cvs fails to link on Mac with gcc-3.3. Any hints?
Did you run autogen.sh over your 1.4.0pre3 distribution? What happens
of you don't? Nowadays, autogen replaces the automake/libtool files in
config/ and it may be tha
> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:
Bennett> Most recent cvs fails to link on Mac with gcc-3.3. Any hints?
It seems that libtool eats the -framework options that the mac needs.
Probably related to Lars' recent update.
JMarc
On Saturday 23 April 2005 16:55, Michael Schmitt wrote:
> Angus Leeming wrote:
> >In a moment of clear thinking, I tried to force the linker to load
> > the qt libraries statically.
> >
> >G.
> >
> >Try two.
> >
> >... back again. The bloody error dialog popped up again, warning
> > me that
Angus Leeming wrote:
In a moment of clear thinking, I tried to force the linker to load the qt
libraries statically.
G.
Try two.
... back again. The bloody error dialog popped up again, warning me that it
couldn't find qt3.dll.
I have NO idea where the linker is getting info about qt3.dll
Jean-Marc Lasgouttes wrote:
>>> Did you succeed with static linking?
>
> Angus> Nope. Haven't tried.
>
> Angus> Do I need to re-compile (witness the QT_DIR,
> Angus> __declspec(dllimport) discussion) or can I just redo the
> Angus> linking step? If the latter, what flags should I pass to the
> A
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>> Isn't it enough to just define QTDIR?
Angus> But I'm not 'exporting' QTDIR, I'm passing it to the configure
Angus> script in a format it will understand and *store*. Thereafter,
Angus> I can run make at my leisure without worrying whet
Jean-Marc Lasgouttes wrote:
> Angus> Just for information, the attached script allows me to build a
> Angus> cross-compiled LyX/Win 1.3.x, although at the moment I mush use
> Angus> the natively compiled qt3.dll if the executable is to actually
> Angus> run. Still working on that one.
>
> Two smal
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Just for information, the attached script allows me to build a
Angus> cross-compiled LyX/Win 1.3.x, although at the moment I mush use
Angus> the natively compiled qt3.dll if the executable is to actually
Angus> run. Still working on
Angus Leeming wrote:
> Jean-Marc Lasgouttes wrote:
>> Angus> Can't we get rid of the automatic X11 thing? I don't want it
>> Angus> and I don't need it to build LyX/Win using the mingw cross
>> Angus> compiler.
>>
>> configure --without-x.
>
> Excellent! The switch works!
>
>> This is needed by
Jean-Marc Lasgouttes wrote:
> Angus> Can't we get rid of the automatic X11 thing? I don't want it
> Angus> and I don't need it to build LyX/Win using the mingw cross
> Angus> compiler.
>
> configure --without-x.
Excellent! The switch works!
> This is needed by qt/mac too; we may want to
> try t
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Can't we get rid of the automatic X11 thing? I don't want it
Angus> and I don't need it to build LyX/Win using the mingw cross
Angus> compiler.
configure --without-x. This is needed by qt/mac too; we may want to
try to make it the
On Thu, 13 Nov 2003, Andre Poenitz wrote:
> On Wed, Nov 12, 2003 at 11:39:01AM +0100, Michael Schmitt wrote:
> > Hello,
> >
> > I would like to remind you of a very simple solution:
> >
> >
> > Index: config/lyxinclude.m4
> > ===
>
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
Michael> I did not ask to make -gstabs the default debug option. But
Michael> for people who have to build the lyx binary many, many times,
Michael> it can be a big relief.
What we could do is, like for the --enable-optimization=-O3 s
Jean-Marc Lasgouttes wrote:
Andre> This does look simple enough. Is there a reason we don't use it
Andre> already?
With which version of gcc/binutils and on which platforms does this work?
It works definitely with gcc 3.3.1 and binutils 2.14.90.0.5 on SuSE 9.0.
It also worked with gcc 3.2.2 on Su
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> This does look simple enough. Is there a reason we don't use it
Andre> already?
With which version of gcc/binutils and on which platforms does this work?
On Wed, Nov 12, 2003 at 11:39:01AM +0100, Michael Schmitt wrote:
> Hello,
>
> from time to time, we discuss about the same problem again: Linking with
> debug information is sooo time-consuming.
>
> I would like to remind you of a very simple solution:
>
>
> Index: config/lyxinclude.m4
> =
Lars Gullik Bjønnes wrote:
>>> On Tue, Nov 04, 2003 at 09:37:35AM +, Angus Leeming wrote:
So, use that script I posted that doesn't merge symbols when
linking. Increases disk footprint but link times are... this
quick.
>>>
>>> Didn't you want to incorporate that into the regualr
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>
>> On Tue, Nov 04, 2003 at 09:37:35AM +, Angus Leeming wrote:
>>> So, use that script I posted that doesn't merge symbols when
>>> linking. Increases disk footprint but link times are... this quick.
>>
>> Didn't you want to in
Andre Poenitz wrote:
> On Tue, Nov 04, 2003 at 09:37:35AM +, Angus Leeming wrote:
>> So, use that script I posted that doesn't merge symbols when
>> linking. Increases disk footprint but link times are... this quick.
>
> Didn't you want to incorporate that into the regualr build
> machinery?
On Tue, Nov 04, 2003 at 09:37:35AM +, Angus Leeming wrote:
> So, use that script I posted that doesn't merge symbols when linking.
> Increases disk footprint but link times are... this quick.
Didn't you want to incorporate that into the regualr build machinery?
Andre'
Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Tue, Nov 04, 2003 at 09:09:48AM +0100, Lars Gullik Bjønnes
> | wrote:
>>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>>
>>> | Linking with -g uses again 203 MB resources which means my 256MB
>>> | box goes into swap
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> And I must admit that I currently always run with
>> "--disable-debug", not because of memory usage, but of linking
>> time.
Andre> I usually do as well, but from time to time a full backtrace is
Andre> helpful...
What I do in such ca
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Nov 04, 2003 at 09:09:48AM +0100, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | Linking with -g uses again 203 MB resources which means my 256MB box goes
>> | into swap again (read "unusable").
>> >
>> | We had
On Tue, Nov 04, 2003 at 09:09:48AM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | Linking with -g uses again 203 MB resources which means my 256MB box goes
> | into swap again (read "unusable").
> >
> | We had been down to 182 MB.
> >
> | What has changed?
>
>
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Linking with -g uses again 203 MB resources which means my 256MB box goes
| into swap again (read "unusable").
>
| We had been down to 182 MB.
>
| What has changed?
No real idea.
Hmm... have you tried to use a newer linker? (binutils)
I think I saw tha
> We used to have support for adding a fake atexit for systems
> which need it but do not have it. I removed that in configure a couple
> months ago because I thought we did not need it (I added it for sunos4)
> and that we would find out soon enough if we did :)
>
> Can you give details on your
Edwin Leuven wrote:
> breaks down (both 2.96 and 3.2)
>
> Has someone an idea what this is about?
>
> Thanks, Ed.
>
> /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 080522a0
> BufferView_pimpl.o: In function `BufferView::Pimpl::selectionRequested()':
> /usr/local/cvs/build
Edwin Leuven <[EMAIL PROTECTED]> writes:
| breaks down (both 2.96 and 3.2)
|
| Has someone an idea what this is about?
|
| Thanks, Ed.
|
| /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 080522a0
| BufferView_pimpl.o: In function `BufferView::Pimpl::selectionRequested()':
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> How much physical/virtual memory do you have?
Juergen> Still 128 MB physical Memory 136 MB Swap
You may try to increase drasticly your swap. A totla of 266M of memory
may not be enough to
Jean-Marc Lasgouttes wrote:
> How much physical/virtual memory do you have?
Still
128 MB physical Memory
136 MB Swap
Let's see if downgrading cures it.
I will reboot with the new (old) kernel now.
Jürgen
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> John Levon wrote:
>> What kernel version do you run ? Try upgrading ... :(
Juergen> Oh no... I've just upgraded to 2.4.16-4GB which is the most
Juergen> recent kernel available for SuSE 7.3
How much physical/virtual me
John Levon wrote:
> what was your old kernel ? was it pre-2.4.10
No, it was 2.4.10
I am just downgrading again.
Jürgen
On Thu, Jun 13, 2002 at 02:49:05PM +0200, Juergen Spitzmueller wrote:
> I've just upgraded to 2.4.16-4GB which is the most recent kernel available for
> SuSE 7.3
what was your old kernel ? was it pre-2.4.10 ?
john
--
"All is change; all yields its place and goes"
- Euripides
On Thursday 13 June 2002 1:49 pm, Juergen Spitzmueller wrote:
> John Levon wrote:
> > What kernel version do you run ? Try upgrading ... :(
>
> Oh no...
> I've just upgraded to 2.4.16-4GB which is the most recent kernel available
> for SuSE 7.3
>
> Juergen.
Maybe this is linked to your problem? T
John Levon wrote:
> What kernel version do you run ? Try upgrading ... :(
Oh no...
I've just upgraded to 2.4.16-4GB which is the most recent kernel available for
SuSE 7.3
Juergen.
On Thu, Jun 13, 2002 at 02:29:30PM +0200, Juergen Spitzmueller wrote:
> This seems to be the relevant part. What to do?
>
> Jun 13 14:07:04 eddy kernel: __alloc_pages: 0-order allocation failed
> (gfp=0x1d2/0)
> Jun 13 14:07:04 eddy kernel: VM: killing process ld
What kernel version do you run
Am Donnerstag, 13. Juni 2002 14:07 schrieb John Levon:
> If you're on linux check your kernel log, it probably decided ld
> was oom
This seems to be the relevant part. What to do?
Jun 13 14:07:04 eddy kernel: __alloc_pages: 0-order allocation failed
(gfp=0x1d2/0)
Jun 13 14:07:04 eddy kernel: VM
On Thu, Jun 13, 2002 at 02:13:04PM +0200, Juergen Spitzmueller wrote:
> ../boost/libs/signals/src/.libs/libboostsignals.a -lXpm -lSM -lICE -lc -lm
> -L/usr/X11R6/lib -lX11
> collect2: ld terminated with signal 9 [Killed], core dumped
If you're on linux check your kernel log, it probably decided
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Angus Leeming <[EMAIL PROTECTED]> writes:
>
| | /bin/ksh ../../libtool --mode=link deccxx -ptr
| | /usr/users/aleem/OTHERS_CODE/lyx/devel-build/lyx_cxx_repository -O2 -o
| | libgraphics.la GraphicsCache.lo GraphicsCacheItem.lo GraphicsConve
Angus Leeming <[EMAIL PROTECTED]> writes:
| /bin/ksh ../../libtool --mode=link deccxx -ptr
| /usr/users/aleem/OTHERS_CODE/lyx/devel-build/lyx_cxx_repository -O2 -o
| libgraphics.la GraphicsCache.lo GraphicsCacheItem.lo GraphicsConverter.lo
| GraphicsImage.lo GraphicsParams.lo -lSM -lICE
On Wed, Mar 06, 2002 at 01:00:38PM +, Angus Leeming wrote:
> Well, it created the symbolic links correctly but didn't build anything.
> Perhaps because the .lo files already exist in the frontends/xforms dir?
> Doesn't sound very likely...
>
> Incidentally, it's a bit of a pain re-creating
On Wednesday 06 March 2002 11:54 am, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
>
> >>
> >> FRONTEND_GUILIB="qt2/*.lo qt2/ui/*.lo qt2/moc/*.lo qt2/ui/moc/*.lo"
> >>
> >> where do you see the xforms stuff.
> >
> | So what is the point of the qt2/xforms director
Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>> FRONTEND_GUILIB="qt2/*.lo qt2/ui/*.lo qt2/moc/*.lo qt2/ui/moc/*.lo"
>>
>> where do you see the xforms stuff.
>
| So what is the point of the qt2/xforms directory? What do I need to change in
| FRONTEND_GUILIB? I certainly don't want to add x
On Wednesday 06 March 2002 11:17 am, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | It appears that the new qt2/xforms stuff isn't being linked into the
frontend
> | library.
> >
> | Incidentally, and separately, I had to change qt2/Makefile.am:
> | -libqt2xforms.l
Angus Leeming <[EMAIL PROTECTED]> writes:
| It appears that the new qt2/xforms stuff isn't being linked into the frontend
| library.
>
| Incidentally, and separately, I had to change qt2/Makefile.am:
| -libqt2xforms.la: link_files $(XFORMS_SOURCES)
| +libqt2xforms.la: link_files $(libqt2xforms_l
On Mon, Sep 03, 2001 at 10:49:17AM +0100, Angus Leeming wrote:
> cxx ... -lXpm /usr/local/lib/libAikSaurus.so -lbz2 -lbz2 -lbz2 -lSM ...
>
> Two questions:
> 1. Why is AikSaurus expanded (Xpm is found in /usr/local/lib and isn't).
probably because AikSaurus installs a libtool .la file, xpm has
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> When I update my lyx CVS directory (cvs update) and "make" the
Angus> updated code, I occasionally get unresolved errors on linking.
Angus> The problem goes away if I "make clean" and then "make" the
Angus> whole schmooze. I was wo
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Mike" == Mike Hildreth <[EMAIL PROTECTED]> writes:
|
| Mike> Hello, I'm very interested to try out LyX here at CERN, but I
| Mike> can't get the current stable releases to link properly. We're
| Mike> running a fairly vanilla HP-UX 10.20a
> "Mike" == Mike Hildreth <[EMAIL PROTECTED]> writes:
Mike> Hello, I'm very interested to try out LyX here at CERN, but I
Mike> can't get the current stable releases to link properly. We're
Mike> running a fairly vanilla HP-UX 10.20a on /afs. In any case, all
Mike> of the code compiles proper
On Tue, 3 Aug 1999 [EMAIL PROTECTED] wrote:
> While I try to link the link application, I obtain the following output :
>
> Undefined first referenced
> symbol in file
> fl_addto_browser_chars lyx_cb.o
[...]
The linker can't find t
90 matches
Mail list logo
