|
Варнинг компоновщика, Что это может означать? |
|
|
|
Jan 23 2007, 18:02
|
Местный
  
Группа: Свой
Сообщений: 235
Регистрация: 9-02-05
Пользователь №: 2 526

|
Цитата(boez @ Jan 23 2007, 17:57)  Странно, всегда последнее время так делал и никто не ругался... По крайней мере на С. На С++ наверное такого делать нельзя - но я и не пробовал... А главное - непонятно почему линкер, а не компилятор. Какой компилятор и линкер используются? да компиллятору то и не на что ругаться. Именно компоновщик не может привести типы. IAR 4.20A
|
|
|
|
|
Jan 23 2007, 18:14
|
Местный
  
Группа: Свой
Сообщений: 235
Регистрация: 9-02-05
Пользователь №: 2 526

|
Цитата(IgorKossak @ Jan 23 2007, 18:03)  Не забыли охранник поставить в файле menu.h? Код #ifndef _MENU_H_ #define _MENU_H_ ... #endif нет, не забыл. да если бы забыл, то ругался бы компиллятор - "редекларация"
|
|
|
|
|
Jan 23 2007, 18:23
|

Гуру
     
Группа: Свой
Сообщений: 2 720
Регистрация: 24-03-05
Пользователь №: 3 659

|
Цитата(Sergio66 @ Jan 23 2007, 21:31)  Есть такое определение: typedef __flash struct {...} item_struct_type; оно находится в h файле далее идут определения переменных в файле menu.c
item_struct_type Main_menu[NUMBER] = {инициализация}; и item_struct_type *current_menu = Main_menu;
есть файл menu.h со следующими строками: extern item_struct_type Main_menu[NUMBER] ; и extern item_struct_type *current_menu; А зачем extern item_struct_type *current_menu;??? зачем определять указатель, если каждому юниту извесно про extern item_struct_type Main_menu[NUMBER] ;??? Каждый юнит когда угодно может взять и создать указатель на массив... не из-за этого ли варнинги? К тому же подозрительно выглядит присвоение в хедере...
--------------------
|
|
|
|
|
Jan 23 2007, 18:25
|

Дух погибшего транзистора
   
Группа: Свой
Сообщений: 877
Регистрация: 6-09-05
Из: Москва
Пользователь №: 8 288

|
Есть мыстль что в модуль mulidisplay и в модуль multimenu на самом деле включаются 2 разных файла h с описанием переменных. может буковку какую не поставили и или наоборот поставили. Убедитесь что файл menuh и декларации extern единственные, через goto definition в IARе. и это Код typedef __flash struct [b]item_struct[/b] { unsigned int *var_pointer; unsigned char position; unsigned char flags; char left; char right; char up; char down; void (*relative_func)(); } item_struct_type;
--------------------
Yes, there are two paths you can go by But in the long run Theres still time to change the road youre on.
|
|
|
|
|
Jan 23 2007, 18:32
|
Местный
  
Группа: Свой
Сообщений: 235
Регистрация: 9-02-05
Пользователь №: 2 526

|
Цитата(prottoss @ Jan 23 2007, 18:23)  Цитата(Sergio66 @ Jan 23 2007, 21:31)  Есть такое определение: typedef __flash struct {...} item_struct_type; оно находится в h файле далее идут определения переменных в файле menu.c
item_struct_type Main_menu[NUMBER] = {инициализация}; и item_struct_type *current_menu = Main_menu;
есть файл menu.h со следующими строками: extern item_struct_type Main_menu[NUMBER] ; и extern item_struct_type *current_menu; А зачем extern item_struct_type *current_menu;??? зачем определять указатель, если каждому юниту извесно про extern item_struct_type Main_menu[NUMBER] ;??? Каждый юнит когда угодно может взять и создать указатель на массив... не из-за этого ли варнинги? К тому же подозрительно выглядит присвоение в хедере... Есть 2 массива меню (2 меню) и программа работает только с активным в данный момент. А указатель на активный массив сторок и описателей меню передается именно через присвоение указателю нужного значения. А присвоение происходит не в недере, а в с файле.
|
|
|
|
|
Jan 23 2007, 18:38
|
Частый гость
 
Группа: Новичок
Сообщений: 79
Регистрация: 1-11-06
Пользователь №: 21 868

