Ошибка связи во время выполнения: не удалось найти точку входа в процедуру glewInit @ 0

0

Я только начинаю использовать GLEW в Windows с MinGW. Я могу скомпилировать программу успешно (glew.h и libglew.a находятся в правильном месте в MinGW), однако выполнение моей программы вызывает libglew.a выше ошибку. glew32.dll присутствует в том же каталоге, что и исполняемый файл, и я нашел и попытался решить различные проблемы. Однако моя проблема, похоже, отличается от других - сообщение об ошибке жалуется, что glewInit не может быть найден в самом исполняемом файле, а не в glew32.dll. Я не нашел ничего об этом в Google.

Здесь ошибка:

Изображение 174551

Как вы можете видеть, он не жалуется, что не смог найти метод glew в DLL, но сам файл программы. Я чувствую, что неправильно связываю исполняемый файл, но у меня очень мало опыта в устранении такого рода ошибок.

Вот мой Makefile:

EXEC      = test1.exe
SRC_FILES = test1.cpp wavefront.cpp

CXX = g++
CC = $(CXX)

DEBUG_LEVEL     = -g
EXTRA_CCFLAGS   = -Wall
CXXFLAGS        = $(DEBUG_LEVEL) $(EXTRA_CCFLAGS)
CCFLAGS         = $(CXXFLAGS)

CPPFLAGS        = -I.

LDFLAGS         = -L"/cygdrive/c/MinGW/lib"
LDLIBS          = -lsfml-graphics -lsfml-window -lsfml-system -lopengl32 -lglu32 -lglew32

O_FILES         = $(SRC_FILES:.cpp=.o)

all: .FORCE

.FORCE: compile link

compile:
    $(CXX) -c $(SRC_FILES)

link: 
    $(CXX) $(O_FILES) -o $(EXEC) $(LDFLAGS) $(LDLIBS)

clean:
    $(RM) $(O_FILES) *.exe *.rpo
  • 0
    Вы сами собирали glew32 с помощью mingw или это из готового бинарного файла?
  • 0
    Это из готового двоичного файла. Я попытался собрать GLEW самостоятельно, однако я не могу установить необходимые ему зависимости разработчика X11. Я думаю, что мне удалось заставить его работать, скомпилировав с glew32s.lib (статическая glew32s.lib ), однако
Показать ещё 1 комментарий
Теги:
linker
opengl
mingw
glew

1 ответ

2
Лучший ответ

Ошибка в заголовке и на диаграмме совершенно другая. Первая ошибка, в вашем заголовке - имя экспортированного DLL-экспорта, а второе - функция __stdcall. По какой-то причине блокировка импорта, похоже, пытается разрешить адрес функции из вашего приложения, а не DLL.

Возможно, вы неправильно определили поведение dllexport при dllimport своей DLL или dllimport при связывании с ним? GLEW использует для этого предварительное определение процессора: GLEW_BUILD.

В любом случае использование статической связующей библиотеки glew определенно решит эту проблему, хотя я не могу сказать, почему это происходит точно.

Ссылка на glew32s и добавьте -DGLEW_STATIC в свой файл Makefile.

  • 0
    Извините за путаницу, они оба должны были прочитать то, что правильно показывает заголовок
  • 0
    @ Bojangles: Ах, вот интересная вещь, хотя ... glewInit (...) обычно является функцией __stdcall , что означает, что декорированное имя должно быть _glewInit@0 . Я думаю, что где-то в общих чертах изменилось соглашение о вызовах, когда DLL была скомпилирована, и соглашение о вызовах, когда вы собрали свою программу. Вы можете попробовать переопределить GLEWAPI как extern __declspec(dllimport) __stdcall . Но я думаю, что, возможно, вы забыли подчеркивание в заголовке вашего вопроса.
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню