为什么 gcc 对于以下重复符号不报告错误？

问题描述 投票：0回答：2

我正在 Ubuntu Linux 上构建 Android 和 Linux 二进制文件。我有一个静态库，它由两个共享库链接，并且静态库中有一个全局对象。

根据我的理解，全局对象将同时存在于

*.so
中，并且会导致问题，因为每个共享库中的函数符号访问不同的全局变量。

（我在构建两个共享库时在命令行中引用了静态库。我一直在使用

-Wl,--whole-archive
和
-Wl,-z,defs
开关。因此共享库包含静态库的符号。）

所以问题是：

  1. 在链接可执行文件时，为什么 GCC/LD 不报告这种情况下的重复符号错误？
  2. 这是否意味着我们永远不会链接到应用程序共享库和可执行文件本身中的同一个静态库？

-----------------编辑1------------------------------------

正如R Soha所说，我们不应该在静态库中拥有状态，或者应该提供共享库。

我认为有这个限制是糟糕和悲伤的：静态库不应该有状态或者应该作为共享库提供。

原因是： 1. 全局变量很常用，比如我的例子，它是一个单例对象。 2. 静态库可能由第三方提供。也许用户还使用另一个第三方提供的共享库，该共享库已经链接了静态库，例如 boost。

c++ linux gcc linker
2个回答
3
投票

经验证据表明共享库行为依赖于平台

这里有一些简单的代码，演示了两个共享库，它们都定义了一个符号（函数）

abc_123()
以及调用同一函数的其他函数，以及一个使用这些函数的测试程序。

lib1.h

#ifndef JLSS_ID_LIB1_H
#define JLSS_ID_LIB1_H

extern void abc_123(int i);
extern void def_345(int i);

#endif

lib2.h

#ifndef JLSS_ID_LIB2_H
#define JLSS_ID_LIB2_H

extern void abc_123(int i);
extern void ghi_678(int i);

#endif

lib1a.c

#include <stdio.h>
#include "lib1.h"

void abc_123(int i)
{
    printf("Library 1:%s:%d:%s() - %d\n", __FILE__, __LINE__, __func__, i);
    printf("Note this extra message\n");
}

lib1b.c

#include <stdio.h>
#include "lib1.h"
#include "lib2.h"

void def_345(int i)
{
    printf("Library 1:%s:%d-->>%s() - %d\n", __FILE__, __LINE__, __func__, i);
    ghi_678(i+10);
    printf("Library 1:%s:%d<<--%s() - %d\n", __FILE__, __LINE__, __func__, i);
}

lib2a.c

#include <stdio.h>
#include "lib2.h"

void abc_123(int i)
{
    printf("Library 2:%s:%d:%s() - %d\n", __FILE__, __LINE__, __func__, i);
    printf("This is a completely different message\n");
}

lib2b.c

#include <stdio.h>
#include "lib2.h"

void ghi_678(int i)
{
    printf("Library 2:%s:%d-->>%s() - %d\n", __FILE__, __LINE__, __func__, i);
    abc_123(i * 10);
    printf("Library 2:%s:%d<<--%s() - %d\n", __FILE__, __LINE__, __func__, i);
}

测试1.c

#include <stdio.h>
#include "lib1.h"
#include "lib2.h"

int main(void)
{
    printf("Cross-library linking and calling\n");
    printf("Main calling abc_123(29)\n");
    abc_123(29);
    printf("Main calling def_345(45)\n");
    def_345(45);
    printf("Main calling ghi_678(57)\n");
    ghi_678(57);
    printf("Demonstration over\n");
    return 0;
}

生成文件

CC     = gcc #/usr/bin/gcc
WFLAG1 = -Wall
WFLAG2 = -Wextra
WFLAG3 = -Wmissing-prototypes
WFLAG4 = -Wstrict-prototypes
WFLAG5 = -Wold-style-definition
WFLAG6 = -Werror
WFLAGS = ${WFLAG1} ${WFLAG2} ${WFLAG3} ${WFLAG4} ${WFLAG5} ${WFLAG6}
SFLAGS = -std=c11
GFLAGS = -g
OFLAGS = -O3
UFLAGS = # Set on command line
IFLAG1 = # -I${HOME}/inc
IFLAGS = # ${IFLAG1}

SOEXT   = dylib
LDFLAG1 = -L.
LDLIB1  = -lrary1
LDLIB2  = -lrary2
LDFLAGS = ${LDFLAG1}
LDLIBS  = ${LDLIB1} ${LDLIB2}

CFLAGS  = ${OFLAGS} ${GFLAGS} ${IFLAGS} ${SFLAGS} ${WFLAGS} ${UFLAGS}

LNKSHLIB = -shared

LIBRARY1 = library1.${SOEXT}
LIBRARY2 = library2.${SOEXT}

LIB1.o  = lib1a.o lib1b.o
LIB2.o  = lib2a.o lib2b.o
TEST1.o = test1.o

PROGRAM = test1

