[C/C++] линковка траблз

erotic

Объясните пожалуйста, согласуется ли это с какими-либо общечеловеческими нормами, или ошибка линкера?
Есть библиотека с двумя функциями и один файл с реализацией этих функций:
lib.h
 #ifndef __LIB_H__



int func;

int func_with_external_use;



#endif

lib.c
 #include "lib.h"

#include <uuid/uuid.h>



int func

{

    return 5;

}



int func_with_external_use

{

    uuid_t u;

    uuid_generate(u);

    return 10;

}

Тут uuid_generate находится во внешней библиотеке libuuid, но это не играет особой роли - главное, что вызывается функция из другой библиотеки.
Собрал статически библиотеку, теперь собираю программу:
main.c:
 #include "lib.h"

#include <stdio.h>



int main

{

    printf("%d\n", func;

    return 0;

}

Поскольку я использую только функцию func, я надеюсь, что мне достаточно слинковать программу только с моей liblib.a. Но

gcc --version
gcc (Gentoo 4.3.4 p1.0, pie-10.1.5) 4.3.4
make
[ 50%] Building C object CMakeFiles/lib.dir/lib.c.o
Linking C static library liblib.a
[ 50%] Built target lib
[100%] Building C object CMakeFiles/main.dir/main.c.o
Linking C executable main
liblib.a(lib.c.o): In function `func_with_external_use':
lib.c:(.text+0x18): undefined reference to `uuid_generate'
collect2: выполнение ld завершилось с кодом возврата 1
make[2]: *** [main] Ошибка 1
make[1]: *** [CMakeFiles/main.dir/all] Ошибка 2
make: *** [all] Ошибка 2

Т.е. линкер пытается найти зависимости для неиспользуемой функции, которая оказалось в том же модуле трансляции, что и действительно используемая функция.
Является ли это поведение правильным для линкера?
Ведь если переместить код func_with_external_use в другой объектный файл и собрать ту же библиотеку, то проблемы не будет.
В случае сборки шареной библиотеки не собирается ни в какой комбинации, это тоже меня удивляет.
Та же фигня в gcc 4.1.2, в студии пока не пробовал собирать.

Ivan8209

> линкер пытается найти зависимости для неиспользуемой функции,
> которая оказалось в том же модуле трансляции, что и
> действительно используемая функция.
> Является ли это поведение правильным для линкера?
Да. Он знает только то, что ему надо подправить такое-то место
в двоичном коде, а используется ли соответствующий код или нет,
определить уже невозможно.
> Ведь если переместить код func_with_external_use в другой
> объектный файл и собрать ту же библиотеку, то проблемы не будет.
Так и надо делать.
---
"Vyroba umelych lidi, slecno, je tovarni tajemstvi."

Maurog

линковка делается целыми translation unit-ами. то есть если часть объектника (*.obj) заюзалась, то весь объектник залезет в бинарь (и потянет что-то другое)
это по дефолту делается и в студии и в gcc
для предотвращения этого эффекта
1) режут .cpp на части
2) используют магический ключик для линкера (скорее всего такая оптимизация есть для линкеров, но она не дешевая в плане производительности и я не знаю ключик)
есть еще ключик (в gcc точно чтобы при линковке с lib брались в бинарь _все_ obj из этой либины. такой гремучий бинарь получается

erotic

а используется ли соответствующий код или нет,
определить уже невозможно
Мне проще согласиться с 'ом, что это возможно, но дорого. Потому что я не понимаю, почему это может быть невозможно. Есть точка входа в программу, можно раскрутить всевозможные вызовы и составить точный их список.
Однако, спасибо за ответ. Придется разделять. Странно, я думал линкеры по умолчанию умнее.

Ivan8209

> Мне проще согласиться с 'ом,
Он написал то же самое, только другими словами.
> что это возможно, но дорого.
Ну, если ты сможешь правильно порезать секцию, то вперёд.
Кстати, если настолько не хочется резать файлы, тогда подсунь
файл, определяющий недостающие символы:


int uuid_generate;

---
"Narrowness of experience leads to narrowness of imagination."

Serab

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


registration.h:

void register( void (*f const char* name );

void callByName( const char* name );



registration.cpp:



// implement register and callByName using map or something



Registrar.h:

#include "registration.h"



class Registrar {

public:

  Registrar( void (*f const char* name ) {

    register( f, name );

  }

};



aux.cpp:



void g { ... }



Registrar g_registrar( g, "A cool func" );



main.cpp



#include "registration.h"



int main

{

  call_by_name( "A cool func" );

}

Понятно, что пример не минимальный (хотя и отброшены для простоты #pragma once ваш любимый способ защититься от повторного включения заголовков просто с подобным недавно сталкивались :grin:
тут очень надо, чтобы aux.o обязательно-обязательно был влинкован, иначе что-то не заработает.
Ведь в C++ большинство мыслей типа «а забацаем-ка мы вот такой крутой статический анализ кода» обламывается именно из-за того, что можно спрятать указатель в заднем кармане.

erotic

тут очень надо, чтобы aux.o обязательно-обязательно был влинкован, иначе что-то не заработает.
А какие есть поводы его отбросить? В нем объявляется переменная и вызывается ее конструктор,
Хотя это тоже для меня загадка, все ли глобальные переменные из разных модулей подключаются или может быть так, что линкер решит модуль не использовать, и переменная не будет создана. Наверное это где-то четко описано, но я не знаю.

Serab

А какие есть поводы его отбросить? В нем объявляется переменная и вызывается ее конструктор,
отбрасывал ld, иначе бы этой истории и не было.
Но сейчас подумал, действительно, пожалуй это бага (отрубание конструктора влияет на семантику надо зачекать в новых версиях.

procenkotanya

Забавно, что нужная функциональность уже есть: -ffunction-sections в gcc и --gc-sections в ld. В студийном компиляторе, вроде бы, есть аналог.

erotic

Что-то я почитал, они, по-моему, только засоряют все дело ) Ну т.е. первая распухает файл, как написано, а вторая чистит неиспользуемые секции, но каждая секция - это ведь оверхед, не так ли? Т.е. каждая функция в своей секции будет вообще дикий оверхед, наверное.
Вообще, надо попробовать, какой профит в зависимости от соотношения используемых/неиспользуемых функций в либе. Есть такая статистика?

procenkotanya

Финальная линковка сливает все секции, оверхед наблюдается только во время билда

erotic

Круто, спасибо.
Оставить комментарий
Имя или ник:
Комментарий: