Ошибка при запуске программы lex в командной строке Windows 10 предыдущих ответов не помогла мне [дублировать]

Для ошибки: cannot find -lflx

В вашем изменении Makefile: LEXLIB = -lfl - LEXLIB =.

В противном случае удалите аргумент -lfl, где бы он ни находился.

Я столкнулся с той же проблемой, и поэтому я проверил ее в Интернете и нашел решение путем workcaptchabypass опубликовано 3 июня 2011 г. 6:44 здесь

он сказал:

Вы можете добавить эту функцию вместо этого и скомпилировать нормально

yywrap()
{
}

И поэтому я поставил код в файле .lex перед основной функцией. После этого все получилось так:

Если вы используете lex + yacc, вы можете удалить -lfl, если вы определяете функцию yywrap или, что еще лучше, если вы используете опцию noyywrap:

%option noyywrap
%%
 ...
%%

Чтобы скомпилировать lex-код, во-первых, вы должны установить flex на свой компьютер. Если да, то будет файл libfl.a. В моей машине я установил flex в 'C: \ GnuWin32 \ lib'

gcc lex.yy.c -L "C: \ GnuWin32 \ lib" -lfl

Я столкнулся с этой проблемой при переносе TXR в Windows с помощью MinGW.

MinGW имеет гибкую библиотеку для себя, но не экспортирует ее в среду.

См. здесь : http://lists.nongnu.org/archive/html/txr-users/2011-10/msg00001.html

Обходным путем является использование -L/usr/lib до -lfl. Но подумайте об этом: это взломать. Зачем? Поскольку путь /usr/lib/ принадлежит MinGW, время выполнения среды компиляции.

/usr/lib не там, где предполагается, что инструментальная цепочка должна найти библиотеки для создаваемой программы Windows (чего нет в путь к библиотеке!) [/ ​​g5]

То есть мы эффективно краем родную библиотеку машины сборки в задании кросс-компиляции.

Это похоже на то, что вы выполняли кросс-компиляцию, скажем, программу Fedora на Ubuntu и помогать себе в статической библиотеке Ubuntu в /usr/lib, которая отсутствует в перекрестной привязке Fedora (используя тот факт, что формат архитектуры и объектного файла бывает одинаковым).

Это определенно ошибка в том, как Flex «упакован» в MingW.