On Thu, Jan 21, 2021 at 10:06:27AM -0500, Scott Kostyshak wrote:
> On Thu, Jan 21, 2021 at 09:05:43AM +0200, Yuriy Skalko wrote:
> > Yes, this is expected, since system libQt5*.so are dependent on libstdc++
> > (assuming you haven't rebuild Qt with libc++). ldd displays all required
> >
On Thu, Jan 21, 2021 at 09:05:43AM +0200, Yuriy Skalko wrote:
> >
> > I've tried to reproduce on Linux with Clang and libc++ but cannot.
> > However, one thing that I do not understand is that in the output from
> > ldd, both libstdc++.so.6 and libc++.so.1 show up. See attached. Is this
> >
Am 21.01.2021 um 08:05 schrieb Yuriy Skalko :
>
>> I've tried to reproduce on Linux with Clang and libc++ but cannot.
>> However, one thing that I do not understand is that in the output from
>> ldd, both libstdc++.so.6 and libc++.so.1 show up. See attached. Is this
>> expected?
>> Scott
>>
I've tried to reproduce on Linux with Clang and libc++ but cannot.
However, one thing that I do not understand is that in the output from
ldd, both libstdc++.so.6 and libc++.so.1 show up. See attached. Is this
expected?
Scott
linux-vdso.so.1 (0x7ffd059e5000)
On Wed, Jan 20, 2021 at 07:24:54PM +0100, Jean-Marc Lasgouttes wrote:
> Le 20/01/2021 à 18:01, Scott Kostyshak a écrit :
> > It took me a while to figure out this was going on, but Kornel helped
> > fix things for the bundled Hunspell (even for the bundled Hunspell we
> > were trying to link
Le 20/01/2021 à 18:01, Scott Kostyshak a écrit :
It took me a while to figure out this was going on, but Kornel helped
fix things for the bundled Hunspell (even for the bundled Hunspell we
were trying to link against the system Hunspell in CMake). I'm planning
to search for materials to
On Wed, Jan 20, 2021 at 05:43:08PM +0100, Jean-Marc Lasgouttes wrote:
> Le 20/01/2021 à 17:14, Scott Kostyshak a écrit :
> > > > I've tried to reproduce on Linux with Clang and libc++ but cannot.
> > > > However, one thing that I do not understand is that in the output from
> > > > ldd, both
Le 20/01/2021 à 17:14, Scott Kostyshak a écrit :
I've tried to reproduce on Linux with Clang and libc++ but cannot.
However, one thing that I do not understand is that in the output from
ldd, both libstdc++.so.6 and libc++.so.1 show up. See attached. Is this
expected?
I wonder if that may be a
On Wed, Jan 20, 2021 at 03:48:45PM +0100, Kornel Benko wrote:
> Am Wed, 20 Jan 2021 00:16:49 -0500
> schrieb Scott Kostyshak :
>
> > On Tue, Jan 19, 2021 at 11:17:25PM +0200, Yuriy Skalko wrote:
> > > > The next step from my side should be clang installation and debugging
> > > > this patch
Am Wed, 20 Jan 2021 00:16:49 -0500
schrieb Scott Kostyshak :
> On Tue, Jan 19, 2021 at 11:17:25PM +0200, Yuriy Skalko wrote:
> > > The next step from my side should be clang installation and debugging
> > > this patch there. But it can happen not very soon.
> >
> > It happened sooner than I
On Tue, Jan 19, 2021 at 11:17:25PM +0200, Yuriy Skalko wrote:
> > The next step from my side should be clang installation and debugging
> > this patch there. But it can happen not very soon.
>
> It happened sooner than I expected. I've got Clang 11 from winlibs.com (it
> uses libstdc++,
The next step from my side should be clang installation and debugging this patch there. But it can happen not very soon.
It happened sooner than I expected. I've got Clang 11 from winlibs.com
(it uses libstdc++, unfortunately libc++ is not available here). It
compiles LyX on Windows without
Thanks Stephan. It crashes on the call to move(?) assignment operator, but it
is still not clear looking on these sources. I haven't tried Valgrind yet.
To trigger the crash I picked the second file out of the five files in the
lastfiles vector. (But this happens with the first and with the
OK, now will you commit the replacements?
Kornel
Please commit them. I don't have patch and only figured out why that
call is considered ambiguous by Clang.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Thu, 14 Jan 2021 22:00:33 +0200
schrieb Yuriy Skalko :
> >
> > Maybe '-std=c++17'?
>
> AFAIR Scott successfully compiled LyX with -std=c++20 on Clang. Other
> compiler options also seem usual.
>
>
> Yuriy
OK, now will you commit the replacements?
Kornel
pgpOik6ZxF44D.pgp
Am 14.01.2021 um 20:56 schrieb Yuriy Skalko :
>
>> I used the debugger to bring some light into it.
>
> Thanks Stephan. It crashes on the call to move(?) assignment operator, but it
> is still not clear looking on these sources. I haven't tried Valgrind yet.
To trigger the crash I picked the
Maybe '-std=c++17'?
AFAIR Scott successfully compiled LyX with -std=c++20 on Clang. Other
compiler options also seem usual.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
I used the debugger to bring some light into it.
Thanks Stephan. It crashes on the call to move(?) assignment operator,
but it is still not clear looking on these sources. I haven't tried
Valgrind yet.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
Am 14.01.2021 um 19:45 schrieb Scott Kostyshak :
>
> On Thu, Jan 14, 2021 at 05:36:58PM +0100, Jean-Marc Lasgouttes wrote:
>> Le 14/01/2021 à 16:53, Scott Kostyshak a écrit :
>>> On Thu, Jan 14, 2021 at 09:34:37AM +0100, Jean-Marc Lasgouttes wrote:
Le 13/01/2021 à 17:59, Scott Kostyshak a
Am Thu, 14 Jan 2021 21:17:26 +0200
schrieb Yuriy Skalko :
> > Yes, it helps. Now the next are
> > /usr2/src/lyx/lyx-git/src/graphics/GraphicsCacheItem.cpp:445
> > /usr2/src/lyx/lyx-git/src/mathed/MathExtern.cpp:602
> > /usr2/src/lyx/lyx-git/src/mathed/MathExtern.cpp:687
>
Yes, it helps. Now the next are
/usr2/src/lyx/lyx-git/src/graphics/GraphicsCacheItem.cpp:445
/usr2/src/lyx/lyx-git/src/mathed/MathExtern.cpp:602
/usr2/src/lyx/lyx-git/src/mathed/MathExtern.cpp:687
/usr2/src/lyx/lyx-git/src/mathed/MathExtern.cpp:772
On Thu, Jan 14, 2021 at 07:48:51PM +0100, Jean-Marc Lasgouttes wrote:
> Le 14/01/2021 à 19:45, Scott Kostyshak a écrit :
> > Thanks, this is good to know. What is your intuition for when it would
> > be helpful to try the different C++ standard library?
>
> I do not have an intuition about it. I
Am Thu, 14 Jan 2021 20:30:03 +0200
schrieb Yuriy Skalko :
> > I cannot even compile everything under clang8
> > /usr2/src/lyx/lyx-git/src/support/FileMonitor.cpp:62:9: error: call to
> > 'make_unique' is
> > ambiguous return make_unique(instance().getGuard(filename));
> >
Should it work w/o -std=c++17? What do expect to happen with different
compiler switches for build of Qt-libs and LyX?
On GCC it works now with all standards: from C++11 to C++20.
The show stopper with -mmacosx-version-min=10.10 is:
Le 14/01/2021 à 19:45, Scott Kostyshak a écrit :
Thanks, this is good to know. What is your intuition for when it would
be helpful to try the different C++ standard library?
I do not have an intuition about it. I mainly compile with different
compilers/libc to see whether it breaks or
On Thu, Jan 14, 2021 at 05:36:58PM +0100, Jean-Marc Lasgouttes wrote:
> Le 14/01/2021 à 16:53, Scott Kostyshak a écrit :
> > On Thu, Jan 14, 2021 at 09:34:37AM +0100, Jean-Marc Lasgouttes wrote:
> > > Le 13/01/2021 à 17:59, Scott Kostyshak a écrit :
> > > > I just tested with Clang and cannot
I cannot even compile everything under clang8
/usr2/src/lyx/lyx-git/src/support/FileMonitor.cpp:62:9: error: call to
'make_unique' is
ambiguous return make_unique(instance().getGuard(filename));
^~~~
Am 14.01.2021 um 17:57 schrieb Stephan Witt :
>
> Am 14.01.2021 um 17:09 schrieb Stephan Witt :
>>
>> Am 14.01.2021 um 09:30 schrieb Yuriy Skalko :
>>>
Sorry, I’ve reverted the change for now locally. I can answer your
questions later…
Perhaps the compiler flags of the autotools
Am 14.01.2021 um 17:09 schrieb Stephan Witt :
>
> Am 14.01.2021 um 09:30 schrieb Yuriy Skalko :
>>
>>> Sorry, I’ve reverted the change for now locally. I can answer your
>>> questions later…
>>> Perhaps the compiler flags of the autotools build are of interest (but
>>> cmake build crashes
Le 14/01/2021 à 16:53, Scott Kostyshak a écrit :
On Thu, Jan 14, 2021 at 09:34:37AM +0100, Jean-Marc Lasgouttes wrote:
Le 13/01/2021 à 17:59, Scott Kostyshak a écrit :
I just tested with Clang and cannot reproduce. Stephan, does the list need to have more than one
"recent file"? Note that the
Am Wed, 13 Jan 2021 11:59:28 -0500
schrieb Scott Kostyshak :
> On Wed, Jan 13, 2021 at 10:37:30AM +0100, Jean-Marc Lasgouttes wrote:
> > Le 13/01/2021 à 10:21, Yuriy Skalko a écrit :
> > > > Hi Yuriy,
> > > >
> > > > I’m seeing a crash after this commit when using File->Open recent.
> > > >
>
Am 14.01.2021 um 09:30 schrieb Yuriy Skalko :
>
>> Sorry, I’ve reverted the change for now locally. I can answer your questions
>> later…
>> Perhaps the compiler flags of the autotools build are of interest (but cmake
>> build crashes either):
>> Configuration
>> Host type:
On Thu, Jan 14, 2021 at 09:34:37AM +0100, Jean-Marc Lasgouttes wrote:
> Le 13/01/2021 à 17:59, Scott Kostyshak a écrit :
> > I just tested with Clang and cannot reproduce. Stephan, does the list need
> > to have more than one "recent file"? Note that the recent files are stored
> > in the
Le 13/01/2021 à 17:59, Scott Kostyshak a écrit :
I just tested with Clang and cannot reproduce. Stephan, does the list need to have more than one
"recent file"? Note that the recent files are stored in the "session" file. You
could experiment by seeing if it depends on which file you choose or
Sorry, I’ve reverted the change for now locally. I can answer your questions
later…
Perhaps the compiler flags of the autotools build are of interest (but cmake
build crashes either):
Configuration
Host type: x86_64-apple-darwin18.7.0
Special build flags: build=release
Am 13.01.2021 um 17:59 schrieb Scott Kostyshak :
>
> On Wed, Jan 13, 2021 at 10:37:30AM +0100, Jean-Marc Lasgouttes wrote:
>> Le 13/01/2021 à 10:21, Yuriy Skalko a écrit :
Hi Yuriy,
I’m seeing a crash after this commit when using File->Open recent.
I’m having 5
On Wed, Jan 13, 2021 at 10:37:30AM +0100, Jean-Marc Lasgouttes wrote:
> Le 13/01/2021 à 10:21, Yuriy Skalko a écrit :
> > > Hi Yuriy,
> > >
> > > I’m seeing a crash after this commit when using File->Open recent.
> > >
> > >
> > > I’m having 5 files in list and the first entry has nullptr as
>
Le 13/01/2021 à 10:21, Yuriy Skalko a écrit :
Hi Yuriy,
I’m seeing a crash after this commit when using File->Open recent.
I’m having 5 files in list and the first entry has nullptr as private
data.
Hi Stephan,
Sorry for late answer. Does it crash always on choosing the first file
in
Am 13.01.2021 um 10:21 schrieb Yuriy Skalko :
>
>> Hi Yuriy,
>> I’m seeing a crash after this commit when using File->Open recent.
>> I’m having 5 files in list and the first entry has nullptr as private data.
>
> Hi Stephan,
> Sorry for late answer. Does it crash always on choosing the first
Hi Yuriy,
I’m seeing a crash after this commit when using File->Open recent.
I’m having 5 files in list and the first entry has nullptr as private data.
Hi Stephan,
Sorry for late answer. Does it crash always on choosing the first file
in Recent list? I cannot reproduce this on Windows and
Hi Yuriy,
I’m seeing a crash after this commit when using File->Open recent.
I’m having 5 files in list and the first entry has nullptr as private data.
@frame 4$ print lastfiles
(lyx::LastFilesSection::LastFiles) $0 = size=5 {
[0] = {
d = 0x
}
[1] = {
d =
41 matches
Mail list logo
