Global variables and shared libraries

[Stephan Bergmann]

On 11/28/2012 03:09 PM, Bharath Ramesh wrote:
> On Wed, Nov 28, 2012 at 11:53:18AM +0530, Siddhesh Poyarekar wrote:
>> On 28 November 2012 11:11, Bharath Ramesh <bramesh@vt.edu> wrote:
>>> I want to export a global variable that has been defined in a
>>> shared library to the binary that links with it. The most common
>>> approach would be to declare the global variable as an extern
>>> variable in the application code. This approach would make the
>>> actual reference to the global variable be present in the data
>>> segment of the binary. My use case would require that the
>>
>> No it wouldn't, unless the binary is statically linked.  It comes up
>> as an undefined symbol in the binary and it is resolved at runtime by
>> the dynamic linker.  You can see this by doing an `objdump -x` on the
>> generated binary.  The global variable is defined in the data section
>> of the DSO binary.
>
> I am then definitely doing something wrong. I am attaching two
> simple test files and compile them as follows.
>
> libfoo:
> gcc -g -Wall -Wextra -O3 -fPIC -c foo.c
> gcc -g -Wall -Wextra -O3 -shared -Wl,-soname,libfoo.so -o libfoo.so foo.o
>
> test:
> gcc -g -Wall -Wextra -O3 -o test test.c -Wl,-rpath . -L . -lfoo
>
> Now, if I run "nm" on test I get the following
>
> $ nm ./test | grep foo
> 0000000000601028 B foo
>
> Which indicates foo is in the data segment of the binary. The
> output of the test reflects the same.

Isn't that because the executable does not have relocations, so needs 
the address of a var it is referencing to be fixed at link time, and 
that the runtime loader does something special in that case?  I think 
"Linkers & Loaders" covers that general problem, but my understanding 
may well be rusty.

Stephan