First defined here c ошибка

The problem here is that you are including commands.c in commands.h before the function prototype. Therefore, the C pre-processor inserts the content of commands.c into commands.h before the function prototype. commands.c contains the function definition. As a result, the function definition ends up before than the function declaration causing the error.

The content of commands.h after the pre-processor phase looks like this:

#ifndef COMMANDS_H_
#define COMMANDS_H_

// function definition
void f123(){

}

// function declaration
void f123();

#endif /* COMMANDS_H_ */

This is an error because you can’t declare a function after its definition in C. If you swapped #include "commands.c" and the function declaration the error shouldn’t happen because, now, the function prototype comes before the function declaration.

However, including a .c file is a bad practice and should be avoided. A better solution for this problem would be to include commands.h in commands.c and link the compiled version of command to the main file. For example:

commands.h

#ifndef COMMANDS_H_
#define COMMANDS_H_

void f123(); // function declaration

#endif

commands.c

#include "commands.h"

void f123(){} // function definition

Recommended Answers

All 7 Replies

#ifndef ...
#define ...
// code
#endif

#ifndef FUNCCNTRLPARAMS_H_
#define FUNCCNTRLPARAMS_H_

#include <QWidget>
#include <QStringList>
class FuncCntrlParams : public QWidget
{
	Q_OBJECT
	
public:
	/**
	 * Constructs a new FuncCntrlParams QWidget.
	 */
	FuncCntrlParams(QWidget *parent=0);
	static QStringList type_pairPotList;
};

QStringList FuncCntrlParams::type_pairPotList = QStringList() << "Pair LJ12-6 CS" << "Pair Coulomb CS" << "Pair Coulomb" << "Pair Yukawa CS";
#endif /*FUNCCNTRLPARAMS_H_*/

//interpotcntrlparams.cpp
#include "interpotcntrlparams.h"
#include "surfcntrlparams.h"
#include "funccntrlparams.h"
.
.
.

//funcntrlparams.cpp
.
.
FuncCntrlParams::FuncCntrlParams(QWidget *parent)
	:QWidget(parent)
{
	QStringList type_pairPotList = QStringList() << "Pair LJ12-6 CS" << "Pair Coulomb CS" << "Pair Coulomb" << "Pair Yukawa CS";
.
.
}
.
.

//funcntrlparams.cpp
.
.
QStringList type_pairPotList = QStringList() << "Pair LJ12-6 CS" << "Pair Coulomb CS" << "Pair Coulomb" << "Pair Yukawa CS";
FuncCntrlParams::FuncCntrlParams(QWidget *parent)
	:QWidget(parent)
{
.
.
}
.
.

Reply to this topic

Друзья, что это за ошибка?

Ниже присказка: «collect2: ld returned 1 exit status»

читал. Пишут. что из-за повторных #include-ов. Но не пойму, где я напортачил

Среда QT Creator

Проект — dll. При создании автоматически средой был создан конструктор:

1
2
3
4

class HOOK32SHARED_EXPORT HookNET32 {
public:
    HookNET32();
};

и реализация:

1

HookNET32::HookNET32(){}

на нее эта ошибка указывает

В принципе они мне не нужны. Мне там нечего инициализировать. Я просто экспортирую extern функции. В этом весь смысл.

Повторных #include у себя не вижу. Здесь находил, что это может быть из-за using namespace в заголовочном файле. Перебрал все в *.cpp-шные. Впрочем судите сами:

alloc.h:

1
2
3
4

#pragma once
 
#include <vector>
#include <windows.h>

main.h

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#pragma once
 
#ifndef HOOKNET32_H
#define HOOKNET32_H
//#define WIN32
 
#include "hook32_global.h"
#include <iostream>
#include <map>
#include <algorithm>
 
#include "alloc.h"
 
typedef unsigned char BYTE;
typedef unsigned long DWORD;

alloc.cpp

1
2
3

#include "alloc.h"
 
using namespace std;

main.cpp

1
2
3
4
5
6
7
8

#include "main.h"
 
using namespace std;
 
HookNET32::HookNET32(){}
 
typedef map <BYTE,ifunct*> DictOf_Funcs;
typedef vector <vector <void*> > VecV_vp;

PS: так же в каждом заголовочном на вс случай везде поставил #pragme once

В ссылке на стек есть решение, обозначить функции как inline. Я попробовал, действительно, на эту функцию не ругается. Но ругается на следующую. Я думаю, это не есть нормально

Добавлено через 43 минуты
Блин,я думал, что нашел, что ошибку…

У меня в «alloc.h» была структура и класс:

1
2
3
4
5
6
7
8
9
10
11
12

struct jmp_near
{
 
  BYTE push_sign;
  
};
 
class Alloc
{
public:
    int CalcVolume_ByFuncs(std::vector < std::vector<void*> > *funcs_BySign);
};

