Как заставить слабое связывание работать с GCC?

Я только что изучил это и подумал, что некоторые другие могут быть заинтересованы в моих выводах.

Слабое связывание с weak_import действительно хорошо работает только с динамическими библиотеками. Вы можете заставить его работать со статической компоновкой (указав -undefined dynamic_lookup, как было предложено выше), но это не такая уж горячая идея. Это означает, что неопределенные символы не будут обнаружены до времени выполнения. Это то, чего я бы лично избегал в производственном коде.

Вот сеанс терминала Mac OS X, показывающий, как заставить его работать:

Вот ф.к.

int f(int n)
{
    return n * 7;
}

Вот что.c

#include <stdio.h>
#include <stdlib.h>

extern int f (int) __attribute__((weak_import));

int main() {
    if(f == NULL)
        printf("what, no f?\n");
    else
        printf("f(8) is %d\n", f(8));
    exit(0);
}

Сделать динамическую библиотеку из f.c:

$ cc -dynamiclib -o f.dylib f.c

Скомпилируйте и свяжите с динамической библиотекой, перечислите динамические библиотеки.

$ cc -o whatnof whatnof.c f.dylib
$ otool -L whatnof
whatnof:
       f.dylib (compatibility version 0.0.0, current version 0.0.0)
       /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)

Запустите whatnof, чтобы посмотреть, что произойдет:

$ whatnof
f(8) is 56

Теперь замените f.dylib пустой библиотекой (без символов):

$ mv f.dylib f.dylib.real
$ touch null.c
$ cc -dynamiclib -o f.dylib null.c

Запустите тот же whatnof, чтобы увидеть, что произойдет:

$ whatnof
what, no f?

Основная идея (или «вариант использования») для weak_import заключается в том, что он позволяет вам связываться с набором динамических (общих) библиотек, а затем запускать тот же код с более ранними версиями тех же библиотек. Вы можете проверить функции на NULL, чтобы узнать, поддерживаются ли они в конкретной динамической библиотеке, с которой в данный момент выполняется код. Кажется, это часть базовой модели разработки, поддерживаемой Xcode. Я надеюсь, что этот пример будет полезен; это помогло мне успокоиться об этой части дизайна Xcode.

Добавьте -Wl,-flat_namespace,-undefined,dynamic_lookup в строку компилятора gcc, которую вы используете для окончательной ссылки.

Вам необходимо установить для переменной MACOSX_DEPLOYMENT_TARGET значение 10.2 или более поздней версии. См. документацию Apple и их техническая заметка о слабых связях.

Пример Linux с минимальной работоспособностью

main.c

#include <stdio.h>

int my_weak_var __attribute__((weak)) = 1;

int main(void) {
    printf("%d\n", my_weak_var);
}

notmain.c

int my_weak_var = 2;

Скомпилируйте и запустите оба объекта:

gcc -c -std=c99 -Wall -Wextra -pedantic -o main.o main.c
gcc -c -std=c99 -Wall -Wextra -pedantic -o notmain.o notmain.c
gcc -std=c99 -Wall -Wextra -pedantic -o main.out main.o notmain.o
./main.out

Вывод:

2

Скомпилируйте и запустите без notmain.o:

gcc -std=c99 -Wall -Wextra -pedantic -o main.out main.o
./main.out

Вывод:

1

GitHub upstream.

Итак, мы видим, что если задано notmain.o, то неслабый символ имеет приоритет, как и ожидалось.

Мы можем проанализировать Объектный файл ELF с символами:

nm main.o notmain.o

который дает:

main.o:
                 U _GLOBAL_OFFSET_TABLE_
0000000000000000 T main
0000000000000000 V my_weak_var
                 U printf

notmain.o:
0000000000000000 D my_weak_var

а потом:

man nm

содержит:

Тип символа. По крайней мере, используются следующие типы; другие также зависят от формата объектного файла. В нижнем регистре символ обычно является локальным; если в верхнем регистре, символ является глобальным (внешним). Однако есть несколько символов нижнего регистра, которые показаны для специальных глобальных символов («u», «v» и «w»).

"D"
"d" Символ находится в разделе инициализированных данных.

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

Однако при работе со статическими библиотеками .a вам, возможно, придется использовать -Wl,--whole-archive, как описано по адресу: Как сделать так, чтобы сильный символ ссылки gcc в статической библиотеке перезаписывал слабый символ?

Слабые символы также можно оставить неопределенными, что в Binutils приводит к «зависимому от платформы поведению», см.: Поведение GCC для неразрешенных слабых функций

Протестировано на Ubuntu 18.10, GCC 8.2.0.

Из руководства по документации gcc:

слабый

Слабый атрибут приводит к тому, что объявление выдается как слабый символ, а не как глобальный. Это в первую очередь полезно при определении библиотечных функций, которые можно переопределить в пользовательском коде, хотя его также можно использовать с объявлениями, не являющимися функциями. Слабые символы поддерживаются для целей ELF, а также для целей a.out при использовании ассемблера и компоновщика GNU.

это означает, что объект может перезаписывать слабый символ (определенный в другом объекте/библиотеке) без возникновения ошибок во время компоновки. Неясно, связываете ли вы библиотеку с символом weak или нет. Похоже, что вы не определили символ, и библиотека не подключена должным образом.