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_
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, std::allocator >)'
Yuriy
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
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 from:
boost::array::operator[](unsigned lon
Pavel Sanda wrote:
here too.
bisect leads me here:
http://www.lyx.org/trac/changeset/24249
Andre'?
Well, it's not exactly surprising that replacing an empty assert macro
with one that actually barks increases the noise level ;-)
And no, that change is not the problem...
i'm no
> > > > Well, it's not exactly surprising that replacing an empty assert macro
> > > > with one that actually barks increases the noise level ;-)
> > > >
> > > > And no, that change is not the problem...
> > >
> > > i'm not claiming that it is the root of the problem. just that before
> > > this
On Thu, Apr 17, 2008 at 10:51:25PM +0200, Pavel Sanda wrote:
> > > > here too.
> > > >
> > > > bisect leads me here:
> > > > http://www.lyx.org/trac/changeset/24249
> > > > Andre'?
> > >
> > > Well, it's not exactly surprising that replacing an empty assert macro
> > > with one that actually bark
> > > here too.
> > >
> > > bisect leads me here:
> > > http://www.lyx.org/trac/changeset/24249
> > > Andre'?
> >
> > Well, it's not exactly surprising that replacing an empty assert macro
> > with one that actually barks increases the noise level ;-)
> >
> > And no, that change is not the probl
> > here too.
> >
> > bisect leads me here:
> > http://www.lyx.org/trac/changeset/24249
> > Andre'?
>
> Well, it's not exactly surprising that replacing an empty assert macro
> with one that actually barks increases the noise level ;-)
>
> And no, that change is not the problem...
i'm not claim
On Wed, Apr 16, 2008 at 09:09:40AM +0200, Pavel Sanda wrote:
> > g++ -g -O2 -o lyxclient boost.o client.o debug.o gettext.o Messages.o
> > ../../src/support/.libs/liblyxsupport.a -L/usr/lib -lQtCore
> > ../../boost/.libs/liblyxboost.a -lSM -lICE -lz -L/usr/lib64 -lX11
> > ../../src/support/.libs
> g++ -g -O2 -o lyxclient boost.o client.o debug.o gettext.o Messages.o
> ../../src/support/.libs/liblyxsupport.a -L/usr/lib -lQtCore
> ../../boost/.libs/liblyxboost.a -lSM -lICE -lz -L/usr/lib64 -lX11
> ../../src/support/.libs/liblyxsupport.a(debug.o): In function
here too.
bisect leads me h
g++ -g -O2 -o lyxclient boost.o client.o debug.o gettext.o Messages.o
../../src/support/.libs/liblyxsupport.a -L/usr/lib -lQtCore
../../boost/.libs/liblyxboost.a -lSM -lICE -lz -L/usr/lib64 -lX11
../../src/support/.libs/liblyxsupport.a(debug.o): In function
`lyx::LyXErr::disable()':
/cvs/lyx-
On 3/16/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
Abdelrazak Younes wrote:
> Any idea someone?
It's corrected now.
I was wondering why I linked fine. :-)
Bo
Abdelrazak Younes wrote:
Any idea someone?
It's corrected now.
Any idea someone?
LaTeX.obj : error LNK2019: unresolved external symbol "bool __cdecl
boost::filesystem::native(class std::basic_stringstd::char_traits,class std::allocator > const &)"
([EMAIL PROTECTED]@boost@@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@[EMAIL PROTECTED]@2@@std@@@Z)
referenced in fu
Rob <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
>> This is gcc 3.4.2 on FreeBSD 5.3, whic is supposed
| to
>> be current for some time.
>>
>> The question is to know whether we can disable
>> stdlib-debug for this compiler. Or whether we should
>> do it.
>
| I suppose such debug st
Jean-Marc Lasgouttes wrote:
> This is gcc 3.4.2 on FreeBSD 5.3, whic is supposed
to
> be current for some time.
>
> The question is to know whether we can disable
> stdlib-debug for this compiler. Or whether we should
> do it.
I suppose such debug stuff is only in the CVS
repository. When a fina
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| --disable-stdlib-debug solves the problem:
| http://marc.theaimsgroup.com/?l=lyx-devel&m=110657975517441&w=2
Lars> I am leaning to letting that solve the problem, and be done with
Lars> it. Debug mode is after all only used on dev
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> I am still a bit confused
>
| Lars> I need a tea-spoon
>
| OK, the initial message with the errors is here:
| http://marc.theaimsgroup.com/?l=lyx-devel&m=110630812118047&w=2
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I am still a bit confused
Lars> I need a tea-spoon
OK, the initial message with the errors is here:
http://marc.theaimsgroup.com/?l=lyx-devel&m=110630812118047&w=2
--disable-stdlib-debug solves the problem:
http://marc.theaim
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
"Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>>>
| Lars> | Lars> Anything more you want to know? :-)
>>
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>>
Lars> | Lars> Anything more you want to know? :-)
>>
Lars> | Yes. What can we do about this poor freebsd compi
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Anything more you want to know? :-)
>
| Yes. What can we do about this poor freebsd compiler? Do you have
| ideas about that?
There are two errors about concept checks flyin
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Anything more you want to know? :-)
>
| Yes. What can we do about this poor freebsd compiler? Do you have
| ideas about that?
Why anything if the -- switch fixes the proble
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Anything more you want to know? :-)
Yes. What can we do about this poor freebsd compiler? Do you have
ideas about that?
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
| Lars> Lars, did you read that thread?
>
| Lars> This thread?
>
| Yes.
So yes then.
Anything more you want to know? :-)
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: |
Lars> Lars, did you read that thread?
Lars> This thread?
Yes.
JMarc
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Lars, did you read that thread?
This thread?
--
Lgb
Jean-Marc Lasgouttes wrote:
> Rob> It's because of both, _GLIBCXX_DEBUG and _GLIBCXX_DEBUG_PEDANTIC.
>
> Rob> Does that make sense?
>
> So the stdlibc++ debug feature is broken with your compiler version, I
> guess. You should ask the freebsd people for more info. When we know
> exactly what happen
> "Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
>> It seems that at least one of these is broken. If you have time,
>> you could try to turn them off one by one and see which one is the
>> culprit.
Rob> It's because of both, _GLIBCXX_DEBUG and _GLIBCXX_DEBUG_PEDANTIC.
Rob> Does that make s
Jean-Marc Lasgouttes wrote:
>> Rob Lahaye writes:
>
> Rob> Yep, that solves the problem; not that I know what I'm doing
> Rob> though. But LyX compiles like a charm!
>
> Rob> Can you explain a little? Is this a bug, or a misbehaving feature
> Rob> of FreeBSD, or perhaps LyX or gcc?
>
> I think
> "Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
Rob> Yep, that solves the problem; not that I know what I'm doing
Rob> though. But LyX compiles like a charm!
Rob> Can you explain a little? Is this a bug, or a misbehaving feature
Rob> of FreeBSD, or perhaps LyX or gcc?
I think this is a bug
Jean-Marc Lasgouttes wrote:
>>"Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
>
>
> Rob> I can compile LyX almost; something goes wrong at the very end.
> Rob> At the end of gmake, when the final executable is being linked, I
> Rob> get zillions of following lines:
>
> Rob> $ gmake [...]
> Rob
> "Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes:
Rob> I can compile LyX almost; something goes wrong at the very end.
Rob> At the end of gmake, when the final executable is being linked, I
Rob> get zillions of following lines:
Rob> $ gmake [...]
Rob>
BranchList.o(.gnu.linkonce.t._ZN10__gnu_
Hi,
First: thanks for solving the sh vs. bash issue, which is now working
on my FreeBSD system.
I can compile LyX almost; something goes wrong at the very end.
At the end of gmake, when the final executable is being linked,
I get zillions of following lines:
$ gmake
[...]
BranchList.o(.gnu.link
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| http://bugzilla.lyx.org/show_bug.cgi?id=1702
>
| Lars, could you review the patch enclosed in this bug? Is it needed in
| 1.4.0cvs too?
I cannot find this code in boost 1.31. at all.
this must be 1.3.x only.
--
Lgb
http://bugzilla.lyx.org/show_bug.cgi?id=1702
Lars, could you review the patch enclosed in this bug? Is it needed in
1.4.0cvs too?
JMarc
Hello, I am getting an error at link time for the lyx binary, it's not
finding some symbol, and I know very little about this stl stuff
(sorry). I'm using macosx btw.
The error follows at the end of the email. The symbol it seems to have
problems with is crc_table_t and a quick grep of the
> "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
At the very end of the linking process.
Has someone an idea?
../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
make[3]: *** [lyx] Error 1
make[3]: Leaving directory `/home/juergen/lyx-deve
"Garst R. Reese" <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>>
>> "Garst R. Reese" <[EMAIL PROTECTED]> writes:
>
>> Are you able to reprocude it with a clean checkout?
| I tried make distclean, autogen.sh, configure ..., and that did not
| help.
| I can do a clean checkout if you t
"Garst R. Reese" <[EMAIL PROTECTED]> writes:
| This afternoon's CVS
| version.o vspace.o mathed/libmathed.la insets/libinsets.la
| frontends/libfronten
| ds.la graphics/libgraphics.la support/libsupport.la
| `../sigc++/sigc-config --lib
| s-names | sed -e 's/-lsigc//'` ../sigc++/libsigc.la -LNO
71 matches
Mail list logo
