Re: Link error when compiling with -fsanitize=undefined
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 Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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
Re: Link error when compiling with -fsanitize=undefined
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 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 (probably used as 'char') cannot contain the value beyond 127).
> > > >>
> > > >> Expanding the colors in src/ColorCode.h as in attached, removes the
> > > >> sanitize
> > > >> messages.
> > > >
> > > > Nice, that makes sense. 500 seems to be a reasonable ceiling. I suppose
> > > > an
> > > > alternative would be to have the code stop assigning new colors past
> > > > the max. That
> > > > is, I imagine they could just assign the max color value to multiple
> > > > insets?
> > >
> > > But why the 127? Is it that the underlying type of the enum is a signed
> > > char? What does sizeof(ColorCode) return?
> >
> > That is not important from my POV. Sanitize is checking also for
> > portability, so if
> > there is one compiler which would use 'char' for this enum, that would
> > justify the
> > message. Just my 2 cents.
> >
> > > If this is the case, using
> > >enum ColorCode : int {
> > > should help. But I am surprised because the underlying type should be
> > > int (unless -fshort-enums is used):
> > > https://stackoverflow.com/questions/1122096/what-is-the-underlying-type-of-a-c-enum
> >
> > 'int' type may be too big (think on 64-bit (or more) intergers).
> >
> > > > I didn't understand how JMarc's suggestion to change the type to int
> > > > would solve the
> > > > (non) issue.
> > >
> > > I was under the impression that the code would check that the enum value
> > > was one of the declared values. But this is not the case, since a number
> > > of synthetic values between 100 and 127 seem to be valid.
> > >
> > > I also wonder how you triggered it initially. Is it that you really had
> > > 25+ branches, or is it that the code "leaks" color code and creates too
> > > many of them?
> > >
> > > JMarc
>
> JMarc any objection to Kornel's patch?
Ping to JMarc.
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 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 (probably used as 'char') cannot contain the value beyond 127).
> > >>
> > >> Expanding the colors in src/ColorCode.h as in attached, removes the
> > >> sanitize
> > >> messages.
> > >
> > > Nice, that makes sense. 500 seems to be a reasonable ceiling. I suppose an
> > > alternative would be to have the code stop assigning new colors past the
> > > max. That
> > > is, I imagine they could just assign the max color value to multiple
> > > insets?
> >
> > But why the 127? Is it that the underlying type of the enum is a signed
> > char? What does sizeof(ColorCode) return?
>
> That is not important from my POV. Sanitize is checking also for portability,
> so if
> there is one compiler which would use 'char' for this enum, that would
> justify the
> message. Just my 2 cents.
>
> > If this is the case, using
> >enum ColorCode : int {
> > should help. But I am surprised because the underlying type should be
> > int (unless -fshort-enums is used):
> > https://stackoverflow.com/questions/1122096/what-is-the-underlying-type-of-a-c-enum
>
> 'int' type may be too big (think on 64-bit (or more) intergers).
>
> > > I didn't understand how JMarc's suggestion to change the type to int
> > > would solve the
> > > (non) issue.
> >
> > I was under the impression that the code would check that the enum value
> > was one of the declared values. But this is not the case, since a number
> > of synthetic values between 100 and 127 seem to be valid.
> >
> > I also wonder how you triggered it initially. Is it that you really had
> > 25+ branches, or is it that the code "leaks" color code and creates too
> > many of them?
> >
> > JMarc
JMarc any objection to Kornel's patch?
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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.
> >> So each branch will now get colors 103, 104, ..., and so on, so that the
> >> original
> >> enum (probably used as 'char') cannot contain the value beyond 127).
> >>
> >> Expanding the colors in src/ColorCode.h as in attached, removes the
> >> sanitize
> >> messages.
> >
> > Nice, that makes sense. 500 seems to be a reasonable ceiling. I suppose an
> > alternative would be to have the code stop assigning new colors past the
> > max. That
> > is, I imagine they could just assign the max color value to multiple
> > insets?
>
> But why the 127? Is it that the underlying type of the enum is a signed
> char? What does sizeof(ColorCode) return?
That is not important from my POV. Sanitize is checking also for portability,
so if
there is one compiler which would use 'char' for this enum, that would justify
the
message. Just my 2 cents.
> If this is the case, using
>enum ColorCode : int {
> should help. But I am surprised because the underlying type should be
> int (unless -fshort-enums is used):
> https://stackoverflow.com/questions/1122096/what-is-the-underlying-type-of-a-c-enum
'int' type may be too big (think on 64-bit (or more) intergers).
> > I didn't understand how JMarc's suggestion to change the type to int would
> > solve the
> > (non) issue.
>
> I was under the impression that the code would check that the enum value
> was one of the declared values. But this is not the case, since a number
> of synthetic values between 100 and 127 seem to be valid.
>
> I also wonder how you triggered it initially. Is it that you really had
> 25+ branches, or is it that the code "leaks" color code and creates too
> many of them?
>
> JMarc
Kornel
pgpM_fe6UShvg.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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
Re: Link error when compiling with -fsanitize=undefined
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_ignore.
> > > So each branch will now get colors 103, 104, ..., and so on, so that the
> > > original enum
> > > (probably used as 'char') cannot contain the value beyond 127).
> > >
> > > Expanding the colors in src/ColorCode.h as in attached, removes the
> > > sanitize messages.
> >
> > Nice, that makes sense. 500 seems to be a reasonable ceiling. I suppose an
> > alternative would be to have the code stop assigning new colors past the
> > max. That is, I imagine they could just assign the max color value to
> > multiple insets?
>
> But why the 127? Is it that the underlying type of the enum is a signed
> char? What does sizeof(ColorCode) return?
>
> If this is the case, using
> enum ColorCode : int {
> should help. But I am surprised because the underlying type should be int
> (unless -fshort-enums is used):
> https://stackoverflow.com/questions/1122096/what-is-the-underlying-type-of-a-c-enum
>
> > I didn't understand how JMarc's suggestion to change the type to int would
> > solve the (non) issue.
>
> I was under the impression that the code would check that the enum value was
> one of the declared values. But this is not the case, since a number of
> synthetic values between 100 and 127 seem to be valid.
>
> I also wonder how you triggered it initially. Is it that you really had 25+
> branches, or is it that the code "leaks" color code and creates too many of
> them?
I do have 25+ branches. I need to do some organization and cleaning up :). I
think I misuse the branch system to use for essentially "tagging" parts of my
document. i.e., I never intend to activate most of the branches.
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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
(probably used as 'char') cannot contain the value beyond 127).
Expanding the colors in src/ColorCode.h as in attached, removes the sanitize
messages.
Nice, that makes sense. 500 seems to be a reasonable ceiling. I suppose an
alternative would be to have the code stop assigning new colors past the max.
That is, I imagine they could just assign the max color value to multiple
insets?
But why the 127? Is it that the underlying type of the enum is a signed
char? What does sizeof(ColorCode) return?
If this is the case, using
enum ColorCode : int {
should help. But I am surprised because the underlying type should be
int (unless -fshort-enums is used):
https://stackoverflow.com/questions/1122096/what-is-the-underlying-type-of-a-c-enum
I didn't understand how JMarc's suggestion to change the type to int would
solve the (non) issue.
I was under the impression that the code would check that the enum value
was one of the declared values. But this is not the case, since a number
of synthetic values between 100 and 127 seem to be valid.
I also wonder how you triggered it initially. Is it that you really had
25+ branches, or is it that the code "leaks" color code and creates too
many of them?
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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? Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 flag ? > > > > > > > > > If you do > > > > > > > > > > > > > > > > > > ldd build-dir/bin/lyx | grep ubsan > > > > > > > > > > > > > > > > > > Does it show up? > > > > > > > > > > > > > > > > > > Scott > > > > > > > > > > > > > > > > libubsan.so.1 => /usr/lib/x86_64-linux-gnu/libubsan.so.1 > > > > > > > > (0x7f49cdfd2000) > > > > > > > > > > > > > > Great, I will experiment next week with it. > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > Scott > > > > > > > > > > > > > > > > > > > BTW, how got you the output showing errors? My lyx does not print > > > > > > any error > > > > > > messages. (I mean: > > > > > > 'ColorCode' > > > > > > /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: runtime > > > > > > error: load of value 128, which is not a valid value for type > > > > > > ... > > > > > > ) > > > > > > > > > > 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? > > > > > > > > > > Scott > > > > > > > > Not on empty document. > > > > > > For me it works on an empty document. I do use a default.lyx document > > > (this is what > > > saves when you click on "save class defaults"), but I can reproduce if I > > > remove that > > > template. I attach both MWEs; there's not much difference between them. > > > For me, it is > > > sufficient to just open them and I get the messages in the terminal. > > > > > > Not sure if it's relevant, but perhaps it could be differences with GCC > > > version: > > > > > > g++ --version > > > g++ (Ubuntu 10.3.0-1ubuntu1) 10.3.0 > > > > > > Scott > > > > My fail (Using LYX_DEBUG_SANITIZE too late). I get the messages now too. > > > > BTW, I wonder, if if LYX_ASAN and LYX_DEBUG_SANITIZE are eventually > > exclusive? > > > > Kornel > > 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 > (probably used as 'char') cannot contain the value beyond 127). > > Expanding the colors in src/ColorCode.h as in attached, removes the sanitize > messages. Nice, that makes sense. 500 seems to be a reasonable ceiling. I suppose an alternative would be to have the code stop assigning new colors past the max. That is, I imagine they could just assign the max color value to multiple insets? I didn't understand how JMarc's suggestion to change the type to int would solve the (non) issue. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 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
> > > > > > > > the code. Are you sure it ended up using the
> > > > > > > > -fsanitize=undefined flag ?
> > > > > > > > If you do
> > > > > > > >
> > > > > > > > ldd build-dir/bin/lyx | grep ubsan
> > > > > > > >
> > > > > > > > Does it show up?
> > > > > > > >
> > > > > > > > Scott
> > > > > > >
> > > > > > > libubsan.so.1 => /usr/lib/x86_64-linux-gnu/libubsan.so.1
> > > > > > > (0x7f49cdfd2000)
> > > > > >
> > > > > > Great, I will experiment next week with it.
> > > > > >
> > > > > > Thank you,
> > > > > >
> > > > > > Scott
> > > > > >
> > > > >
> > > > > BTW, how got you the output showing errors? My lyx does not print any
> > > > > error
> > > > > messages. (I mean:
> > > > > 'ColorCode'
> > > > > /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: runtime
> > > > > error: load of value 128, which is not a valid value for type
> > > > > ...
> > > > > )
> > > >
> > > > 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?
> > > >
> > > > Scott
> > >
> > > Not on empty document.
> >
> > For me it works on an empty document. I do use a default.lyx document (this
> > is what
> > saves when you click on "save class defaults"), but I can reproduce if I
> > remove that
> > template. I attach both MWEs; there's not much difference between them. For
> > me, it is
> > sufficient to just open them and I get the messages in the terminal.
> >
> > Not sure if it's relevant, but perhaps it could be differences with GCC
> > version:
> >
> > g++ --version
> > g++ (Ubuntu 10.3.0-1ubuntu1) 10.3.0
> >
> > Scott
>
> My fail (Using LYX_DEBUG_SANITIZE too late). I get the messages now too.
>
> BTW, I wonder, if if LYX_ASAN and LYX_DEBUG_SANITIZE are eventually exclusive?
>
> Kornel
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
(probably used as 'char') cannot contain the value beyond 127).
Expanding the colors in src/ColorCode.h as in attached, removes the sanitize
messages.
Kornel
diff --git a/src/ColorCode.h b/src/ColorCode.h
index c7253ff641..d41316d605 100644
--- a/src/ColorCode.h
+++ b/src/ColorCode.h
@@ -236,11 +236,12 @@ enum ColorCode {
/// Color is inherited
Color_inherit,
/// Color for regexp frame
Color_regexpframe,
/// For ignoring updates of a color
- Color_ignore
+ Color_ignore,
+ Colr_max = 500
};
struct RGBColor {
unsigned int r;
pgpP7A_eQf2uY.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 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 > > > > > > > flag ? If > > > > > > > you do > > > > > > > > > > > > > > ldd build-dir/bin/lyx | grep ubsan > > > > > > > > > > > > > > Does it show up? > > > > > > > > > > > > > > Scott > > > > > > > > > > > > libubsan.so.1 => /usr/lib/x86_64-linux-gnu/libubsan.so.1 > > > > > > (0x7f49cdfd2000) > > > > > > > > > > Great, I will experiment next week with it. > > > > > > > > > > Thank you, > > > > > > > > > > Scott > > > > > > > > > > > > > BTW, how got you the output showing errors? My lyx does not print any > > > > error > > > > messages. (I mean: > > > > 'ColorCode' > > > > /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: runtime > > > > error: load of value 128, which is not a valid value for type > > > > ... > > > > ) > > > > > > 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? > > > > > > Scott > > > > Not on empty document. > > For me it works on an empty document. I do use a default.lyx document (this > is what > saves when you click on "save class defaults"), but I can reproduce if I > remove that > template. I attach both MWEs; there's not much difference between them. For > me, it is > sufficient to just open them and I get the messages in the terminal. > > Not sure if it's relevant, but perhaps it could be differences with GCC > version: > > g++ --version > g++ (Ubuntu 10.3.0-1ubuntu1) 10.3.0 > > Scott My fail (Using LYX_DEBUG_SANITIZE too late). I get the messages now too. BTW, I wonder, if if LYX_ASAN and LYX_DEBUG_SANITIZE are eventually exclusive? Kornel pgp8FuX_GXi_q.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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. Branches have user-set colors, and they are assigned a synthetic color value beyond the ColorCode values. You could fix this by replacing all the ColorCode types to int, but there is no real bug to fix here IMO. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 versions as Jean-Marc pointed out. Thank you for trying, Kornel! Scott Actually it was pretty easy. According to the error message, undefined reference to `typeinfo for lyx::xml::FontTag' looked wrong, since it is defined in xml.h. But src/tex2lyx/dummy_impl.cpp used FontTag _and_ did not include it xml.h. So inserting this include cured the compilation for me. I do not know whether sanitize will prove useful, but the extra include looks good. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 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 flag > > > > > > ? If you do > > > > > > > > > > > > ldd build-dir/bin/lyx | grep ubsan > > > > > > > > > > > > Does it show up? > > > > > > > > > > > > Scott > > > > > > > > > > libubsan.so.1 => /usr/lib/x86_64-linux-gnu/libubsan.so.1 > > > > > (0x7f49cdfd2000) > > > > > > > > Great, I will experiment next week with it. > > > > > > > > Thank you, > > > > > > > > Scott > > > > > > > > > > BTW, how got you the output showing errors? My lyx does not print any > > > error messages. > > > (I mean: > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: > > > runtime > > > error: load of value 128, which is not a valid value for type > > > ... > > > ) > > > > 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? > > > > Scott > > Not on empty document. For me it works on an empty document. I do use a default.lyx document (this is what saves when you click on "save class defaults"), but I can reproduce if I remove that template. I attach both MWEs; there's not much difference between them. For me, it is sufficient to just open them and I get the messages in the terminal. Not sure if it's relevant, but perhaps it could be differences with GCC version: g++ --version g++ (Ubuntu 10.3.0-1ubuntu1) 10.3.0 Scott mwe.lyx Description: application/lyx mwe2.lyx Description: application/lyx signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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. > > > > > > > > > > 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 flag ? > > > > > If you do > > > > > > > > > > ldd build-dir/bin/lyx | grep ubsan > > > > > > > > > > Does it show up? > > > > > > > > > > Scott > > > > > > > > libubsan.so.1 => /usr/lib/x86_64-linux-gnu/libubsan.so.1 > > > > (0x7f49cdfd2000) > > > > > > Great, I will experiment next week with it. > > > > > > Thank you, > > > > > > Scott > > > > > > > BTW, how got you the output showing errors? My lyx does not print any error > > messages. > > (I mean: > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: > > runtime > > error: load of value 128, which is not a valid value for type > > ... > > ) > > 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? > > Scott Not on empty document. Kornel pgpQpsawOzIFC.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 the code. > > > > Are you sure it ended up using the -fsanitize=undefined flag ? If you do > > > > > > > > ldd build-dir/bin/lyx | grep ubsan > > > > > > > > Does it show up? > > > > > > > > Scott > > > > > > libubsan.so.1 => /usr/lib/x86_64-linux-gnu/libubsan.so.1 > > > (0x7f49cdfd2000) > > > > Great, I will experiment next week with it. > > > > Thank you, > > > > Scott > > > > BTW, how got you the output showing errors? My lyx does not print any error > messages. > (I mean: > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: > runtime > error: load of value 128, which is not a valid value for type > ... > ) 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? Scott command-sequence branch-add-insert branch1; branch-add-insert branch2; branch-add-insert branch3; branch-add-insert branch4; branch-add-insert branch5; branch-add-insert branch6; branch-add-insert branch7; branch-add-insert branch8; branch-add-insert branch9; branch-add-insert branch10; branch-add-insert branch11; branch-add-insert branch12; branch-add-insert branch13; branch-add-insert branch14; branch-add-insert branch15; branch-add-insert branch16; branch-add-insert branch17; branch-add-insert branch18; branch-add-insert branch19; branch-add-insert branch20; branch-add-insert branch21; branch-add-insert branch22; branch-add-insert branch23; branch-add-insert branch24; branch-add-insert branch25; branch-add-insert branch26; branch-add-insert branch27; branch-add-insert branch28; branch-add-insert branch29; branch-add-insert branch30; branch-add-insert branch31; branch-add-insert branch32; branch-add-insert branch33; branch-add-insert branch34; branch-add-insert branch35; branch-add-insert branch36; branch-add-insert branch37; branch-add-insert branch38; branch-add-insert branch39; branch-add-insert branch40; branch-add-insert branch41; branch-add-insert branch42; branch-add-insert branch43; branch-add-insert branch44; branch-add-insert branch45; branch-add-insert branch46; branch-add-insert branch47; branch-add-insert branch48; branch-add-insert branch49; branch-add-insert branch50; branch-add-insert branch51; branch-add-insert branch52; branch-add-insert branch53; branch-add-insert branch54; branch-add-insert branch55; branch-add-insert branch56; branch-add-insert branch57; branch-add-insert branch58; branch-add-insert branch59; branch-add-insert branch60; branch-add-insert branch61; branch-add-insert branch62 signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 flag ? If you do > > > > > > ldd build-dir/bin/lyx | grep ubsan > > > > > > Does it show up? > > > > > > Scott > > > > libubsan.so.1 => /usr/lib/x86_64-linux-gnu/libubsan.so.1 > > (0x7f49cdfd2000) > > Great, I will experiment next week with it. > > Thank you, > > Scott > BTW, how got you the output showing errors? My lyx does not print any error messages. (I mean: 'ColorCode' /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: runtime error: load of value 128, which is not a valid value for type ... ) Kornel pgpswA4doGhP4.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 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. > > > > > > > > Thank you for trying, Kornel! > > > > > > > > Scott > > > > > > > > > > Actually it was pretty easy. According to the error message, > > > undefined reference to `typeinfo for lyx::xml::FontTag' > > > looked wrong, since it is defined in xml.h. But > > > src/tex2lyx/dummy_impl.cpp used > > > FontTag _and_ did not include it xml.h. > > > > > > 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 flag ? If you do > > > > ldd build-dir/bin/lyx | grep ubsan > > > > Does it show up? > > > > Scott > > libubsan.so.1 => /usr/lib/x86_64-linux-gnu/libubsan.so.1 > (0x7f49cdfd2000) Great, I will experiment next week with it. Thank you, Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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/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. > > > > > > Thank you for trying, Kornel! > > > > > > Scott > > > > > > > Actually it was pretty easy. According to the error message, > > undefined reference to `typeinfo for lyx::xml::FontTag' > > looked wrong, since it is defined in xml.h. But src/tex2lyx/dummy_impl.cpp > > used > > FontTag _and_ did not include it xml.h. > > > > 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 flag ? If you do > > ldd build-dir/bin/lyx | grep ubsan > > Does it show up? > > Scott libubsan.so.1 => /usr/lib/x86_64-linux-gnu/libubsan.so.1 (0x7f49cdfd2000) So, yes. Kornel pgpxLbjKFKvhI.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 > > > -fsanitize. So the only way is to define dummy versions as Jean-Marc > > > pointed out. > > > > Thank you for trying, Kornel! > > > > Scott > > > > Actually it was pretty easy. According to the error message, > undefined reference to `typeinfo for lyx::xml::FontTag' > looked wrong, since it is defined in xml.h. But src/tex2lyx/dummy_impl.cpp > used > FontTag _and_ did not include it xml.h. > > 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 flag ? If you do ldd build-dir/bin/lyx | grep ubsan Does it show up? Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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.
>
> Thank you for trying, Kornel!
>
> Scott
>
Actually it was pretty easy. According to the error message,
undefined reference to `typeinfo for lyx::xml::FontTag'
looked wrong, since it is defined in xml.h. But src/tex2lyx/dummy_impl.cpp used
FontTag _and_ did not include it xml.h.
So inserting this include cured the compilation for me.
Kornel
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f36784a858..21ba80083c 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -234,10 +234,11 @@ LYX_OPTION(PROFILE "Build with options for gprof" ${DefaultLyxProfi
LYX_OPTION(EXTERNAL_BOOST "Use external boost" ${DefaultExternalLibs} GCC)
LYX_OPTION(PROGRAM_SUFFIX "Append version suffix to binaries" ON GCC)
LYX_OPTION(DEBUG_GLIBC "Enable libstdc++ debug mode" OFF GCC)
LYX_OPTION(DEBUG_GLIBC_PEDANTIC "Enable libstdc++ pedantic debug mode" OFF GCC)
LYX_OPTION(STDLIB_DEBUG "Use debug stdlib" ${DefaultLyxStdlibDebug} GCC)
+LYX_OPTION(DEBUG_SANITIZE "Enable sanitize check" OFF GCC)
# MSVC specific
LYX_OPTION(CONSOLE "Show console on Windows" ON MSVC)
LYX_OPTION(VLD "Use VLD with MSVC" OFF MSVC)
LYX_OPTION(WALL "Enable all warnings" OFF MSVC)
@@ -724,10 +725,15 @@ else()
else()
set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG" CACHE STRING "Set release flags" FORCE)
endif()
endif()
+if (LYX_DEBUG_SANITIZE)
+set(LYX_CXX_FLAGS "${LYX_CXX_FLAGS} -fsanitize=undefined")
+set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=undefined")
+endif()
+
if(LYX_ASAN)
set(CMAKE_CXX_FLAGS "-fsanitize=address -fno-omit-frame-pointer -g ${CMAKE_CXX_FLAGS}")
message(STATUS)
message(STATUS "Address sanitizer enabled. Usage:")
message(STATUS "wget https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/asan/scripts/asan_symbolize.py;)
diff --git a/src/tex2lyx/dummy_impl.cpp b/src/tex2lyx/dummy_impl.cpp
index 961eb9ae0d..9a5fee6355 100644
--- a/src/tex2lyx/dummy_impl.cpp
+++ b/src/tex2lyx/dummy_impl.cpp
@@ -20,10 +20,11 @@
#include "Format.h"
#include "LaTeXFeatures.h"
#include "LyXRC.h"
#include "output_xhtml.h"
+#include "xml.h"
#include "support/Messages.h"
#include
pgpbOzxEQqfmo.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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/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' /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' /home/scott/lyxbuilds/master/repo/src/Color.cpp:366:35: > > > > > runtime error: > > > > > load of value 128, which is not a valid value for type > > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:367:39: > > > > > runtime error: > > > > > load of value 128, which is not a valid value for type > > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:457:17: > > > > > runtime error: > > > > > load of value 128, which is not a valid value for type > > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:10: > > > > > runtime error: > > > > > load of value 128, which is not a valid value for type > > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:31: > > > > > runtime error: > > > > > load of value 128, which is not a valid value for type > > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:55: > > > > > runtime error: > > > > > load of value 128, which is not a valid value for type > > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:536:13: > > > > > runtime error: > > > > > load of value 128, which is not a valid value for type > > > > > 'ColorCode' > > > > > /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: runtime > > > > > error: load of value 128, which is not a valid value for type > > > > > 'ColorCode' > > > > > /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:179:9: runtime > > > > > error: load of value 128, which is not a valid value for type > > > > > 'ColorCode' > > > > > /home/scott/lyxbuilds/master/repo/src/support/Changer.h:41:59: runtime > > > > > error: load of value 128, which is not a valid value for type > > > > > 'ColorCode' > > > > > /home/scott/lyxbuilds/master/repo/src/support/Changer.h:45:56: runtime > > > > > error: load of value 128, which is not a valid value for type > > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:191:9: > > > > > runtime error: > > > > > load of value 128, which is not a valid value for type 'ColorCode' > > > > > > > > > > I don't have time to study how to fix it, but at least I can note it > > > > > here in case > > > > > anyone does. > > > > > > > > This seems more interesting indeed. Looks like the same value > > > > everywhere. I suspect we create synthetic color values in some > > > > circumstances. > > > > > > > > JMarc > > > > > > Seems, like an option for sanitize in cmake would be handy. > > > LYX_OPTION(DEBUG_SANITIZE "Enable sanitize check" OFF GCC) > > > > > > ... > > > if (LYX_DEBUG_SANITIZE) > > > # some magic statements > > > endif() > > > > > > Kornel > > > > That would be nice but might be some work and I don't know if others are > > interested. I > > think it's nice because the run-time hit on performance isn't bad. For > > example, with > > -fsanitize=undefined, I don't even notice it is slower. With ASAN it is > > noticeably > > slower (although still usable as opposed to using LyX with Valgrind). > > > > Scott > > 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. Thank you for trying, Kornel! Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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/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' /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' /home/scott/lyxbuilds/master/repo/src/Color.cpp:366:35: > > > > runtime error: > > > > load of value 128, which is not a valid value for type > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:367:39: > > > > runtime error: > > > > load of value 128, which is not a valid value for type > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:457:17: > > > > runtime error: > > > > load of value 128, which is not a valid value for type > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:10: > > > > runtime error: > > > > load of value 128, which is not a valid value for type > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:31: > > > > runtime error: > > > > load of value 128, which is not a valid value for type > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:55: > > > > runtime error: > > > > load of value 128, which is not a valid value for type > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:536:13: > > > > runtime error: > > > > load of value 128, which is not a valid value for type > > > > 'ColorCode' > > > > /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: runtime > > > > error: load of value 128, which is not a valid value for type > > > > 'ColorCode' > > > > /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:179:9: runtime > > > > error: load of value 128, which is not a valid value for type > > > > 'ColorCode' > > > > /home/scott/lyxbuilds/master/repo/src/support/Changer.h:41:59: runtime > > > > error: load of value 128, which is not a valid value for type > > > > 'ColorCode' > > > > /home/scott/lyxbuilds/master/repo/src/support/Changer.h:45:56: runtime > > > > error: load of value 128, which is not a valid value for type > > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:191:9: > > > > runtime error: > > > > load of value 128, which is not a valid value for type 'ColorCode' > > > > > > > > I don't have time to study how to fix it, but at least I can note it > > > > here in case > > > > anyone does. > > > > > > This seems more interesting indeed. Looks like the same value > > > everywhere. I suspect we create synthetic color values in some > > > circumstances. > > > > > > JMarc > > > > Seems, like an option for sanitize in cmake would be handy. > > LYX_OPTION(DEBUG_SANITIZE "Enable sanitize check" OFF GCC) > > > > ... > > if (LYX_DEBUG_SANITIZE) > > # some magic statements > > endif() > > > > Kornel > > That would be nice but might be some work and I don't know if others are > interested. I > think it's nice because the run-time hit on performance isn't bad. For > example, with > -fsanitize=undefined, I don't even notice it is slower. With ASAN it is > noticeably > slower (although still usable as opposed to using LyX with Valgrind). > > Scott 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. Kornel pgp2fv0o0PUVg.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 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' /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' /home/scott/lyxbuilds/master/repo/src/Color.cpp:366:35: > > > runtime error: > > > load of value 128, which is not a valid value for type > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:367:39: > > > runtime error: > > > load of value 128, which is not a valid value for type > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:457:17: > > > runtime error: > > > load of value 128, which is not a valid value for type > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:10: > > > runtime error: > > > load of value 128, which is not a valid value for type > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:31: > > > runtime error: > > > load of value 128, which is not a valid value for type > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:55: > > > runtime error: > > > load of value 128, which is not a valid value for type > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:536:13: > > > runtime error: > > > load of value 128, which is not a valid value for type > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: > > > runtime > > > error: load of value 128, which is not a valid value for type > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:179:9: > > > runtime > > > error: load of value 128, which is not a valid value for type > > > 'ColorCode' > > > /home/scott/lyxbuilds/master/repo/src/support/Changer.h:41:59: runtime > > > error: load of value 128, which is not a valid value for type > > > 'ColorCode' > > > /home/scott/lyxbuilds/master/repo/src/support/Changer.h:45:56: runtime > > > error: load of value 128, which is not a valid value for type > > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:191:9: > > > runtime error: > > > load of value 128, which is not a valid value for type 'ColorCode' > > > > > > I don't have time to study how to fix it, but at least I can note it here > > > in case > > > anyone does. > > > > This seems more interesting indeed. Looks like the same value > > everywhere. I suspect we create synthetic color values in some > > circumstances. > > > > JMarc > > Seems, like an option for sanitize in cmake would be handy. > LYX_OPTION(DEBUG_SANITIZE "Enable sanitize check" OFF GCC) > > ... > if (LYX_DEBUG_SANITIZE) > # some magic statements > endif() > > Kornel That would be nice but might be some work and I don't know if others are interested. I think it's nice because the run-time hit on performance isn't bad. For example, with -fsanitize=undefined, I don't even notice it is slower. With ASAN it is noticeably slower (although still usable as opposed to using LyX with Valgrind). Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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: > > runtime error: load of value 128, which is not a valid value for type > > 'ColorCode' /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' /home/scott/lyxbuilds/master/repo/src/Color.cpp:366:35: runtime > > error: > > load of value 128, which is not a valid value for type > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:367:39: runtime > > error: > > load of value 128, which is not a valid value for type > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:457:17: runtime > > error: > > load of value 128, which is not a valid value for type > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:10: runtime > > error: > > load of value 128, which is not a valid value for type > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:31: runtime > > error: > > load of value 128, which is not a valid value for type > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:55: runtime > > error: > > load of value 128, which is not a valid value for type > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:536:13: runtime > > error: > > load of value 128, which is not a valid value for type > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: > > runtime > > error: load of value 128, which is not a valid value for type > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:179:9: > > runtime > > error: load of value 128, which is not a valid value for type > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/support/Changer.h:41:59: > > runtime > > error: load of value 128, which is not a valid value for type > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/support/Changer.h:45:56: > > runtime > > error: load of value 128, which is not a valid value for type > > 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:191:9: runtime > > error: > > load of value 128, which is not a valid value for type 'ColorCode' > > > > I don't have time to study how to fix it, but at least I can note it here > > in case > > anyone does. > > This seems more interesting indeed. Looks like the same value > everywhere. I suspect we create synthetic color values in some > circumstances. > > JMarc Seems, like an option for sanitize in cmake would be handy. LYX_OPTION(DEBUG_SANITIZE "Enable sanitize check" OFF GCC) ... if (LYX_DEBUG_SANITIZE) # some magic statements endif() Kornel pgpfpFgR9Osbt.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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' /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' /home/scott/lyxbuilds/master/repo/src/Color.cpp:366:35: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:367:39: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:457:17: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:10: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:31: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:55: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:536:13: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:179:9: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/support/Changer.h:41:59: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/support/Changer.h:45:56: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:191:9: runtime error: load of value 128, which is not a valid value for type 'ColorCode' I don't have time to study how to fix it, but at least I can note it here in case anyone does. This seems more interesting indeed. Looks like the same value everywhere. I suspect we create synthetic color values in some circumstances. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 get the following: > > > > -lz /usr/bin/ld: > > > CMakeFiles/tex2lyx.dir/dummy_impl.cpp.o:(.data.rel+0x118): undefined > > > reference to `typeinfo for lyx::xml::FontTag' collect2: error: ld > > > returned 1 exit status > > > > > > Any tip on how to solve this? > > > > We may need to include src/xml.cpp to the list of files for tex2lyx. > > (line src/tex2lyx/CMakeLists.txt:13) > > It is because we use dummy versions of some structures in order to limit the > external code required in tex2lyx. This means that the virtual functions > declared in the .h files are in general not implemented in the tex2lyx part. > I do not think that adding the file is a good idea, since as you saw it > means re-adding lots of code. Remember that the previous situation was that > we had to compile the same .cpp file into a normal and a tex2lyx version. > This was awful. > > What would a clean solution be? Looking at dummy_impl.cpp, I see > > 1/ Alert(). This could be a signal, that could be bound properly as needed. > > 2/ getMessages/getGuiMessages. Could be a signal too. > > 3/ Formats: this is nonsense. Lexer should rely on gzstream to read zipped > files seamlessly (it will do the right thing when the stream is not zipped, > AFAIU). There is no need to rely on Formats there. This would allow to move > it to support/. This has been on a todo list of mine for some time, but not > deemed uergent. Feel free to try. > > 4/ LaTeXFeatures: not sure. > > 5/ alignmentToCSS. This helper function should probably be moved elsewhere. > > 6/ lyx_exit. Maybe a signal again? > > 7/ StartTag stuff. I do not remember why this is needed. What happens if you > remove it? > > I think this stuff in dummy_functions.cpp should be seen as indication that > our code is not cleanly separated enough. Thank you for breaking down the issue, JMarc. I could see that something tricky was going on but I didn't understand the purpose, or what possible alternatives would be. I followed Kornel's approach of just compiling the main LyX binary with the option. It seemed to work, and I might have gotten something useful: /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' /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' /home/scott/lyxbuilds/master/repo/src/Color.cpp:366:35: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:367:39: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:457:17: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:10: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:31: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:435:55: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:536:13: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:174:6: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/MetricsInfo.cpp:179:9: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/support/Changer.h:41:59: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/support/Changer.h:45:56: runtime error: load of value 128, which is not a valid value for type 'ColorCode' /home/scott/lyxbuilds/master/repo/src/Color.cpp:191:9: runtime error: load of value 128, which is not a valid value for type 'ColorCode' I don't have time to study how to fix it, but at least I can note it here in case anyone does. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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): undefined reference to `typeinfo for lyx::xml::FontTag' collect2: error: ld returned 1 exit status Any tip on how to solve this? We may need to include src/xml.cpp to the list of files for tex2lyx. (line src/tex2lyx/CMakeLists.txt:13) It is because we use dummy versions of some structures in order to limit the external code required in tex2lyx. This means that the virtual functions declared in the .h files are in general not implemented in the tex2lyx part. I do not think that adding the file is a good idea, since as you saw it means re-adding lots of code. Remember that the previous situation was that we had to compile the same .cpp file into a normal and a tex2lyx version. This was awful. What would a clean solution be? Looking at dummy_impl.cpp, I see 1/ Alert(). This could be a signal, that could be bound properly as needed. 2/ getMessages/getGuiMessages. Could be a signal too. 3/ Formats: this is nonsense. Lexer should rely on gzstream to read zipped files seamlessly (it will do the right thing when the stream is not zipped, AFAIU). There is no need to rely on Formats there. This would allow to move it to support/. This has been on a todo list of mine for some time, but not deemed uergent. Feel free to try. 4/ LaTeXFeatures: not sure. 5/ alignmentToCSS. This helper function should probably be moved elsewhere. 6/ lyx_exit. Maybe a signal again? 7/ StartTag stuff. I do not remember why this is needed. What happens if you remove it? I think this stuff in dummy_functions.cpp should be seen as indication that our code is not cleanly separated enough. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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 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/lib/ccache/c++
> > > -Wall -Wextra -Wno-deprecated-copy --std=c++20 -DENABLE_ASSERTIONS=1
> > > -fsanitize=undefined -fno-strict-aliasing -O0 -g3 -D_DEBUG
> > > -fsanitize=undefined
> > > -rdynamic CMakeFiles/tex2lyx.dir/Context.cpp.o
> > > CMakeFiles/tex2lyx.dir/Parser.cpp.o
> > > CMakeFiles/tex2lyx.dir/Preamble.cpp.o CMakeFiles/tex2lyx.dir/boost.cpp.o
> > > CMakeFiles/tex2lyx.dir/dummy_impl.cpp.o CMakeFiles/tex2lyx.dir/math.cpp.o
> > > CMakeFiles/tex2lyx.dir/table.cpp.o CMakeFiles/tex2lyx.dir/tex2lyx.cpp.o
> > > CMakeFiles/tex2lyx.dir/text.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/graphics/GraphicsParams.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/insets/ExternalTemplate.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/insets/ExternalTransforms.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/insets/InsetLayout.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/Author.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/CiteEnginesList.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/Color.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/Counters.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/Encoding.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/FloatList.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/Floating.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/FontInfo.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/LaTeXPackages.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/Layout.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/LayoutFile.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/LayoutModuleList.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/Lexer.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/ModuleList.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/TextClass.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/Spacing.cpp.o
> > > CMakeFiles/tex2lyx.dir/__/version.cpp.o
> > > -o ../../bin/tex2lyx ../../lib/libsupport.a
> > > -lmagic /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2
> > > /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.2
> > > -lz /usr/bin/ld:
> > > CMakeFiles/tex2lyx.dir/dummy_impl.cpp.o:(.data.rel+0x118):
> > > undefined reference to `typeinfo for lyx::xml::FontTag' collect2: error:
> > > ld
> > > returned 1 exit status
> > >
> > > Any tip on how to solve this?
> > >
> > > Scott
> >
> > We may need to include src/xml.cpp to the list of files for tex2lyx.
> > (line src/tex2lyx/CMakeLists.txt:13)
>
> Thanks! Your suggestion worked for this linker error, but then I got new
> linker errors.
> I kept adding to the list, but I keep getting new linker errors. Currently I
> have the
> following:
>
> --- a/src/tex2lyx/CMakeLists.txt
> +++ b/src/tex2lyx/CMakeLists.txt
> @@ -14,7 +14,7 @@ foreach(_src graphics/GraphicsParams insets/ExternalTemplate
> insets/ExternalTransforms insets/InsetLayout Author CiteEnginesList
> Color
> Counters Encoding FloatList Floating FontInfo LaTeXPackages Layout
> LayoutFile LayoutModuleList Lexer ModuleList TextClass
> - Spacing version)
> + Spacing version xml Layout Paragraph BufferParams)
> list(APPEND LINKED_sources ${TOP_SRC_DIR}/src/${_src}.cpp)
> list(APPEND LINKED_headers ${TOP_SRC_DIR}/src/${_src}.h)
> endforeach(_src)
>
> But I still get linker errors. I can keep proceeding to add them individually
> if that
> is what we need to do. But I wanted to check to make sure that's what we
> should do.
>
> I should add that being able to compile with -fsanitize=undefined is not so
> important.
> If this seems like a tricky issue, I am fine to give up for now :)
>
> Scott
We could omit the flag for tex2lyx compilation. I suppose, we need this flag
only for the
lyx-executable.
So adding the flags in src/CMakeLists.txt as
add_compile_options("-fsanitize=undefined")
...
target_link_options(${_lyx} "-fsanitize=undefined")
Hope this is correct.
Kornel
pgpkvk1CBJEos.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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/tex2lyx
> > cd /home/scott/lyxbuilds/master/CMakeBuild/src/tex2lyx && /usr/bin/cmake -E
> > cmake_link_script CMakeFiles/tex2lyx.dir/link.txt --verbose=1
> > /usr/lib/ccache/c++ -Wall
> > -Wextra -Wno-deprecated-copy --std=c++20 -DENABLE_ASSERTIONS=1
> > -fsanitize=undefined
> > -fno-strict-aliasing -O0 -g3 -D_DEBUG -fsanitize=undefined -rdynamic
> > CMakeFiles/tex2lyx.dir/Context.cpp.o CMakeFiles/tex2lyx.dir/Parser.cpp.o
> > CMakeFiles/tex2lyx.dir/Preamble.cpp.o CMakeFiles/tex2lyx.dir/boost.cpp.o
> > CMakeFiles/tex2lyx.dir/dummy_impl.cpp.o CMakeFiles/tex2lyx.dir/math.cpp.o
> > CMakeFiles/tex2lyx.dir/table.cpp.o CMakeFiles/tex2lyx.dir/tex2lyx.cpp.o
> > CMakeFiles/tex2lyx.dir/text.cpp.o
> > CMakeFiles/tex2lyx.dir/__/graphics/GraphicsParams.cpp.o
> > CMakeFiles/tex2lyx.dir/__/insets/ExternalTemplate.cpp.o
> > CMakeFiles/tex2lyx.dir/__/insets/ExternalTransforms.cpp.o
> > CMakeFiles/tex2lyx.dir/__/insets/InsetLayout.cpp.o
> > CMakeFiles/tex2lyx.dir/__/Author.cpp.o
> > CMakeFiles/tex2lyx.dir/__/CiteEnginesList.cpp.o
> > CMakeFiles/tex2lyx.dir/__/Color.cpp.o
> > CMakeFiles/tex2lyx.dir/__/Counters.cpp.o
> > CMakeFiles/tex2lyx.dir/__/Encoding.cpp.o
> > CMakeFiles/tex2lyx.dir/__/FloatList.cpp.o
> > CMakeFiles/tex2lyx.dir/__/Floating.cpp.o
> > CMakeFiles/tex2lyx.dir/__/FontInfo.cpp.o
> > CMakeFiles/tex2lyx.dir/__/LaTeXPackages.cpp.o
> > CMakeFiles/tex2lyx.dir/__/Layout.cpp.o
> > CMakeFiles/tex2lyx.dir/__/LayoutFile.cpp.o
> > CMakeFiles/tex2lyx.dir/__/LayoutModuleList.cpp.o
> > CMakeFiles/tex2lyx.dir/__/Lexer.cpp.o
> > CMakeFiles/tex2lyx.dir/__/ModuleList.cpp.o
> > CMakeFiles/tex2lyx.dir/__/TextClass.cpp.o
> > CMakeFiles/tex2lyx.dir/__/Spacing.cpp.o
> > CMakeFiles/tex2lyx.dir/__/version.cpp.o
> > -o ../../bin/tex2lyx ../../lib/libsupport.a
> > -lmagic /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2
> > /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.2
> > -lz /usr/bin/ld: CMakeFiles/tex2lyx.dir/dummy_impl.cpp.o:(.data.rel+0x118):
> > undefined
> > reference to `typeinfo for lyx::xml::FontTag' collect2: error: ld returned
> > 1 exit status
> >
> > Any tip on how to solve this?
> >
> > Scott
>
> We may need to include src/xml.cpp to the list of files for tex2lyx.
> (line src/tex2lyx/CMakeLists.txt:13)
Thanks! Your suggestion worked for this linker error, but then I got new linker
errors. I kept adding to the list, but I keep getting new linker errors.
Currently I have the following:
--- a/src/tex2lyx/CMakeLists.txt
+++ b/src/tex2lyx/CMakeLists.txt
@@ -14,7 +14,7 @@ foreach(_src graphics/GraphicsParams insets/ExternalTemplate
insets/ExternalTransforms insets/InsetLayout Author CiteEnginesList
Color Counters
Encoding FloatList Floating FontInfo LaTeXPackages Layout
LayoutFile LayoutModuleList Lexer ModuleList TextClass
- Spacing version)
+ Spacing version xml Layout Paragraph BufferParams)
list(APPEND LINKED_sources ${TOP_SRC_DIR}/src/${_src}.cpp)
list(APPEND LINKED_headers ${TOP_SRC_DIR}/src/${_src}.h)
endforeach(_src)
But I still get linker errors. I can keep proceeding to add them individually
if that is what we need to do. But I wanted to check to make sure that's what
we should do.
I should add that being able to compile with -fsanitize=undefined is not so
important. If this seems like a tricky issue, I am fine to give up for now :)
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Link error when compiling with -fsanitize=undefined
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/cmake -E > cmake_link_script CMakeFiles/tex2lyx.dir/link.txt --verbose=1 > /usr/lib/ccache/c++ -Wall > -Wextra -Wno-deprecated-copy --std=c++20 -DENABLE_ASSERTIONS=1 > -fsanitize=undefined > -fno-strict-aliasing -O0 -g3 -D_DEBUG -fsanitize=undefined -rdynamic > CMakeFiles/tex2lyx.dir/Context.cpp.o CMakeFiles/tex2lyx.dir/Parser.cpp.o > CMakeFiles/tex2lyx.dir/Preamble.cpp.o CMakeFiles/tex2lyx.dir/boost.cpp.o > CMakeFiles/tex2lyx.dir/dummy_impl.cpp.o CMakeFiles/tex2lyx.dir/math.cpp.o > CMakeFiles/tex2lyx.dir/table.cpp.o CMakeFiles/tex2lyx.dir/tex2lyx.cpp.o > CMakeFiles/tex2lyx.dir/text.cpp.o > CMakeFiles/tex2lyx.dir/__/graphics/GraphicsParams.cpp.o > CMakeFiles/tex2lyx.dir/__/insets/ExternalTemplate.cpp.o > CMakeFiles/tex2lyx.dir/__/insets/ExternalTransforms.cpp.o > CMakeFiles/tex2lyx.dir/__/insets/InsetLayout.cpp.o > CMakeFiles/tex2lyx.dir/__/Author.cpp.o > CMakeFiles/tex2lyx.dir/__/CiteEnginesList.cpp.o > CMakeFiles/tex2lyx.dir/__/Color.cpp.o CMakeFiles/tex2lyx.dir/__/Counters.cpp.o > CMakeFiles/tex2lyx.dir/__/Encoding.cpp.o > CMakeFiles/tex2lyx.dir/__/FloatList.cpp.o > CMakeFiles/tex2lyx.dir/__/Floating.cpp.o > CMakeFiles/tex2lyx.dir/__/FontInfo.cpp.o > CMakeFiles/tex2lyx.dir/__/LaTeXPackages.cpp.o > CMakeFiles/tex2lyx.dir/__/Layout.cpp.o > CMakeFiles/tex2lyx.dir/__/LayoutFile.cpp.o > CMakeFiles/tex2lyx.dir/__/LayoutModuleList.cpp.o > CMakeFiles/tex2lyx.dir/__/Lexer.cpp.o > CMakeFiles/tex2lyx.dir/__/ModuleList.cpp.o > CMakeFiles/tex2lyx.dir/__/TextClass.cpp.o > CMakeFiles/tex2lyx.dir/__/Spacing.cpp.o > CMakeFiles/tex2lyx.dir/__/version.cpp.o > -o ../../bin/tex2lyx ../../lib/libsupport.a > -lmagic /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.15.2 > /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.2 > -lz /usr/bin/ld: CMakeFiles/tex2lyx.dir/dummy_impl.cpp.o:(.data.rel+0x118): > undefined > reference to `typeinfo for lyx::xml::FontTag' collect2: error: ld returned 1 > exit status > > Any tip on how to solve this? > > Scott We may need to include src/xml.cpp to the list of files for tex2lyx. (line src/tex2lyx/CMakeLists.txt:13) Kornel pgpvfWh3CFoMw.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
