Link error lnk2001 неразрешенный внешний символ winmain

The following code compiles on VS Express Edition 2008, yet I get the following errors when trying to debug/release:

1>Linking...
1>MSVCRT.lib(crtexew.obj) : error LNK2001: unresolved external symbol _WinMain@16
1>E:Documents and SettingsAdministratorDesktopProyecto 2 gràficastestingReleasetesting.exe : fatal error LNK1120: 1 unresolved externals

is it because it’s unable to link a library? How can I solve this?

#include <windows.h>   // use as needed for your system

#include <gl/Gl.h>
#include <gl/glut.h>
#include <iostream>
#include <fstream>

using namespace std;

//**************Global Data
char ifileName[30];
char oFileName[30];
fstream inFile;
fstream outFile;

//************ Data structure 
struct GLfloatPoint
{ GLfloat x,y;
};

const int MAX = 100;
class GLfloatPointArray
{
public:
  int num;
  GLfloatPoint pt[MAX];
};

//***************** subprograms
typedef GLfloat colorType[3];
// subprogram used to draw the control points separately
void drawDot (GLfloat x, GLfloat y, GLfloat r, GLfloat g, GLfloat b)
{ glColor3f(r,g,b);
  glBegin (GL_POINTS);
      glVertex2f (x,y);
  glEnd();
}
// Drawing subprogram - this will draw the curve from a set of points
void drawFloatPolyLine (GLfloatPointArray P, colorType c)
{ glColor3fv (c);
  glBegin(GL_LINE_STRIP);
   for (int i=0; i < P.num; i++)
     glVertex2f (P.pt[i].x,P.pt[i].y);
  glEnd();
}

//******************** myInit 
 void myInit(void)
 {
    glClearColor(1.0,1.0,1.0,0.0);  // set white background color
    glColor3f (0.0f,0.0f,0.0f);    //default color
    glMatrixMode(GL_PROJECTION); 
    glLoadIdentity();
    gluOrtho2D(0.0, 640.0, 0.0, 480.0);
    // get data files
    cout << "Enter the input file name: ";
    cin >> ifileName;
    inFile.open (ifileName,ios::in);
    if (inFile.fail())
      return;
    // if want to see points for debugging add output
    // cout << "Enter the output file name: ";
    // cin >> oFileName;
    // outFile.open (oFileName,ios::out);
    // if (outFile.fail())
    //   return;
}

//***************** BEZIER Curve subprograms
// Read the control points 
void readControlPoints (GLfloatPointArray &P)
{
  inFile >> P.num;
  for (int j = 0; j < P.num; j++)
    inFile >> P.pt[j].x >> P.pt[j].y;
}
// output control points to a text file - if you want to see the 
// computations
void printPointArray (GLfloatPointArray P)
{
  outFile << "Size: " << P.num << endl << "Points:" << endl;
  for (int j = 0; j < P.num; j++)
    outFile << "(" << P.pt[j].x << "," << P.pt[j].y << ")" << endl;
}

const int MAXCONTPTS = 100;
int c[MAXCONTPTS];   // the binomial coefficients
//helper routines - compute the coefficient
void ComputeCoeff (int n)
{ int j,k;
  for (k=0;k<=n;k++)
  { //compute n! / (k!*(n-k)!)
    c[k] = 1;
    for (j = n;j>=k+1;j--)
      c[k] *=j;
    for (j = n-k;j>=2;j--)
      c[k] /= j;
  }
}
// compute the blending value
float BlendingValue (int n, int k, float t)
{ int j;
  float bv;
  // compute  c[k]*t^k * (1-t)^(n-k)
  bv = c[k];
  for (j=1; j<=k;j++)
    bv *= t;
  for (j = 1;j<=n-k;j++)
    bv *= (1-t);
  return bv;
}

