Problemas ao vincular várias bibliotecas com os mesmos símbolos

Primeiro, uma ilustração mínima do seu problema. Para mantê-lo mínimo, vou cortar as funções ambivalentes de f1(), f2()para apenas f1(). Já que você diz:

Gostaria de entender a causa raiz do problema?

Vou explicar isso usando a ilustração mínima. Depois, vou mostrar como evitar isso sem um script de versão.

O exemplo

Arquivos de origem e de cabeçalho para libA.so:

// A.h
#pragma once
extern void funcA(void);

// A.c
#include <stdio.h>
#include "A1.h"

void funcA(void)
{
    puts(__FUNCTION__);
    f1();
}
    
// A1.h
#pragma once
extern void f1(void);

// A1.c
#include <stdio.h>
#include "A1.h"

void f1(void)
{
    printf("%s from A1.c\n",__FUNCTION__);
}

Arquivos de origem e de cabeçalho para libB.so:

// B.h
#pragma once
extern void funcB(void);

// B.c
#include <stdio.h>
#include "B1.h"

void funcB(void)
{
    puts(__FUNCTION__);
    f1();
}
    
// B1.h
#pragma once
extern void f1(void);

// B1.c
#include <stdio.h>
#include "B1.h"

void f1(void)
{
    printf("%s from B1.c\n",__FUNCTION__);
}

Fonte para um programa:

// prog.c
#include <A.h>
#include <B.h>

int main(void)
{
    funcA();
    funcB();
    return 0;
}

Compilar todas as fontes da biblioteca compartilhada:

$ gcc -c -fPIC A*.c B*.c

E a fonte do programa:

$ gcc -c -I . prog.c

Vincule as bibliotecas compartilhadas:

$ gcc -shared -o libA.so A*.o 
$ gcc -shared -o libB.so B*.o

E o programa:

$ gcc -o prog prog.o -L . -lA -lB -Wl,-rpath=$(pwd)

Então vemos seu problema:

$ ./prog
funcA
f1 from A1.c
funcB
f1 from A1.c

Ambos funcAe funcBambos chamam o f1from libA.so, definido em A1.c.

Ao vincular novamente o programa, com libA.soe libA.sona ordem inversa:

$ gcc -o prog prog.o -L . -lB -lA -Wl,-rpath=$(pwd)

podemos produzir o problema oposto:

$ ./prog
funcA
f1 from B1.c
funcB
f1 from B1.c

O que não deixa de ser um problema.

A explicação

O símbolo da função ambivalente f1é definido nas tabelas de símbolos dinâmicos de libA.soe libB.so:

$ readelf -W --dyn-syms libA.so

Symbol table '.dynsym' contains 9 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTable
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND puts@GLIBC_2.2.5 (2)
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.2.5 (2)
     4: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     5: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
     6: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@GLIBC_2.2.5 (2)
     7: 0000000000001182    31 FUNC    GLOBAL DEFAULT   14 funcA
     8: 0000000000001159    41 FUNC    GLOBAL DEFAULT   14 f1
     
$ readelf -W --dyn-syms libB.so

Symbol table '.dynsym' contains 9 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTable
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND puts@GLIBC_2.2.5 (2)
     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.2.5 (2)
     4: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     5: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
     6: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@GLIBC_2.2.5 (2)
     7: 0000000000001159    41 FUNC    GLOBAL DEFAULT   14 f1
     8: 0000000000001182    31 FUNC    GLOBAL DEFAULT   14 funcB
     

Portanto, em ambas as bibliotecas compartilhadas, ele fica visível no tempo de execução para o vinculador dinâmico como uma definição elegível para referências a f1, e o vinculador dinâmico vinculará, por padrão, todas essas referências à primeira definição que encontrar durante o carregamento e a vinculação das bibliotecas compartilhadas recursivamente exigidas pelo processo em construção.

Para executar prog, essa construção começa com o carregamento do executável prog. Observe o topo de sua seção dinâmica:

$ readelf --dynamic prog

Dynamic section at offset 0x2d90 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libB.so]
 0x0000000000000001 (NEEDED)             Shared library: [libA.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [/home/imk/develop/so/scrap]
 ...[cut]...
 

Essas são informações que o vinculador estático escreveu lá para o vinculador dinâmico ler e agir. O executável precisa carregar libB.soe libA.so, nessa ordem. O RUNPATH /home/imk/develop/so/scrap é um diretório que o vinculador de tempo de execução pode pesquisar para encontrar as bibliotecas compartilhadas necessárias (além de seus diretórios de pesquisa padrão). Esse é o resultado do -rpath=$(pwd)que adicionei ao vínculo do programa (porque não vou me incomodar em instalar corretamente essas bibliotecas descartáveis).

Então, neste caso, a primeira biblioteca compartilhada carregada na qual o vinculador dinâmico encontra uma definição para f1será libB.so; essa é a definição de B1.c, e ele vinculará todas as referências no programa a essa definição.

Vamos voltar à ligação original de prog:

$ gcc -o prog prog.o -L . -lA -lB -Wl,-rpath=$(pwd)

Então, como você adivinhou, o topo da seção dinâmica do prog mostrará:

$ readelf --dynamic prog

Dynamic section at offset 0x2d90 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libA.so]
 0x0000000000000001 (NEEDED)             Shared library: [libB.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [/home/imk/develop/so/scrap]
 ...[cut]...
 

com libA.socarregado antes libB.so, e libAa definição de f1será a que vencerá, como vimos.

A correção

Seu problema surge do comportamento padrão do vinculador estático ao criar uma biblioteca compartilhada: referências dentro da biblioteca compartilhada para símbolos dinâmicos que ela define não são vinculadas preventivamente à definição interna ¹ . Há uma opção de vinculador que substituirá o comportamento padrão para fazer com que cada biblioteca chame sua própria definição de f1. De man ld( ldé o vinculador estático, invocado em seu nome por gccpara executar vinculações):

-Bsimbólico

Ao criar uma biblioteca compartilhada, vincule referências a símbolos globais à definição dentro da biblioteca compartilhada, se houver. Normalmente, é possível para um programa vinculado a uma biblioteca compartilhada substituir a definição dentro da biblioteca compartilhada. Esta opção só é significativa em plataformas ELF que suportam bibliotecas compartilhadas.

Então podemos revincular as bibliotecas compartilhadas assim:

$ gcc -shared -o libA.so A*.o -Wl,-Bsymbolic
$ gcc -shared -o libB.so B*.o -Wl,-Bsymbolic

(Aliás, costumamos -Wl,<ld-option>dizer gccpara passar a opção ld-optiondiretamente para ld.)

Revincule o programa com as novas bibliotecas:

$ gcc -o prog prog.o -L . -lA -lB -Wl,-rpath=$(pwd)

e então cada biblioteca chama sua própria definição de f1:

$ ./prog
funcA
f1 from A1.c
funcB
f1 from B1.c

Você provavelmente também poderia resolver o problema usando o atributo de visibilidade dinâmica do GCC , mas isso exigiria algumas modificações na fonte das bibliotecas.

1. Esse comportamento do vinculador GNU com bibliotecas compartilhadas é intencional: é o mesmo que aconteceria se as bibliotecas fossem estáticas, em consonância com os esforços do vinculador GNU para fazer com que a resolução de símbolos seja semelhante tanto para arquivos estáticos quanto para bibliotecas compartilhadas.