Компоновщик GCC игнорирует символы в библиотеке .a, которые, как я подтвердил, присутствуют

После некоторого обсуждения в чате мы обнаружили, что проблема заключается в «общих» определениях. Далее следует упрощенная версия кода, вызывающего проблемы. Система Mac OS X (Mavericks и Yosemite).

Только с общими определениями

vars.h

extern int    chorebox_argc;
extern char **chorebox_argv;
extern char **chorebox_envp;

vars.c

#include "vars.h"
int    chorebox_argc;
char **chorebox_argv;
char **chorebox_envp;

main.c

#include "vars.h"

int main(int argc, char **argv, char **envp)
{
    chorebox_argc = argc;
    chorebox_argv = argv;
    chorebox_envp = envp;
    return argc;
}

Сборник 1

$ gcc -c vars.c
$ nm vars.o
0000000000000004 C _chorebox_argc
0000000000000008 C _chorebox_argv
0000000000000008 C _chorebox_envp
$ ar rv libvars.a vars.o
ar: creating archive libvars.a
a - vars.o
$ ranlib libvars.a
warning: ranlib: warning for library: libvars.a the table of contents is
empty (no object file members in the library define global symbols)
$ gcc -c main.c
$ gcc -o program main.o vars.o
$ gcc -o program main.o -L. -lvars
Undefined symbols for architecture x86_64:
  "_chorebox_argc", referenced from:
      _main in main.o
  "_chorebox_argv", referenced from:
      _main in main.o
  "_chorebox_envp", referenced from:
      _main in main.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
$

Обратите внимание на C в выводе nm. Это указывает на «общее» определение переменных. Недостаточно просто превратить их в определения переменных — обратите внимание на сообщение от ranlib.

Я не уверен, что это новое поведение в Mac OS X или нет. Однако кажется, что наличие исходного файла, который определяет только неинициализированные переменные, недостаточно, когда переменные определены в библиотеке, хотя этого достаточно, когда объектный файл связан напрямую.

С определениями переменных

vardefs.c

#include "vars.h"
int    chorebox_argc = 0;
char **chorebox_argv = 0;
char **chorebox_envp = 0;

Это явно инициализировало версии переменных. Значения инициализатора такие же, как значения по умолчанию, но явная инициализация имеет большое значение.

Сборник 2

$ rm libvars.a
$ gcc -c vardefs.c
$ ar rv libvars.a vardefs.o
ar: creating archive libvars.a
a - vardefs.o
$ gcc -o program main.o -L. -lvars
$ 

Явно инициализированные переменные без проблем берутся из библиотеки.

С одним определением переменной

vars.h

extern int    chorebox_argc;
extern char **chorebox_argv;
extern char **chorebox_envp;
extern int make_believe;

vars.c

#include "vars.h"
int    chorebox_argc;
char **chorebox_argv;
char **chorebox_envp;

int make_believe = 59;

main.c

#include "vars.h"

int main(int argc, char **argv, char **envp)
{
    chorebox_argc = argc;
    chorebox_argv = argv;
    chorebox_envp = envp;
    make_believe  = 1;
    return argc;
}

Сборник 3

$ gcc -c vars.c
$ ar rv libvars.a vars.o
ar: creating archive libvars.a
a - vars.o
$ nm vars.o
0000000000000004 C _chorebox_argc
0000000000000008 C _chorebox_argv
0000000000000008 C _chorebox_envp
0000000000000000 D _make_believe
$ gcc -c main.c
$ gcc -o program main.o -L. -lvars
$ 

Обратите внимание, что добавления инициализированного make_believe достаточно, чтобы извлечь объектный файл из библиотеки, а общих определений для других переменных будет достаточно, чтобы удовлетворить компоновщика.

Уроки

Хотя порядок связывания был частью проблемы, это не была вся проблема.

Предоставление неинициализированных глобальных переменных в библиотеке не всегда работает, особенно если в том же исходном файле нет других определений.

Как я уже отмечал в чате, обычно не рекомендуется предоставлять прямой доступ к глобальным переменным. Было бы лучше предоставить функциональные интерфейсы для доступа (получения и установки) переменных.

Поместите параметр -l после файла, которому он нужен (ofiles/main.o)

См. этот вопрос для получения дополнительной информации о порядке ссылок.