// compute one point on the Bezier curve - fixed value of t
void ComputePoint (float t, int n, GLfloatPoint & p, 
                   GLfloatPointArray ctrlPts)
{ int k;
  float b;
  p.x = 0.0;
  p.y = 0.0;
  for (k = 0; k<=n;k++)
  {  b = BlendingValue (n,k,t);
     p.x += ctrlPts.pt[k].x*b;
     p.y  += ctrlPts.pt[k].y*b;
  }
}
// compute the array of Bezier points - drawing done separately
void Bezier ( GLfloatPointArray controlPts, int numInter, 
              GLfloatPointArray & curve)
{ // there are numContPts+1 control points and numInter t values to evaluate the curve
  int k;
  float t;
  ComputeCoeff (controlPts.num-1);
  curve.num = numInter+1;
  for (k=0; k<=numInter; k++)
  { t = (float) k / (float) numInter;
    ComputePoint (t, controlPts.num-1,curve.pt[k],controlPts);
  }
}

//************************ myDisplay 
void myDisplay(void)
{  
   int numbCurves;
   GLfloatPointArray ControlPts,BezCurve;
   colorType C = {0.0f,1.0f,0.0f};

   glClear(GL_COLOR_BUFFER_BIT);     // clear the screen 

   inFile >> numbCurves;
   for (int i = 0; i < numbCurves; i++)
   { 
     // read control points and draw them in red big points
     readControlPoints (ControlPts);
     glPointSize (4.0);
     for (int j = 0; j < ControlPts.num; j++)
       drawDot (ControlPts.pt[j].x,ControlPts.pt[j].y,1,0,0);
     glPointSize (1.0);
     // Compute the Bezier curve points and draw
     Bezier (ControlPts,50,BezCurve);
       // draw the Bezier curve
     drawFloatPolyLine (BezCurve,C);
     glFlush ();
   }
}

//**************************** main
void main(int argc, char** argv)
{
    glutInit(&argc, argv);          // initialize the toolkit
    glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB); // set display mode
    glutInitWindowSize(640,480);     // set window size
    glutInitWindowPosition(100, 150); // set window position on screen
    glutCreateWindow("Bezier Curve drawing"); // open the screen window
    glutDisplayFunc(myDisplay);     // register redraw function
    myInit();                   
    glutMainLoop();              // go into a perpetual loop
}

The following code compiles on VS Express Edition 2008, yet I get the following errors when trying to debug/release:

1>Linking...
1>MSVCRT.lib(crtexew.obj) : error LNK2001: unresolved external symbol _WinMain@16
1>E:Documents and SettingsAdministratorDesktopProyecto 2 gràficastestingReleasetesting.exe : fatal error LNK1120: 1 unresolved externals

is it because it’s unable to link a library? How can I solve this?

#include <windows.h>   // use as needed for your system

#include <gl/Gl.h>
#include <gl/glut.h>
#include <iostream>
#include <fstream>

using namespace std;

//**************Global Data
char ifileName[30];
char oFileName[30];
fstream inFile;
fstream outFile;

//************ Data structure 
struct GLfloatPoint
{ GLfloat x,y;
};

const int MAX = 100;
class GLfloatPointArray
{
public:
  int num;
  GLfloatPoint pt[MAX];
};

//***************** subprograms
typedef GLfloat colorType[3];
// subprogram used to draw the control points separately
void drawDot (GLfloat x, GLfloat y, GLfloat r, GLfloat g, GLfloat b)
{ glColor3f(r,g,b);
  glBegin (GL_POINTS);
      glVertex2f (x,y);
  glEnd();
}
// Drawing subprogram - this will draw the curve from a set of points
void drawFloatPolyLine (GLfloatPointArray P, colorType c)
{ glColor3fv (c);
  glBegin(GL_LINE_STRIP);
   for (int i=0; i < P.num; i++)
     glVertex2f (P.pt[i].x,P.pt[i].y);
  glEnd();
}

//******************** myInit 
 void myInit(void)
 {
    glClearColor(1.0,1.0,1.0,0.0);  // set white background color
    glColor3f (0.0f,0.0f,0.0f);    //default color
    glMatrixMode(GL_PROJECTION); 
    glLoadIdentity();
    gluOrtho2D(0.0, 640.0, 0.0, 480.0);
    // get data files
    cout << "Enter the input file name: ";
    cin >> ifileName;
    inFile.open (ifileName,ios::in);
    if (inFile.fail())
      return;
    // if want to see points for debugging add output
    // cout << "Enter the output file name: ";
    // cin >> oFileName;
    // outFile.open (oFileName,ios::out);
    // if (outFile.fail())
    //   return;
}

//***************** BEZIER Curve subprograms
// Read the control points 
void readControlPoints (GLfloatPointArray &P)
{
  inFile >> P.num;
  for (int j = 0; j < P.num; j++)
    inFile >> P.pt[j].x >> P.pt[j].y;
}
// output control points to a text file - if you want to see the 
// computations
void printPointArray (GLfloatPointArray P)
{
  outFile << "Size: " << P.num << endl << "Points:" << endl;
  for (int j = 0; j < P.num; j++)
    outFile << "(" << P.pt[j].x << "," << P.pt[j].y << ")" << endl;
}

const int MAXCONTPTS = 100;
int c[MAXCONTPTS];   // the binomial coefficients
//helper routines - compute the coefficient
void ComputeCoeff (int n)
{ int j,k;
  for (k=0;k<=n;k++)
  { //compute n! / (k!*(n-k)!)
    c[k] = 1;
    for (j = n;j>=k+1;j--)
      c[k] *=j;
    for (j = n-k;j>=2;j--)
      c[k] /= j;
  }
}
// compute the blending value
float BlendingValue (int n, int k, float t)
{ int j;
  float bv;
  // compute  c[k]*t^k * (1-t)^(n-k)
  bv = c[k];
  for (j=1; j<=k;j++)
    bv *= t;
  for (j = 1;j<=n-k;j++)
    bv *= (1-t);
  return bv;
}

// compute one point on the Bezier curve - fixed value of t
void ComputePoint (float t, int n, GLfloatPoint & p, 
                   GLfloatPointArray ctrlPts)
{ int k;
  float b;
  p.x = 0.0;
  p.y = 0.0;
  for (k = 0; k<=n;k++)
  {  b = BlendingValue (n,k,t);
     p.x += ctrlPts.pt[k].x*b;
     p.y  += ctrlPts.pt[k].y*b;
  }
}
// compute the array of Bezier points - drawing done separately
void Bezier ( GLfloatPointArray controlPts, int numInter, 
              GLfloatPointArray & curve)
{ // there are numContPts+1 control points and numInter t values to evaluate the curve
  int k;
  float t;
  ComputeCoeff (controlPts.num-1);
  curve.num = numInter+1;
  for (k=0; k<=numInter; k++)
  { t = (float) k / (float) numInter;
    ComputePoint (t, controlPts.num-1,curve.pt[k],controlPts);
  }
}

//************************ myDisplay 
void myDisplay(void)
{  
   int numbCurves;
   GLfloatPointArray ControlPts,BezCurve;
   colorType C = {0.0f,1.0f,0.0f};

   glClear(GL_COLOR_BUFFER_BIT);     // clear the screen 

   inFile >> numbCurves;
   for (int i = 0; i < numbCurves; i++)
   { 
     // read control points and draw them in red big points
     readControlPoints (ControlPts);
     glPointSize (4.0);
     for (int j = 0; j < ControlPts.num; j++)
       drawDot (ControlPts.pt[j].x,ControlPts.pt[j].y,1,0,0);
     glPointSize (1.0);
     // Compute the Bezier curve points and draw
     Bezier (ControlPts,50,BezCurve);
       // draw the Bezier curve
     drawFloatPolyLine (BezCurve,C);
     glFlush ();
   }
}

