При сборке reentrant парсера получаю: loadkeys.analyze.c: In function ‘yy_fatal_error’: loadkeys.analyze.c:2532:58: warning: unused parameter ‘yyscanner’ [-Wunused-parameter] loadkeys.analyze.c: At top level: loadkeys.analyze.c:2582:5: warning: no previous prototype for ‘yyget_column’ [-Wmissing-prototypes] loadkeys.analyze.c:2658:6: warning: no previous prototype for ‘yyset_column’ [-Wmissing-prototypes] loadkeys.analyze.c: In function ‘yyalloc’: loadkeys.analyze.c:2864:43: warning: unused parameter ‘yyscanner’ [-Wunused-parameter] loadkeys.analyze.c: In function ‘yyrealloc’: loadkeys.analyze.c:2869:58: warning: unused parameter ‘yyscanner’ [-Wunused-parameter] loadkeys.analyze.c: In function ‘yyfree’: loadkeys.analyze.c:2881:36: warning: unused parameter ‘yyscanner’ [-Wunused-parameter] Проблемы известны давно: http://sourceforge.net/mailarchive/message.php?msg_id=23176513 http://sourceforge.net/mailarchive/message.php?msg_id=25967956 так что есть надежда на их исправление в апстриме.
Какой коммит из какого репозитория какой командой приводит к таким жалобам?
Я получаю это на репозитории: http://git.altlinux.org/people/legion/packages/kbd.git?p=kbd.git;a=shortlog;h=refs/heads/loadkeys при сборке утилиты loadkeys. Сборка осуществляется autotools.
После обновления бизона до bison-2.6.2-alt1 бранч loadkeys не собирается с диагностикой: loadkeys.h:157:14: error: unknown type name 'yyscan_t' Пробовал как действующий flex-2.5.35-alt5, так и будущий flex-2.5.36-alt1. В код kbd не смотрел.
(В ответ на комментарий №3) > После обновления бизона до bison-2.6.2-alt1 бранч loadkeys не собирается с > диагностикой: > loadkeys.h:157:14: error: unknown type name 'yyscan_t' Поставил bison-2.6.2-alt1, в kbd бранч loadkeys собрался. В системе flex-2.5.35-alt5.
(В ответ на комментарий №4) > Поставил bison-2.6.2-alt1, в kbd бранч loadkeys собрался. В системе > flex-2.5.35-alt5. Я ошибся. loadkeys.c был от предыдущей версии. Да, не собирается.
На первый взгляд ситуация смешная. В loadkeys.y есть include сгенерированных хэдеров: #include "loadkeys.h" #include "loadkeys.analyze.h" В loadkeys.h судя по git-diff появилось: +#ifdef YYPARSE_PARAM +#if defined __STDC__ || defined __cplusplus +int yyparse (void *YYPARSE_PARAM); +#else +int yyparse (); +#endif +#else /* ! YYPARSE_PARAM */ +#if defined __STDC__ || defined __cplusplus +int yyparse (yyscan_t scanner, struct keymap *kmap); +#else +int yyparse (); +#endif +#endif /* ! YYPARSE_PARAM */ Тип yyscan_t объявлен в loadkeys.analyze.h. Если в loadkeys.y поменять порядок хэдеров на: #include "loadkeys.analyze.h" #include "loadkeys.h" То получаем ошибку: loadkeys.analyze.h:271:1: error: unknown type name ‘YYSTYPE’ потому что YYSTYPE объявлен в loadkeys.h.
У старого bison-2.4.3: $ fgrep -x -B1 -A3 'int yyparse (yyscan_t scanner, struct keymap *kmap);' loadkeys.{c,h} loadkeys.c-#if defined __STDC__ || defined __cplusplus loadkeys.c:int yyparse (yyscan_t scanner, struct keymap *kmap); loadkeys.c-#else loadkeys.c-int yyparse (); loadkeys.c-#endif У bison-2.6.2-alt1 получается вот что: $ fgrep -x -B1 -A3 'int yyparse (yyscan_t scanner, struct keymap *kmap);' loadkeys.{c,h} loadkeys.c-#if defined __STDC__ || defined __cplusplus loadkeys.c:int yyparse (yyscan_t scanner, struct keymap *kmap); loadkeys.c-#else loadkeys.c-int yyparse (); loadkeys.c-#endif -- loadkeys.h-#if defined __STDC__ || defined __cplusplus loadkeys.h:int yyparse (yyscan_t scanner, struct keymap *kmap); loadkeys.h-#else loadkeys.h-int yyparse (); loadkeys.h-#endif это и приводит к ошибке.
Данную проблему нагуглить не смог. Не могу понять, как разорвать взаимную зависимость. Такая ситуация точно не бага в bison ?
(In reply to comment #8) > Данную проблему нагуглить не смог. Не могу понять, как разорвать взаимную > зависимость. Такая ситуация точно не бага в bison ? bison не подозревает об этой взаимной зависимости: когда он формирует прототип функции yyparse на основе %parse-param, ему все равно, как определены используемые в %parse-param конструкции. Из этих соображений получается, что bison не виноват. С другой стороны, раньше это работало.
(В ответ на комментарий №9) > bison не подозревает об этой взаимной зависимости: когда он формирует прототип > функции yyparse на основе %parse-param, ему все равно, как определены > используемые в %parse-param конструкции. Дело не только в этом. Тут связка %parse-param и %union... а если быть совсем точным, то и %define api.pure. %union создаёт в хэдере YYSTYPE, которая используется в flex при указании %bison-bridge. > Из этих соображений получается, что > bison не виноват. С другой стороны, раньше это работало. Раньше он не выносил объявление yyparse в хэдер. Сейчас получается, что нельзя передавать через %parse-param ничего flex'ового. Как исправление можно только сделать структуру объединяющую все передаваемые yyparse параметры.
(В ответ на комментарий №10) > Как исправление можно только сделать структуру объединяющую все передаваемые > yyparse параметры. Хе. Так сделать нельзя. Любое использование yyscan_t (хэдер flex) влечёт необходимость определения YYSTYPE (хэдер bison).
Ок. Проблема с непересобираемостью с bison-2.6.2 устранена в том же бранче.
flex-2.5.37-alt1 -> sisyphus: * Wed Sep 05 2012 Dmitry V. Levin <ldv@altlinux> 2.5.37-alt1 - Updated to flex-2.5.37-17-gbac5b2b. - flex.skl: fixed warnings generated by gcc -Wunused-parameter (closes: #27661).