all: ${PROGRAM}

${PROGRAM}: ${TEST1.o} ${LIBRARY1} ${LIBRARY2}
    ${CC} ${CFLAGS} -o $@ ${TEST1.o} ${LDFLAGS} ${LDLIBS}

${LIBRARY1}: ${LIB1.o} ${LIBRARY2}
    ${CC} ${CFLAGS} ${LNKSHLIB} -o $@ ${LIB1.o} ${LDFLAGS} ${LDLIB2}

${LIBRARY2}: ${LIB2.o}
    ${CC} ${CFLAGS} ${LNKSHLIB} -o $@ ${LIB2.o}

在 Linux 上构建并运行

这是来自 Ubuntu 14.04 LTS VM（托管在 Mac OS X 10.9.3 上），编译器是 GCC 4.8.2。

$ make -B SOEXT=so UFLAGS=-fPIC
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -fPIC -c test1.c
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -fPIC -c lib1a.c
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -fPIC -c lib1b.c
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -fPIC -c lib2a.c
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -fPIC -c lib2b.c
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -fPIC -shared -o library2.so lib2a.o lib2b.o
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -fPIC -shared -o library1.so lib1a.o lib1b.o -L. -lrary2
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -fPIC -o test1 test1.o -L. -lrary1 -lrary2
$ LD_LIBRARY_PATH=$PWD:$LD_LIBRARY_PATH ./test1
Cross-library linking and calling
Main calling abc_123(29)
Library 1:lib1a.c:15:abc_123() - 29
Note this extra message
Main calling def_345(45)
Library 1:lib1b.c:17-->>def_345() - 45
Library 2:lib2b.c:15-->>ghi_678() - 55
Library 1:lib1a.c:15:abc_123() - 550
Note this extra message
Library 2:lib2b.c:17<<--ghi_678() - 55
Library 1:lib1b.c:19<<--def_345() - 45
Main calling ghi_678(57)
Library 2:lib2b.c:15-->>ghi_678() - 57
Library 1:lib1a.c:15:abc_123() - 570
Note this extra message
Library 2:lib2b.c:17<<--ghi_678() - 57
Demonstration over
$

请注意，每次都会调用 

abc_123()
中的 
library1.so
，即使调用函数是 
ghi_678()
中的 
library2.so
。

在 Mac OS X 上构建并运行

这是来自带有 GCC 4.9.0 的 Mac OS X 10.9.3。

$ make -B
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -c -o test1.o test1.c
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -c -o lib1a.o lib1a.c
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -c -o lib1b.o lib1b.c
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -c -o lib2a.o lib2a.c
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -c -o lib2b.o lib2b.c
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -shared -o library2.dylib lib2a.o lib2b.o
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -shared -o library1.dylib lib1a.o lib1b.o -L. -lrary2
gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Werror -o test1 test1.o -L. -lrary1 -lrary2
$ ./test1
Cross-library linking and calling
Main calling abc_123(29)
Library 1:lib1a.c:15:abc_123() - 29
Note this extra message
Main calling def_345(45)
Library 1:lib1b.c:17-->>def_345() - 45
Library 2:lib2b.c:15-->>ghi_678() - 55
Library 2:lib2a.c:16:abc_123() - 550
This is a completely different message
Library 2:lib2b.c:17<<--ghi_678() - 55
Library 1:lib1b.c:19<<--def_345() - 45
Main calling ghi_678(57)
Library 2:lib2b.c:15-->>ghi_678() - 57
Library 2:lib2a.c:16:abc_123() - 570
This is a completely different message
Library 2:lib2b.c:17<<--ghi_678() - 57
Demonstration over
$

请注意，

ghi_678()
中的代码从 
abc_123()
调用 
library2.so
，而不是像 Linux 上那样从 
library1.so
调用版本。

您可以尝试反向链接顺序，看看会发生什么。

道德

不要在多个共享库中构建包含相同功能的软件；如果您在平台之间移植，您会感到困惑。

2
投票

你说：

据我了解，全局对象将同时存在于两个 *.so 中，并且会导致问题，因为每个共享库中的函数符号访问不同的全局变量。

这是正确的。第一个 .so 使用的全局变量将与第二个 .so 使用的全局变量不同。

至于你的问题...

当链接可执行文件时，为什么 GCC/LD 在这种情况下不报告重复符号错误？

就可执行文件而言，它只关心.so库的接口。它不关心它们是使用相同的静态库创建的这一事实。

这是否意味着我们永远不会链接到应用程序共享库和可执行文件本身中的同一个静态库？

静态库没有状态也没关系。如果它们有状态，您必须判断状态是否需要在整个应用程序中是全局的，还是仅在共享库中。

如果状态需要在整个应用程序中是全局的，最好创建另一个提供对全局状态的访问的共享库，而不是将其放在静态库中。

如果需要在每个共享库中维护状态，则将其放在静态库中就可以了。即便如此，创建一个提供数据访问的共享库将是一个更好的解决方案。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.