|
Цитата(Sergio66 @ Jan 23 2007, 17:02)  да компиллятору то и не на что ругаться. Именно компоновщик не может привести типы. IAR 4.20A С каких пор компоновщики стали понимать типы? ИМХО для каждого объекта он должен знать секцию, адрес, размер и выравнивание... Ну может еще что-то, но типы? Или я отстал от жизни? В конце концов попробуйте то же самое собрать gcc. Цитата(prottoss @ Jan 23 2007, 17:23)  Цитата(Sergio66 @ Jan 23 2007, 21:31)  Есть такое определение:
далее идут определения переменных в файле menu.c (!!!)
item_struct_type Main_menu[NUMBER] = {инициализация};
есть файл menu.h со следующими строками: extern item_struct_type Main_menu[NUMBER] ; А зачем extern item_struct_type *current_menu;??? зачем определять указатель, если каждому юниту извесно про extern item_struct_type Main_menu[NUMBER] ;??? Каждый юнит когда угодно может взять и создать указатель на массив... не из-за этого ли варнинги? К тому же подозрительно выглядит присвоение в хедере... Читайте внимательнее - в хидере только typedef и extern декларация. Настоящая декларация и инициализация в .c файле. Повторяю, у меня на gcc такое прокатывает на ура.
|
|
|
|
|
Jan 23 2007, 18:41
|
Местный
  
Группа: Свой
Сообщений: 235
Регистрация: 9-02-05
Пользователь №: 2 526

|
Цитата(boez @ Jan 23 2007, 18:38)  Цитата(Sergio66 @ Jan 23 2007, 17:02)  да компиллятору то и не на что ругаться. Именно компоновщик не может привести типы. IAR 4.20A
С каких пор компоновщики стали понимать типы? ИМХО для каждого объекта он должен знать секцию, адрес, размер и выравнивание... Ну может еще что-то, но типы? Или я отстал от жизни? В конце концов попробуйте то же самое собрать gcc. Цитата(prottoss @ Jan 23 2007, 17:23)  Цитата(Sergio66 @ Jan 23 2007, 21:31)  Есть такое определение:
далее идут определения переменных в файле menu.c (!!!)
item_struct_type Main_menu[NUMBER] = {инициализация};
есть файл menu.h со следующими строками: extern item_struct_type Main_menu[NUMBER] ; А зачем extern item_struct_type *current_menu;??? зачем определять указатель, если каждому юниту извесно про extern item_struct_type Main_menu[NUMBER] ;??? Каждый юнит когда угодно может взять и создать указатель на массив... не из-за этого ли варнинги? К тому же подозрительно выглядит присвоение в хедере... Читайте внимательнее - в хидере только typedef и extern декларация. Настоящая декларация и инициализация в .c файле. Повторяю, у меня на gcc такое прокатывает на ура. Вот то то и странно! У меня еще много деклараций и определений подобного типа. Ругается только на эти 2.
|
|
|
|
|
Jan 23 2007, 18:58
|
Частый гость
 
Группа: Новичок
Сообщений: 79
Регистрация: 1-11-06
Пользователь №: 21 868

|
Цитата(Sergio66 @ Jan 23 2007, 17:41)  Вот то то и странно! У меня еще много деклараций и определений подобного типа. Ругается только на эти 2. Ну это уже лучше. Ищите различия  Возможно путем написания и компиляции промежуточных вариантов между рабочим и нерабочим. Кстати, слово const слову _flash не мешает. Где-то в соседней ветке рекомендовалось его писать тоже, тогда вкинув в начало #define _flash можно собрать эти же вещи под gcc.
|
|
|
|
|
Jan 24 2007, 09:33
|

Adept
     
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343

|
Цитата(boez @ Jan 23 2007, 21:38)  Цитата(Sergio66 @ Jan 23 2007, 17:02)  да компиллятору то и не на что ругаться. Именно компоновщик не может привести типы. IAR 4.20A
С каких пор компоновщики стали понимать типы? Со времен С++. Цитата(Sergio66 @ Jan 23 2007, 20:31)  Есть такое определение: typedef __flash struct { unsigned int *var_pointer; unsigned char position; unsigned char flags; char left; char right; char up; char down; void (*relative_func)(); } item_struct_type; оно находится в h файле далее идут определения переменных в файле menu.c
item_struct_type Main_menu[NUMBER] = {инициализация}; и item_struct_type *current_menu = Main_menu; Попробуйте такой вариант: Код struct item_struct_type { unsigned int *var_pointer; unsigned char position; unsigned char flags; char left; char right; char up; char down; void (*relative_func)(); }; Хотя судя по тексту диагностики, дело не в этом.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|