в общем,пишу первый в жизни make, компилящий один cpp и один .c файл


процесс завершается с ошибкой "не найден cplusplus.c", хотя реальный файл "cplusplus.cpp"

Здравствуйте, Molchalnik, Вы писали:

M>в общем,пишу первый в жизни make, компилящий один cpp и один .c файл


M>процесс завершается с ошибкой "не найден cplusplus.c", хотя реальный файл "cplusplus.cpp"

Последний написанный Makefile:

CC=c++
FL= -lX11 -lm -lGL -ljpeg -lXext -std=c++0x  -DGL_GLEXT_PROTOTYPES
HD=-I`pwd`
DESTDIR=
SRC=main.cpp window.cpp models.cpp sphere.cpp scene.cpp image.cpp
DST=main.o window.o models.o sphere.o scene.o image.o
PRG=mountain
PROG=/usr/share/prog
MODELS=/usr/share/prog/models
IMAGE=/usr/share/prog/image
SHADER=/usr/share/prog/shaders
all: $(DST)
    $(CC) -o $(PRG) $(DST) $(FL) $(HD)
$(DST): $(SRC)
    $(CC) -c $(SRC) $(FL) $(HD)
clean:
    rm -f $(DST)
install:
    if [ ! -d  $(DESTDIR)/$(PROG) ]; then mkdir -p $(DESTDIR)/$(PROG);fi
    if [ ! -d  $(DESTDIR)/$(MODELS) ]; then mkdir -p $(DESTDIR)/$(MODELS);fi
    if [ ! -d  $(DESTDIR)/$(IMAGE) ]; then mkdir -p $(DESTDIR)/$(IMAGE);fi
    if [ ! -d  $(DESTDIR)/$(SHADER) ]; then mkdir -p $(DESTDIR)/$(SHADER); fi
    if [ ! -d  $(DESTDIR)/usr/bin ]; then mkdir -p $(DESTDIR)/usr/bin; fi
    cp ./image/*.jpg $(DESTDIR)/$(IMAGE)
    cp ./models/* $(DESTDIR)/$(MODELS)
    cp ./shaders/* $(DESTDIR)/$(SHADER)
    cp ./ball $(DESTDIR)/usr/bin

Здравствуйте, Molchalnik, Вы писали:

M>в общем,пишу первый в жизни make, компилящий один cpp и один .c файл

Лучше бы этот Makefile в студию.

M>процесс завершается с ошибкой "не найден cplusplus.c", хотя реальный файл "cplusplus.cpp"

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

Ещё не указана платформа. Если это Unix, то .cpp по умолчанию может быть суффиксом для входа для препроцессора Си, а не компилятора Си++ (за которым зарезервированы .C, .cc, .cxx). Это уже зависит от флавора системы.

Здравствуйте, netch80, Вы писали:

N>С ходу предполагаю, что в файле есть зависимость бинарника от .o-файлов и не указаны собственно исходные файлы.
N>Обычно рекомендуется или наоборот (список исходников, а из них вычисляются объектники), или явное описание зависимостей каждого .o от соответствующего исходного.

N>Ещё не указана платформа. Если это Unix, то .cpp по умолчанию может быть суффиксом для входа для препроцессора Си, а не компилятора Си++ (за которым зарезервированы .C, .cc, .cxx). Это уже зависит от флавора системы.


платформа — Linux

Makefile —

ifneq ($(KERNELRELEASE),)

obj-m := hello.o

else

default: all

BLD_DIR ?= $(PWD)/../../

# linux kernel module targets

MDIR := $(BLD_DIR)/modules/
KDIR ?= /lib/modules/`uname -r`/build

# module include directories

modules:
        $(MAKE) -C $(KDIR) M=$(PWD) modules

modules_install: modules
        mkdir -p $(MDIR)
        $(MAKE) -C $(KDIR) M=$(PWD) INSTALL_MOD_PATH=$(MDIR) modules_install

modules_uninstall:
        rm -rf $(MDIR)

modules_clean:
    $(MAKE) -C $(KDIR) M=$(PWD) clean

all: modules

clean: modules_clean

install: modules_install

uninstall: modules_uninstall

endif

с сишными файлами оно работает, а подключаю cpp — и всё. пробовал добавлять

.SUFFIXES: .o .c .cpp .cc .cxx .C

.cpp.o:
    $(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$@" "$<"

.cc.o:
    $(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$@" "$<"

.cxx.o:
    $(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$@" "$<"

.C.o:
    $(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$@" "$<"

.c.o:
    $(CC) -c $(CFLAGS) $(INCPATH) -o "$@" "$<"

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

Здравствуйте, Molchalnik, Вы писали:

M>Здравствуйте, netch80, Вы писали:

N>>С ходу предполагаю, что в файле есть зависимость бинарника от .o-файлов и не указаны собственно исходные файлы.
N>>Обычно рекомендуется или наоборот (список исходников, а из них вычисляются объектники), или явное описание зависимостей каждого .o от соответствующего исходного.

N>>Ещё не указана платформа. Если это Unix, то .cpp по умолчанию может быть суффиксом для входа для препроцессора Си, а не компилятора Си++ (за которым зарезервированы .C, .cc, .cxx). Это уже зависит от флавора системы.


M>платформа — Linux

M>Makefile -
M>

M>ifneq ($(KERNELRELEASE),)

M>obj-m := hello.o

M>else

M>default: all

M>BLD_DIR ?= $(PWD)/../../

M># linux kernel module targets

M>MDIR := $(BLD_DIR)/modules/
M>KDIR ?= /lib/modules/`uname -r`/build

M># module include directories

M>modules:
M>        $(MAKE) -C $(KDIR) M=$(PWD) modules

M>modules_install: modules
M>        mkdir -p $(MDIR)
M>        $(MAKE) -C $(KDIR) M=$(PWD) INSTALL_MOD_PATH=$(MDIR) modules_install

M>modules_uninstall:
M>        rm -rf $(MDIR)

M>modules_clean:
M>    $(MAKE) -C $(KDIR) M=$(PWD) clean

M>all: modules

M>clean: modules_clean

M>install: modules_install

M>uninstall: modules_uninstall

M>endif

M>

M>с сишными файлами оно работает, а подключаю cpp — и всё. пробовал добавлять


M>

M>.SUFFIXES: .o .c .cpp .cc .cxx .C

M>.cpp.o:
M>    $(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$@" "$<"

M>.cc.o:
M>    $(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$@" "$<"

M>.cxx.o:
M>    $(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$@" "$<"

M>.C.o:
M>    $(CXX) -c $(CXXFLAGS) $(INCPATH) -o "$@" "$<"

M>.c.o:
M>    $(CC) -c $(CFLAGS) $(INCPATH) -o "$@" "$<"
M>

M>и другие шамании, не помоглго. помогает только прямое, "лобовое" прописывание файлов, а зделать проект так, чтобы он автоматом разбирал, какой файл сишный, какой сиплюсплюсовский, не выходит

Чел, так Вы модули ядра на С++ писать вздумали? В каком ВУЗе Вас такому обучили?
В срочке $(MAKE) -C $(KDIR) M=$(PWD) ... Вы запускаете kenel-овский Makefile из /lib/modules/`uname -r`/build
который и компилит Ваши файлы, и это Makefile ничего про C++ не знает.

Здравствуйте, smeeld, Вы писали:



M>>и другие шамании, не помоглго. помогает только прямое, "лобовое" прописывание файлов, а зделать проект так, чтобы он автоматом разбирал, какой файл сишный, какой сиплюсплюсовский, не выходит

S>Чел, так Вы модули ядра на С++ писать вздумали? В каком ВУЗе Вас такому обучили?

Ни в каком. Просто писать на уровне ядра мне привычней на плюсах. Конечно, нужно это делать умеючи. Иначе будет фэйл.

Впрочем, на линухе я такого ещё не пробовал

S>В срочке $(MAKE) -C $(KDIR) M=$(PWD) ... Вы запускаете kenel-овский Makefile из /lib/modules/`uname -r`/build
S>который и компилит Ваши файлы, и это Makefile ничего про C++ не знает.

И что делать? как "припаять" плюсовый файл?

Здравствуйте, Molchalnik, Вы писали:

M>Ни в каком. Просто писать на уровне ядра мне привычней на плюсах. Конечно, нужно это делать умеючи. Иначе будет фэйл.

Это не win, для линуха в ядро пилят только на благородном C.


M>И что делать? как "припаять" плюсовый файл?

Если сможете написать на плюсах так, чтоб его переварил компилятор чистого C из gcc,
то тогда останется только файлы писать с расширением .c, или переписывайте всё ядро на плюсы.

Здравствуйте, smeeld, Вы писали:


S>Если сможете написать на плюсах так, чтоб его переварил компилятор чистого C из gcc,
S>то тогда останется только файлы писать с расширением .c, или переписывайте всё ядро на плюсы.

ну, а если сделать объектник из cpp файлов, и функции из него подключить в C файл?

для чего вообще тогда obj файлы нужны, если нельзя писать на разных языках?

Здравствуйте, smeeld, Вы писали:


M>>Ни в каком. Просто писать на уровне ядра мне привычней на плюсах. Конечно, нужно это делать умеючи. Иначе будет фэйл.

S>Это не win, для линуха в ядро пилят только на благородном C.

Дело не в уважении к традициям, а как сделать именно так. Как пират я имею возможность не уважать даже самые благородные традиции Английского Военно-морского Флота.


Просто есть задача — пришпилить к модулю функции из C++. Предположим, что функции на С++ написаны так, что они гарантированно будут работать даже в драйвере или модуле линукс.


То, что так обычно не делают — я знаю, и беру ответственность за это на себя. Осознанно и с полным пониманием возможных последствий. Поэтому вернёмся к вопросу — и я очень рассчитываю на вашу помощь, форумчане!!!

Здравствуйте, Molchalnik, Вы писали:
M>>>Ни в каком. Просто писать на уровне ядра мне привычней на плюсах. Конечно, нужно это делать умеючи. Иначе будет фэйл.

Он и случился.

S>>Это не win, для линуха в ядро пилят только на благородном C.

M>Дело не в уважении к традициям, а как сделать именно так. Как пират я имею возможность не уважать даже самые благородные традиции Английского Военно-морского Флота.

Не уважаете — действуйте как пират, против всех правил, компилите свои крестовые файлы руками в объектник.
Если сумеете не потянуть ничего из STL и прочих стандартных либ (даже libc), то оно может даже слинковаться, если сумеете через extern "C" свои функции обозвать или позвать их из ядра промангленными.

M>Просто есть задача — пришпилить к модулю функции из C++. Предположим, что функции на С++ написаны так, что они гарантированно будут работать даже в драйвере или модуле линукс.

Они там гарантированно работать не будут, скорее всего Вы даже не подозреваете, с какими опциями оно должно компилиться. Впрочем, V=1 Вам в руки.

M>То, что так обычно не делают — я знаю, и беру ответственность за это на себя. Осознанно и с полным пониманием возможных последствий. Поэтому вернёмся к вопросу — и я очень рассчитываю на вашу помощь, форумчане!!!

Какую именно ответственность Вы на себя берёте? Ну вот Вам последствие — не компилится, понимайте его.

Вы уж лучше на шарпе или дотнетовском басике, чтобы совсем кроссплатформенно, да и удобнее так. Ещё Дельфи хорош и PHP.

Здравствуйте, cures, Вы писали:

C>Здравствуйте, Molchalnik, Вы писали:
M>>>>Ни в каком. Просто писать на уровне ядра мне привычней на плюсах. Конечно, нужно это делать умеючи. Иначе будет фэйл.

C>Он и случился.

Поправь меня, если ошибаюсь. Разве недостаточно выкинуть всё, что требует инициализации run-time? любое статическое задание объектов, исключения, нетривиальные конструкторы, виртуальные классы и виртуальное наследование? классы создавать только через alloc и placement-new?
естественно, стандартные либы тянуть нельзя, ибо исключения.

Я что-то ещё забыл или не учёл?

S>>>Это не win, для линуха в ядро пилят только на благородном C.

M>>Дело не в уважении к традициям, а как сделать именно так. Как пират я имею возможность не уважать даже самые благородные традиции Английского Военно-морского Флота.

C>Не уважаете — действуйте как пират, против всех правил, компилите свои крестовые файлы руками в объектник.
C>Если сумеете не потянуть ничего из STL и прочих стандартных либ (даже libc), то оно может даже слинковаться, если сумеете через extern "C" свои функции обозвать или позвать их из ядра промангленными.

M>>Просто есть задача — пришпилить к модулю функции из C++. Предположим, что функции на С++ написаны так, что они гарантированно будут работать даже в драйвере или модуле линукс.

C>Они там гарантированно работать не будут, скорее всего Вы даже не подозреваете, с какими опциями оно должно компилиться. Впрочем, V=1 Вам в руки.

главное, чтобы rti не тянул — инициализацию в run-time

M>>То, что так обычно не делают — я знаю, и беру ответственность за это на себя. Осознанно и с полным пониманием возможных последствий. Поэтому вернёмся к вопросу — и я очень рассчитываю на вашу помощь, форумчане!!!

C>Какую именно ответственность Вы на себя берёте? Ну вот Вам последствие — не компилится, понимайте его.

да уже даже иногда что-то компилится начало

Здравствуйте, cures, Вы писали:


M>>Дело не в уважении к традициям, а как сделать именно так. Как пират я имею возможность не уважать даже самые благородные традиции Английского Военно-морского Флота.

C>Не уважаете — действуйте как пират, против всех правил, компилите свои крестовые файлы руками в объектник.
C>Если сумеете не потянуть ничего из STL и прочих стандартных либ (даже libc), то оно может даже слинковаться, если сумеете через extern "C" свои функции обозвать или позвать их из ядра промангленными.

я пытаюсь скомпилить в объектник, а потом вызвать Makefile из директории сырцов ядра. проблема в том, что я не знаю, как указать ему c++ объектник.

пока делаю так:

Makefile

obj-m += kernel.o 
redirfs-objs := main_module.o

CC = gcc
CXX = g++

KERNEL_DIR = /lib/modules/`uname -r`/build
INCPATH = -I$(PWD) -I$(KERNEL_DIR)/include
OBJPATH = $(PWD)

SOURCES = kernel.c main_module.cpp




all: cpp_file
    @echo start    
    $(MAKE)  modules


cpp_file: 
    @echo --- cpp_file
    $(CXX) -c main_module.cpp $(INCPATH)
    @echo --- cpp_file_ c_sub
    #$(CC) -c kernel.c $<    

c_file: 
    @echo --- c_file
    $(CC) -c kernel.o $<    

modules:
    @echo --- modules
    $(MAKE) -C $(KERNEL_DIR) M=$(PWD) EXTRA_CFLAGS=$(OBJPATH) INSTALL_MOD_PATH=$(PWD) modules

kernel.c

#include <linux/init.h>
#include <linux/module.h>

extern int cpp_init(void);
extern void cpp_cleanup(void);


static int __init hello_init(void)
{
    printk(KERN_INFO "Hello world!\n");
    return cpp_init();    // Non-zero return means that the module couldn't be loaded.
}
 
static void __exit hello_cleanup(void)
{
    printk(KERN_INFO "Cleaning up module.\n");
    cpp_cleanup();
}

module_init(hello_init);
module_exit(hello_cleanup);

main_module.cpp

extern "C" int  hello_init(void) {
  return 0;
}
extern "C" void  hello_cleanup(void) {
}

Получаю:

make[2]: Entering directory `/usr/src/kernels/2.6.32-431.17.1.el6.x86_64'
  Building modules, stage 2.
  MODPOST 1 modules
WARNING: "cpp_init" [/home/konstantin/eclipse_proj/make_test0/kernel.ko] undefined!
WARNING: "cpp_cleanup" [/home/konstantin/eclipse_proj/make_test0/kernel.ko] undefined!

Здравствуйте, Molchalnik, Вы писали:

А и правда, где у Вас определены cpp_init и cpp_cleanup? Они только объявлены.
А вот hello_init и hello_cleanup два раза определены, как статические в kernel.c и как глобальные в main_module.cpp

Там не только исключения и инициализация, ещё функций библиотечных нет
Ну и компилить надо с каким-нибудь пиком, с определённым размером стека и прочими тонкостями.

Здравствуйте, cures, Вы писали:

C>Здравствуйте, Molchalnik, Вы писали:

C>А и правда, где у Вас определены cpp_init и cpp_cleanup? Они только объявлены.
C>А вот hello_init и hello_cleanup два раза определены, как статические в kernel.c и как глобальные в main_module.cpp

Даже после исправления этого бага проект не заработал. По неизвестным мне причинам. При этом он скомпилился, но отказался регистрироваться, если в инициализации есть хотя бы один вызов cpp функции. Возможно, дело в том, что я даже не пытался применять хитрые ключи компиляции, или ещё что-то.

Но вот тут есть интересная статья. Проект, собранный по этой статье с некоторым допиливанием напильником работает. Ключи там рекомендуются -fno-builtin -fno-exceptions -fno-rtti -nostdinc, но при реальной комплияции происходит фигня, и в лог ядро линуха пишет рекомендацию перекомпилировать с ключом -mcmodel=kernel. С этим ключом работает уже лучше.

Но при этом замечаем, что в кроме инициализация и деинициализация, а внутри них нет вызова cpp.

Добавляем в инициализацию вызов функции start_driver, и получаем крах системы и перезагрузку. Почему? Потому что там некорректно используется new, та форма этого оператора, которая не переопределена.

Правим определения оператора new, и всё начинает нормально работать. Позже добавлю определения файлов.

cppmod.cpp

#include "kernel_api.h"
#include "local_new.h"
#include "cppmod.h"

class Driver {
 public:
  Driver()    :  _id(0) {
    printk(KERN_INFO "C++ driver started\n");
  }
  Driver(unsigned int dev_id)    :  _id(dev_id) {
    printk(KERN_INFO "C++ driver started\n");
  }
  ~Driver(void) {
    printk(KERN_INFO "Goodbye C++ driver\n");
  }

 private:
  unsigned int _id;
};

Driver *g_driver = NULL;

extern "C" int start_driver(void *data) {
  g_driver = static_cast<Driver *> ( Allocate(sizeof(Driver)) );
  new (g_driver) Driver;
  if (!g_driver) {
    return -1;
  }
  return 0;
}

extern "C" void stop_driver(void) {
  g_driver->~Driver();
  Free(g_driver);
}

cppmod.h

#ifndef CPP_MOD_H
#define CPP_MOD_H

#   ifdef __cplusplus
extern "C" {
#   endif

extern int start_driver(void* data);
extern void stop_driver(void);

#   ifdef __cplusplus
}
#   endif

#endif

local_new.h

#ifndef  LOCAL_NEW_H
#define  LOCAL_NEW_H

#include "kernel_api.h"

//inline void *operator new(size_t s) {
//inline void * operator new(size_t s) {
//  return Allocate(s);
//}

//inline void operator delete(void *p) {
//  return Free(p);
//}

void *operator new(size_t size, void *p) {
    return p;
}

// you may need other forms of new and delete
#endif //LOCAL_NEW_H

interface.c

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include "cppmod.h"

static int __init cppmod_init(void)
{
  printk(KERN_INFO "cpp module installed\n");
  start_driver(0);
  return 0;
}

static void __exit cppmod_exit(void)
{
  printk(KERN_INFO "cpp module removed\n");
}

module_init(cppmod_init);
module_exit(cppmod_exit);

MODULE_LICENSE("GPL");

kernel_api.c

#include <linux/module.h>

void *Allocate(size_t s) {
  return kmalloc(s, GFP_KERNEL);
}

void Free(void *p) {
  if (p) kfree(p);
}

kernel_api.h

#ifndef  KERNEL_API_H
#define  KERNEL_API_H

#   ifdef __cplusplus
extern "C" {
#   endif
typedef long unsigned int size_t;


#define KERN_INFO    "<6>"
#define NULL    0UL

extern void printk(const char *fmt, ...);
extern void *Allocate(size_t size);
extern void Free(void *p);

#   ifdef __cplusplus
}
#   endif

#endif //KERNEL_API_H

Makefile

obj-m += mydrv.o
mydrv-objs := interface.o cppmod.o kernel_api.o
list-multi := mydrv.o

all: cppmod.o module
module:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
    make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

cppmod.o : cppmod.cpp local_new.h kernel_api.h cppmod.h
    $(CC) -c -o $@ -fno-builtin -fno-exceptions -fno-rtti -nostdinc -mcmodel=kernel $<

Вроде ничего не забыл...

Так, кстати говоря, и не понял, почему мой вариант не заработал

Здравствуйте, Molchalnik, Вы писали:

M>Так, кстати говоря, и не понял, почему мой вариант не заработал

Так в итоге заработал или нет? Ваш — это который? Без ключей компиляции и со "стандартным" new? Он и не мог.
При компиляции матюги в лог ядра — это сильно! Или это в лог сборки? Так линкер наверное и сказал, что именно ему не понравилось? В целом — там совсем другая управляющая среда, если нужны детали — изучите получившиеся объектники и модуль, где какие секции, какие символы и так далее. Но это — не для слабых духом! И от крестов практически ничего в итоге не остаётся. Вы всё ещё уверены, что оно Вам надо?

Здравствуйте, cures, Вы писали:

C>Здравствуйте, Molchalnik, Вы писали:

M>>Так, кстати говоря, и не понял, почему мой вариант не заработал

C>Так в итоге заработал или нет? Ваш — это который? Без ключей компиляции и со "стандартным" new? Он и не мог.
Мой не заработал в принципе, хотя там просто вызывались пустые c++ функции, ничего не делающие.

Тот, который я привёл тут

Автор: Molchalnik
Дата: 03.06.14

работает


C>При компиляции матюги в лог ядра — это сильно! Или это в лог сборки? Так линкер наверное и сказал, что именно ему не понравилось? В целом — там совсем другая управляющая среда, если нужны детали — изучите получившиеся объектники и модуль, где какие секции, какие символы и так далее. Но это — не для слабых духом!

printk куда пишет? Слабоват я ещё в линухе.

C>При компиляции матюги в лог ядра — это сильно! Или это в лог сборки?
Нет. В том-то и фишка, что скомпилилось нормально, но само ядро написало в лог, спецом для таких, как я, что нужно компилить с этим ключом

Jun 3 13:54:12 localhost kernel: overflow in relocation type 10 val ffffffffa00a4174
Jun 3 13:54:12 localhost kernel: `mydrv' likely not compiled with -mcmodel=kernel

C> И от крестов практически ничего в итоге не остаётся.
???
шаблоны, классы, наследования?
Просто нужно мини-либу создать. например такую, которая будет создавать объект нужного типа

Весь дважды трефовый С++ остаётся, другое дело, что если вам нужен список, вектор, отображение или операции с плавающей запятой — пишите ручками.


C>Вы всё ещё уверены, что оно Вам надо?

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

Зато я получаю шаблоны, фабрики, умные указатели (при необходимости), и улучшенную организацию кода.