//**************************** main
void main(int argc, char** argv)
{
    glutInit(&argc, argv);          // initialize the toolkit
    glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB); // set display mode
    glutInitWindowSize(640,480);     // set window size
    glutInitWindowPosition(100, 150); // set window position on screen
    glutCreateWindow("Bezier Curve drawing"); // open the screen window
    glutDisplayFunc(myDisplay);     // register redraw function
    myInit();                   
    glutMainLoop();              // go into a perpetual loop
}

Определение

Данная ошибка означает, что в процессе компоновки программы, компоновщик не смог найти определение некоторой сущности, на которую есть ссылка (попытка использования) в программе.

К таким сущностям может относиться, например, функция или переменная.

Причины и решения

Возможных причин появления ошибки может быть несколько и это зависит от того, что представляет из себя собираемый проект. Всё множество ситуаций можно разбить на две большие группы:

Используются сторонние библиотеки

• Не указана необходимая (статическая) библиотека для компоновщика.

  Например, к проекту подключен только *.h файл с объявлениями, но отсутствует код реализации, обычно это *.lib или *.a файлы (в зависимости от используемой системы).
  Требуется явно подключить библиотеку к проекту.

• Для Visual C++ это можно сделать добавлением следующей строки прямо в код:

  #pragma comment(lib, "libname.lib")
  

• Для gcc/clang требуется указать файл через ключ -l (эль)

• Для Qt в .pro файле нужно использовать переменную LIBS:

  LIBS += -L[путь_к_библиотеке] -l[имя_библиотеки]
  

• Для системы сборки cmake есть target_link_libraries.

• Библиотека указана, но необходимая сущность, например, класс или функция фактически не экспортируется из библиотеки. Под Windows это может возникать из-за отсуствия __declspec(dllexport) перед сущностью. Обычно это решается макросами. Данная ситуация чаще всего характерна именно для библиотек, находящихся в процессе разработки, и доступных для модификации самому разработчику, нежели для каких-то стабильных версий действительно внешних для проекта библиотек. После разрешения экспортирования библиотеку, конечно же, нужно пересобрать перед непосредственным использованием проблемной сущности.

• Библиотека указана, но не совпадает разрядность библиотеки и компилируемого кода.

  В общем случае, разрядность собираемого проекта (приложения или библиотеки) должна совпадать с разрядностью используемой сторонней библиотеки. Обычно производители библиотек предоставляют возможность выбора 32 или 64 бит версию использовать. Если библиотека поставляется в исходных кодах и собирается отдельно от текущего проекта, нужно также выбрать правильную разрядность.

• Библиотека указана, но она собрана для другой (не совместимой) ОС.

  Например при сборке проекта в Windows осуществляется попытка использовать бинарный файл, собранный для Linux. В данном случае нужно использовать файлы, подходящие для вашей ОС.

• Библиотека указана, но она собрана другим компилятором, не совместимым с используемым.

  Объектные файлы, полученные путем сборки C++ кода разными компиляторами для одной и той же ОС могут быть бинарно несовместимы друг с другом. Требуется использовать совместимые (скорее всего и вовсе одинаковые) компиляторы.

• Библиотека указана, и собрана тем же компилятором, что и основной проект, но используются разные версии Run-Time библиотек.

  Например, для Visual C++ возможна ситуация, когда библиотека собрана с ключом /MDd, а основной проект с /MTd. Требуется задать ключи так, чтобы использовались одинаковые версии Run-Time библиотек.

Сторонние библиотеки не используются

