[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Fix LEXLIB and YYTEXT_POINTER on non-ANSI systems.
From: |
Peter Rosin |
Subject: |
Re: [PATCH] Fix LEXLIB and YYTEXT_POINTER on non-ANSI systems. |
Date: |
Wed, 04 Jan 2012 10:06:44 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 |
Paul Eggert skrev 2012-01-04 09:33:
> On 01/04/12 00:01, Peter Rosin wrote:
>> Below is a patch that makes the lex library detection and
>> the yytext-pointer tests not stumble when the system does
>> not provide a unistd.h include.
>
> Are the tests really stumbling in that case?
Yes. I don't have logs available anymore, but adding the same
lines to configure made this problem go away and configure was
able to link with -lfl. The problem was very obvious when I
looked at the logs, configure tried to link without any extra
lib, with -lfl and with -ll, all of which failed to even compile
due to unistd.h not being present. With the change, configure
successfully compiled but failed to link, until I managed to
satisfy -lfl and then everything when smooth.
> If 'lex' generates .c files that don't work
> unless one #defines a magic symbol, then arguably
> 'lex' isn't working.
Yes, 'lex' (flex in this case) really generates code that
requires unistd.h in the default case.
> Perhaps a better fix would be for 'configure'
> to #define YY_NO_UNISTD_H as needed, and
> to leave contest.l alone? That way, the fix
> would be visible to C programs that are being
> compiled.
I don't think so, since blindly defining YY_NO_UNISTD_H might
kill the C program as it might assume that unistd.h has been
included. It is not really helpful to regress these unistd.h-
depending projects when trying to help fringe configurations
such as MSVC, at least not when it can be avoided so easily.
Or did you mean that configure should only #define YY_NO_UNISTD_H
when there is no unistd.h (ac_cv_header_unistd_h=no)?
Cheers,
Peter