英文:

extern global variable issue only in CentOS/RHEL 7

问题

I'm trying to debug a troublesome issue. I have a program that is compiled with g++, and it makes use of a global struct that contains some config information.

In most linux/unix environments where this runs, it works fine. But in CentOS/RHEL 7 environments, it looks like we have two different instances of what is supposed to be a global variable. (Note, I'm using generic variable names here)

That global struct is defined with extern in a header file, this way...
extern struct collect_config configstruct;

and it is initialized in the file with the main function, this way...
struct collect_config configstruct = {{0}};

Here I'm printing out the pointer address of this global struct in the file where the main function is, and inside a function that is populating the config information. The pointer address is different within this function, as opposed to what it is out with the main function.

my_config A:952 configstruct address is 0x6c8400
my_config B:957 configstruct address is 0x6c8400
main B:3421 configstruct address is 0x6c8460 ```

In any other linux/unix environment, these addresses are the same... (this was taken from a run in Ubuntu 20)
``` main A:3417 configstruct address is 0x6bb500
my_config A:952 configstruct address is 0x6bb500
my_config B:957 configstruct address is 0x6bb500
main B:3421 configstruct address is 0x6bb500 ```

I do not see any other places where configstruct is declared/defined.

Any suggestions on what I can look at to try and find out why I'm ending up with two different pointer addresses for what is supposed to be a global variable? (And why this seems to be a problem only in CentOS/RHEL?) Thanks.

<details>
<summary>英文:</summary>

I&#39;m trying to debug a troublesome issue. I have a program that is compiled with g++, and it makes use of a global struct that contains some config information.

In most linux/unix environments where this runs, it works fine. But in CentOS/RHEL 7 environments, it looks like we have two different instances of what is supposed to be a global variable. (Note, I&#39;m using generic variable names here)

That global struct is defined with extern in a header file, this way...

extern struct collect_config configstruct;

and it is initialized in the file with the main function, this way...

struct collect_config configstruct = {{0}};

Here I'm printing out the pointer address of this global struct in the file where the main function is, and inside a function that is populating the config information. The pointer address is different within this function, as opposed to what it is out with the main function.

main A:3417 configstruct address is 0x6c8460
my_config A:952 configstruct address is 0x6c8400
my_config B:957 configstruct address is 0x6c8400
main B:3421 configstruct address is 0x6c8460

In any other linux/unix environment, these addresses are the same... (this was taken from a run in Ubuntu 20)

main A:3417 configstruct address is 0x6bb500
my_config A:952 configstruct address is 0x6bb500
my_config B:957 configstruct address is 0x6bb500
main B:3421 configstruct address is 0x6bb500

I do not see any other places where configstruct is declared/defined.

Any suggestions on what I can look at to try and find out why I'm ending up with two different pointer addresses for what is supposed to be a global variable? (And why this seems to be a problem only in CentOS/RHEL?) Thanks.

</details>


# 答案1
**得分**: 2

这个问题很可能是由于符号可见性引起的，它控制了同一可执行文件和共享库中符号的作用范围。在C++中，符号默认情况下是隐藏的，这意味着它们只能在它们所定义的模块（即翻译单元）内访问。你遇到的问题可能是因为在不同的环境中使用不同的可见性标志编译了你的程序，导致相同的符号在一个环境中被定义为隐藏的，而在另一个环境中被定义为全局的。

尝试使用 `-fvisibility=default` 标志编译你的程序。这个标志将符号的可见性设置为默认，使它们在全局范围内可访问。如果这解决了问题，那就意味着符号可见性确实是根本原因。

<details>
<summary>英文:</summary>

This issue is likely due to symbol visibility, which controls the scope of symbols within the same executable and shared libraries. In C++, symbols are by default hidden, which means they can only be accessed within the same module (i.e. translation unit) they are defined in. The issue you&#39;re encountering could be because your program is compiled with different visibility flags in different environments, leading to the same symbol being defined as hidden in one environment and as global in another.

Try compiling your program with the -fvisibility=default flag. This flag sets the visibility of symbols to default, which makes them globally accessible. If this resolves the issue, it means that symbol visibility was indeed the root cause.

</details>