• Просто отсутствует определение функции.

  void f(int); // всего лишь объявление. Нет `тела` функции
  int main(){  
      f(42);   // undefined reference to `f(int)'
  }  
  

  Требуется добавить определение функции f:

  void f(int) {
      // тело функции
  }
  

  Может быть ещё частный случай с ошибкой вида:

  undefined reference to `vtable for <имя_класса>`
  

  Такая ошибка возникает, если объявленная виртуальная функция класса, не являющаяся чистой (=0), не содержит реализации.

  class C {
      virtual void f(int);
  };
  

  Нужно такую реализацию добавить. Если это делается вне класса, надо не забыть указать имя проблемного класса, иначе это будет просто свободная функция, которая не устраняет указанную проблему:

  void C::f(int) { // виртуальная функция-член вне определения класса
      // тело функции  
  } 
  
  void f(int) { // свободная функция, не устраняющая проблему
      // тело функции 
  } 
  

  Аналогичная ситуация может возникать при использовании пространств имён, когда объявлении функции находится в пространстве имён:

  // В заголовочном файле
  namespace N {
      void f(int);
  };    
  

  а при реализации указать это пространство имён забыли:

  // В файле реализации
  void f(int) { // функция в глобальном пространстве имён, не устраняющая проблему
      // тело функции  
  }
  
  namespace N {
  void f(int) { // функция в нужном пространстве имён
      // тело функции  
  }
  } // конец пространства имён
  

  Стоит заметить, что C++ разрешает перегрузку функций (существование одноимённых функций, но с разным набором параметров), и в этом случае важно, чтобы сигнатуры функций при объявлении и определении совпадали. Например, вместо объявленной void f(int) была реализована другая:

  void f(const char*) { // const char* вместо int
      // тело функции     
  }
  

  При вызове f(42) будет ошибка:

  undefined reference to `f(int)'
  

  Наличие связки шаблонного класса и дружественной функции также может приводить к ошибке. Например:

  template <class T>
  struct C {
      friend void f(C<T>);   // объявляет *НЕ*шаблонную дружественную функцию
  };
  
  template <class T>         // определяет шаблонную функцию 
  void f(C<T>) { }
  
  int main() {
      C<int> c;
      f(c);                  // undefined reference to `f(C<int>)'
  }
  

  Чтобы объявить шаблонную дружественную функцию, требуется добавить указание шаблонности:

  template <class T>
  struct C {
      template <class V>     // добавили шаблонность для friend функции
      friend void f(C<T>);
  };
  

  Важно, что имя шаблонного параметра для дружественной функции должно отличаться от имени параметра шаблонного класса T, т.к. иначе будет ошибка о сокрытии имени. В частном случае имя класса можно вовсе не указывать, и оставить template <class>. Но это не всегда будет правильным решением, т.к. фактически могла потребоваться дружественная специализация шаблона функции, а не сама шаблонная функция. Подробнее об использовании дружественных функций в шаблонном классе можно ознакомиться здесь.

• Отсутствует определение статической переменной класса.

  struct S {
      static int i;
  };
  
  int main() {
      S s;
      s.i = 42;  // undefined reference to `S::i'
  }
  

  Нужно добавить определение (выделить память) переменной:

  int S::i;
  

• Неправильная реализация шаблонного кода.

  Например, реализация шаблонного кода помещена в *.cpp файл, хотя она должна находиться полностью в подключаемом *.h файле. Это требуется по той причине, что компилятор обрабатывает каждый модуль независимо, и в момент инстанцирования шаблона (подстановки конкретного типа) код его реализации должен быть виден. При этом если возможные типы шаблона известны заранее, можно произвести инстанцирование сразу рядом с телом шаблона и не предоставлять его наружу в исходном коде заголовочного файла. Пример:

  // unit.h
  #pragma once
  
  template <class T>
  T f(T);                    // объявление шаблона без реализации
  

  // unit.cpp
  #include "unit.h"
  
  template <class T>
  T f(T t) { return t + t; } // реализация шаблона
  
  template
  int f<int>(int);           // явное инстанцирование для int
  
  template
  double f<double>(double);  // явное инстанцирование для double
  

  // main.cpp
  #include "unit.h"
  
  int main() { 
      f(2);   // ok int
      f(1.5); // ok double
      f('a'); // undefined reference to `char f<char>(char)'
  }
  

