On 30.09.2010 11:08, Stefan Fritsch wrote:
On Thursday 30 September 2010, Rainer Jung wrote:
On 30.09.2010 10:24, Stefan Fritsch wrote:
On Thursday 30 September 2010, William A. Rowe Jr. wrote:
On 9/29/2010 6:49 PM, Guenter Knauf wrote:
Am 30.09.2010 01:17, schrieb Guenter Knauf:
a touch would probably do ... - if not I will face same for
NetWare ...
just checked, and beside some new prototype warnings:
Compiling ssl_expr_scan.c
### mwccnlm Compiler:
# File: ssl_expr_scan.c
# ------------------------
# 2066: {
# Warning: ^
# function has no prototype
### mwccnlm Compiler:
# 2142: {
# Warning: ^
# function has no prototype
No, those are the ones I mentioned in the commit log. They appear
with gcc, too:
ssl_expr_scan.c:2065: warning: no previous prototype for
'ssl_expr_yyget_column'
ssl_expr_scan.c:2141: warning: no previous prototype for
'ssl_expr_yyset_column'
If someone has a the latest Fedora and can regenerate the file,
that would probably fix it. Otherwise it will have to wait until
the fixed flex is in Debian, I am too lazy to install a new flex
from source for just too warnings.
Do you have a pointer to the flex source code you want to be used?
I build the toolchain for myself on Solaris, so I can easily
update from 2.5.35 to some custom version to do this test.
That would be nice. There is no official release, yet, but this bug
report has a patch:
http://sourceforge.net/tracker/?func=detail&aid=3029024&group_id=97492&atid=618177
(I have read somewhere that Fedora has included the patch)
I also get the warning (only when using "-Wmissing-prototypes", the flag
"-Wall" didn't produce the warning) for the original file.
I rebuilt flex with the above patch (original flex 2.5.35, no other
patch) and regenerated the file. No more warning and two additional
prototypes are there:
+int ssl_expr_yyget_column (yyscan_t yyscanner );
+
+void ssl_expr_yyset_column (int column_no ,yyscan_t yyscanner );
+
The full diff is available at:
http://people.apache.org/~rjung/patches/patched-flex-ssl_expr_scan_c.patch
Unfortunately it looks like my flex plus one patch also changes other
stuff, which looks more correct in your version, likely because your
flex already contains other pathces (the original version 2.5.35 is
already about 2 years old, but there is no more recent official release).
So I'm not sure, what we should check in. I'd say leave as if, as
results will vary depending on the system the RM uses and the missing
prototype warnings are not too bad.
I also rebuild ssl_expr_parse.(c|h) with bison 2.4.2 I had at hand.
Latest would be 2.4.3. The header file does not contain any relevant
difference. The source files does have some differences in the macro use.
Full diff here:
http://people.apache.org/~rjung/patches/bison-2_4_2-ssl_expr_parse.patch
Finally: I tweaked the Makefile a bit to allowe out of tree use of the
flex and bison targets (r1003061). There is still an open point for me:
at the moment when doing an out of tree build and when the timestamps
are not right, the targets generate the new source and header files in
the build directory, not the source directory. At least when I tested
it, those win, so the compiled code uses the right ones without
overriding the original ones. Is that like we want it, or do we actually
want to regenerate in the source directory?
Regards,
Rainer