В alloc.cpp реализация:

1
2
3
4
5
6
7
8
9
10

int Alloc::CalcVolume_ByFuncs(vector<vector<void *> > *funcs_BySign)
{
    int sum = 0;
    for (int i=0;i<funcs_BySign->size();i++){
        for (int j=0;j<funcs_BySign->at(i).size();j++){
            sum++;
        }
    }
    return sizeof(jmp_near)*sum;
}

Как только заменил sizeof(jmp_near) на sizeof(1) все сразу заработало

Но для меня эта ошибка не понятна, т.к. в основном коде я постоянно использую конструкцию sizeof(jmp_near), например, скопировав тело jmp_near в основной код

1
2
3
4

class functD
{
    BYTE old_code[sizeof(jmp_near)];           //старый код
};

И все прекрасно компилировалось и компилируется.

Добавлено через 3 минуты
Короче, только я добавил этот коммент и все перестало компилироваться

Я просто написал одну строку cout << … в основном коде и удалил ее. Откомпилировалось только тогда когда я удалил весь код из alloc.cpp.

Когда же я добавил в alloc.cpp только:

1
2
3

#include "alloc.h"
 
using namespace std;

то он отказался компилироваться и выдал ту же ошибку. Что за фигня?

Добавлено через 12 минут
Теперь он компилируется при:

alloc.h

1
2
3
4

#pragma once
 
#include <vector>
#include <windows.h>

и

alloc.cpp

1
2
3

#include "alloc.h"
 
using namespace std;

Но отказывается, если я добавлю в alloc.h

1

std::vector <std::vector<void*> > Funcs_BySign;

Ничего не пойму. Компилятор мне таким образом запрещает объявить глобальную переменную. Это нормально?

Добавлено через 56 секунд
PS: пересборка не помогает. Смириться?

(This smells like a homework assignment.)

First, the error message:

boo.c multiple definition of main
light.o:light.c:first defined here.

It indicates the files you’re attempting to link together have multiple copies of a function named main(), and that is clearly not correct.

You’re trying to reuse light.o, but that would really work only if it had a function other than main(). Let’s call it light(). You would also need a .h file #included in boo.c, so that the compiler will know the properties (basically the types of the parameters and the type of return value, if it has any) of the function light() without yet seeing its source code.

It seems to me that your files fit together somewhat differently from what is expected in the assignment. Your professor may have created a series of assignments that tie together: if you take shortcuts in the previous assignments in the series, the later assignments that reuse code from the previous ones won’t work right.

Your professor is attempting to teach you how to arrange your code so that it’ll be reusable, and what happens if you fail to do so.

The basic form of Makefile rules is:

<name of target>: <names of files the creation process depends on>
        <command(s) to create the target file>

The creation of a .c file depends not only of the file itself, but also of the .h files it includes. Generally you can assume that any system include files (those you include with #include <filename> won’t change on you, so you won’t need to add those into your Makefile rules. But any .h files that are part of your project should be included too.

There can also be «virtual targets» that are not actually files. They allow you to do things like make clean. You can also use a virtual target as a dependency of another target: since a virtual target does not have a real file associated with it, the commands to «create» the virtual target will be executed each time the virtual target is listed as a dependency for something else and that something else needs to be built.

Also, there can be Makefile rules that don’t have any commands in them, but list one or more Makefile targets as their dependencies. If there is just one dependency, then the target with no commands acts just as an another name to the target listed as a dependency. If it has multiple dependencies, then the command-less target becomes a way to have multiple Makefile targets built with a single command.

It sounds to me like your professor intended the build: target to become such a target with no commands of its own. It should just depend on two targets:

• a separate target to build the actual executable
• the templates target

You may wonder how I knew about the contents of light.o without seeing its source code? Simple — I downloaded your light.o and then used this command:

$ readelf -s light.o

Symbol table '.symtab' contains 12 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS light.c
     2: 00000000     0 SECTION LOCAL  DEFAULT    1 
     3: 00000000     0 SECTION LOCAL  DEFAULT    3 
     4: 00000000     0 SECTION LOCAL  DEFAULT    4 
     5: 00000000     0 SECTION LOCAL  DEFAULT    5 
     6: 00000000     0 SECTION LOCAL  DEFAULT    7 
     7: 00000000     0 SECTION LOCAL  DEFAULT    8 
     8: 00000000     0 SECTION LOCAL  DEFAULT    6 
     9: 00000000    51 FUNC    GLOBAL DEFAULT    1 main
    10: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND puts
    11: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND sound

That tells me light.o comes from a source file named light.c, defines a function named main() and uses functions named puts() and sound(), which are not defined here. puts() comes from the standard library, but sound() needs to be defined in some other file that is linked together with this one to make a complete executable.