• Файл с кодом не был скомпилирован.

  Например, в случае использования make-файла не было прописано правило построения файла, а в случае использования IDE типа Visual Studio *.cpp файл не добавлен в список файлов проекта.

• Виртуальная функция в базовом классе не объявлена как = 0 (pure-virtual).

  struct B {
      void virtual f();
  };
  
  struct D : B {
      void f() {}
  };
  
  int main() {
      D d;
  }
  

  При использовании иерархии классов функция в базовом классе, не имеющая реализации должна быть помечена как «чистая»:

  struct B {
      void virtual f() = 0;
  };
  

• Имя не имеет внешнего связывания.

  Например, есть объявление функции f в модуле А и даже ее реализация в модуле B, но реализация помечена как static:

  // A.cpp
  void f();
  int main() {
      f();   // undefined reference to `f()'
  }
  
  // B.cpp
  static void f() {}
  

  Аналогичная ситуация может возникнуть при использовании безымянного пространства имен:

  // B.cpp
  namespace {
     void f() {}
  }
  

  Или даже при наличии inline у функции:

  // B.cpp
  inline void f() {}
  

Как говорят, «или крест снимите, или трусы наденьте». И учите понятие «единица компиляции».
По какой схеме устроен ваш проект? «Одна единица компиляции» или «много единиц компиляции»?

Си недалеко ушёл от ассемблеров. А в ассемблерах программа компилировалась по частям и собиралась воедино линкером (компоновщиком, редактором связей) — в те времена кода было много, а данных мало. Многие из ошибок невозможно было определить, не запустив линкер. Си++ пользуется многими из архитектурных особенностей ассемблеров и Си — по крайней мере ни одно из модульных решений не стало рекомендацией (кроме костыля extern template class).

Но как говорить «переменная/функция есть, такого-то типа и в другой единице компиляции»? Для этого есть прототипы функций и extern-определения переменных. Их обычно вносят в заголовочные файлы с таким требованием: ничего, что находится в заголовочном файле, не должно производить кода. А код производят…
• Глобальные переменные (без typedef, extern).
• Нешаблонные функции (кроме inline).
• Полностью специализированные шаблонные функции (кроме inline).
• Команда «специализировать шаблон» (template class).

При этом…
• Функции в теле struct/class автоматически inline и кода не производят.
• Для неявной специализации шаблонов существуют обходы — код генерируется дважды, но ошибки не выдаёт.
• «Свой» хедер обычно включают первым, чтобы убедиться, что в нём нет недостающих зависимостей.

В системе «одна единица компиляции» всё просто: есть ровно один файл, подлежащий компиляции. Тогда в хедерных файлах вполне могут быть конструкции, производящие код.

Системы «одна единица компиляции» и «много единиц компиляции» можно комбинировать, но надо знать:
• Все хедеры, которые производят код, должны подключаться из одной-единственной единицы компиляции. Надо чётко осознавать, из какой, и не подключать из чужих.
• У библиотеки всё равно должен быть хедер-фасад, не производящий кода и предназначенный для стыковки с другими единицами компиляции.
Такая конструкция ускоряет полную перекомпиляцию и часто применяется для библиотек, но надо знать: огромные библиотеки вроде SqLite, в 5 мегабайт препроцессированного кода, мешают распараллеливанию компиляции (ибо пока откомпилируется SqLite, остальные процессоры вполне себе соберут остальную программу).

// В схеме «одна единица компиляции»: ничего не делать.
// В схеме «много единиц компиляции»: лишняя зависимость; унести в unit1.cpp
#include <cstdlib>

// В схеме «одна единица компиляции»: убрать extern.
// В схеме «много единиц компиляции»: завести unit1.cpp, там сделать MyType x;
extern MyType X;

// В схеме «одна единица компиляции»: ничего не делать.
// В схеме «много единиц компиляции»: перенести функцию в unit1.cpp, оставив в .h только прототип.
void XReset() {}