3

Let's say we have this source tree:

.
└── src
    ├── foo
    │   ├── common.c
    │   └── foo.c
    └── bar
        ├── common.c
        └── bar.c

And in both src/foo/common.c and src/bar/common.c we have different static variables named common_var in both files, which obviously correspond to different variables.

All files will be compiled into a similar tree in tmp/ (including tmp/foo/common.s & tmp/bar/common.s), later assembled into object files (including tmp/foo/common.o & tmp/bar/common.o), and all those object files will go into lib/libfoobar.a which will be used by some program.

Ending with this file tree:

.
├── lib
│   └── libfoobar.a
├── src
│   ├── foo
│   │   ├── common.c
│   │   └── foo.c
│   └── bar
│       ├── common.h
│       └── bar.hpp
└── tmp
    ├── foo
    │   ├── common.o
    │   ├── common.s
    │   ├── foo.o
    │   └── foo.s
    └── bar
        ├── common.o
        ├── common.s
        ├── bar.o
        └── bar.s

Is it OK, or will there be compiler/linker/any problems?

Related: Static library having object files with same name (ar)

The difference here is that contents may clash.

1 Answers1

2

Global static variables have internal linkage, so there is no way for them to be treated as the same even if there is no difference in names, mangled or otherwise.

There will be no conflict.

rtpax
  • 1,687
  • 1
  • 18
  • 32
  • 1
    There will be problems if the static library is updated incrementally. Since `ar` doesn't store paths, `ar r` will replace any existing `bar.o` or `common.o` regardless of them being from `tmp/foo/` or `tmp/bar/`. – bit2shift May 08 '19 at 18:19