Re: MacOS 64-bit build

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: MacOS 64-bit build

Erlend Aasland-2
> On 13 Feb 2019, at 20:16, Daniel Johnson <address@hidden> wrote:
>
> I am using guile 1.8.8, gcc 7.4.0, and flex 2.6.4.  Here's my configure line:
>
> On build, I get a long string of errors originating in out/lexer.cc<http://lexer.cc>:
>
> out/lexer.cc:6272<http://lexer.cc:6272>:46: error: cannot convert 'std::istream {aka
> std::basic_istream<char>}' to 'std::istream* {aka std::basic_istream<char>*}'
> in assignment
>     YY_CURRENT_BUFFER_LVALUE->yy_input_file = yyin;

Use flex 2.5.37, as the flex 2.6.* C++ lexer is broken (discussed on the Bison
lists): a stream pointer has been changed in the declaration to a reference
without doing it in the code. Reported some years ago on the flex list.

`configure` should warn or bail on incompatible flex versions. I suggest we add a version check in configure.ac to ensure that flex version is between 2.5.37 and 2.5.39 (given that 2.5.38 and 2.5.39 actually works).



Erlend E. Aasland
Reply | Threaded
Open this post in threaded view
|

Re: MacOS 64-bit build

Erlend Aasland-2
(Sorry, 'bout incorrect quote level in previous email!)

E

> On 9 Jan 2020, at 13:00, Erlend Aasland <[hidden email]> wrote:
>
>> On 13 Feb 2019, at 20:16, Daniel Johnson <address@hidden> wrote:
>>
>> I am using guile 1.8.8, gcc 7.4.0, and flex 2.6.4.  Here's my configure line:
>>
>> On build, I get a long string of errors originating in out/lexer.cc<http://lexer.cc>:
>>
>> out/lexer.cc:6272<http://lexer.cc:6272>:46: error: cannot convert 'std::istream {aka
>> std::basic_istream<char>}' to 'std::istream* {aka std::basic_istream<char>*}'
>> in assignment
>>    YY_CURRENT_BUFFER_LVALUE->yy_input_file = yyin;
>
> Use flex 2.5.37, as the flex 2.6.* C++ lexer is broken (discussed on the Bison
> lists): a stream pointer has been changed in the declaration to a reference
> without doing it in the code. Reported some years ago on the flex list.
>
> `configure` should warn or bail on incompatible flex versions. I suggest we add a version check in configure.ac to ensure that flex version is between 2.5.37 and 2.5.39 (given that 2.5.38 and 2.5.39 actually works).
>
>
>
> Erlend E. Aasland


Reply | Threaded
Open this post in threaded view
|

Re: MacOS 64-bit build

Werner LEMBERG
In reply to this post by Erlend Aasland-2

> `configure` should warn or bail on incompatible flex versions.  I
> suggest we add a version check in configure.ac to ensure that flex
> version is between 2.5.37 and 2.5.39 (given that 2.5.38 and 2.5.39
> actually works).

What you suggest wouldn't work as expected.  There is no guarantee
that `FlexLexer.h` found during compilation is the one that is used by
a recent flex version.  Unfortunately, `FlexLexer.h` doesn't contain
any version information, so it is really impossible to protect against
this situation automatically.

I was bitten by that on my Mac OS Lion box, and as a consequence I
implemented the `--with-flexlexer-dir` configuration option.


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: MacOS 64-bit build

Erlend Aasland-2
Argh, yes, you are of course right. Thanks.


Erlend

> On 9 Jan 2020, at 13:34, Werner LEMBERG <[hidden email]> wrote:
>
>
>> `configure` should warn or bail on incompatible flex versions.  I
>> suggest we add a version check in configure.ac to ensure that flex
>> version is between 2.5.37 and 2.5.39 (given that 2.5.38 and 2.5.39
>> actually works).
>
> What you suggest wouldn't work as expected.  There is no guarantee
> that `FlexLexer.h` found during compilation is the one that is used by
> a recent flex version.  Unfortunately, `FlexLexer.h` doesn't contain
> any version information, so it is really impossible to protect against
> this situation automatically.
>
> I was bitten by that on my Mac OS Lion box, and as a consequence I
> implemented the `--with-flexlexer-dir` configuration option.
>
>
>    Werner


Reply | Threaded
Open this post in threaded view
|

Re: MacOS 64-bit build

Hans Åberg-2
In reply to this post by Werner LEMBERG

> On 9 Jan 2020, at 13:34, Werner LEMBERG <[hidden email]> wrote:
>
>> `configure` should warn or bail on incompatible flex versions.  I
>> suggest we add a version check in configure.ac to ensure that flex
>> version is between 2.5.37 and 2.5.39 (given that 2.5.38 and 2.5.39
>> actually works).
>
> What you suggest wouldn't work as expected.  There is no guarantee
> that `FlexLexer.h` found during compilation is the one that is used by
> a recent flex version.  Unfortunately, `FlexLexer.h` doesn't contain
> any version information, so it is really impossible to protect against
> this situation automatically.

Akim Demaille made a patch for it, see:
https://lists.gnu.org/archive/html/bug-bison/2018-09/msg00020.html



Reply | Threaded
Open this post in threaded view
|

Re: MacOS 64-bit build

Werner LEMBERG

>> There is no guarantee that `FlexLexer.h` found during compilation
>> is the one that is used by a recent flex version.  Unfortunately,
>> `FlexLexer.h` doesn't contain any version information, so it is
>> really impossible to protect against this situation automatically.
>
> Akim Demaille made a patch for it, see:
> https://lists.gnu.org/archive/html/bug-bison/2018-09/msg00020.html

Nope, he didn't.  This patch is for something completely different, as
far as I can see – LilyPond doesn't use `FlexLexer.hh`, it rather uses
`FlexLexer.h` that comes with flex.

If you look into the git repository of flex you can see that even the
most recent version of `FlexLexer.h` doesn't have any version
information.


    Werner
Reply | Threaded
Open this post in threaded view
|

Re: MacOS 64-bit build

Dan Eble
In reply to this post by Erlend Aasland-2
On Jan 9, 2020, at 07:00, Erlend Aasland <[hidden email]> wrote:
>
> Use flex 2.5.37, as the flex 2.6.* C++ lexer is broken (discussed on the Bison
> lists): a stream pointer has been changed in the declaration to a reference
> without doing it in the code. Reported some years ago on the flex list.

I've been building master with flex 2.6.4 and I have not had any problem.

Dan


Reply | Threaded
Open this post in threaded view
|

Re: MacOS 64-bit build

Hans Åberg-2
In reply to this post by Werner LEMBERG

> On 9 Jan 2020, at 18:00, Werner LEMBERG <[hidden email]> wrote:
>
>>> There is no guarantee that `FlexLexer.h` found during compilation
>>> is the one that is used by a recent flex version.  Unfortunately,
>>> `FlexLexer.h` doesn't contain any version information, so it is
>>> really impossible to protect against this situation automatically.
>>
>> Akim Demaille made a patch for it, see:
>> https://lists.gnu.org/archive/html/bug-bison/2018-09/msg00020.html
>
> Nope, he didn't.  This patch is for something completely different, as
> far as I can see – LilyPond doesn't use `FlexLexer.hh`, it rather uses
> `FlexLexer.h` that comes with flex.

I did not look so careful at it, but I get the impression he makes his own header that depends on the Flex version.

> If you look into the git repository of flex you can see that even the
> most recent version of `FlexLexer.h` doesn't have any version
> information.

You can’t get around that, so one way around it is to make ones own header and include that. Then the .cc uses system includes, so either that should be patched too, or an option passed to the compiler.