Skip to content

Clang++ ignores visibility attribute for namespace of forward-declared symbol #170963

@stuarthayhurst

Description

@stuarthayhurst

clang++ seems to be ignoring "default" visibility of symbols that have their visibility specified by a namespace in a header. Originally, I was swapping my hobby graphics engine over to -fvisibility=hidden, so I started specifying the symbol visibility by setting the visibility for an entire namespace in the header they're exposed by. Setting the visibility for a whole namespace in a header seems to be ignored, but setting the visibility on every symbol in the header is respected. Setting the visibility of the namespace where the symbol is actually defined also works as expected, it's only namespace visibility for headers that's not working.

I stripped it down to a MWE, tested with clang 19, 21 and 22-git.

main.cpp:

#include "testSpace.hpp"

int main() {
  return testSpace::run();
}

testSpace.hpp:

namespace __attribute__((visibility("default"))) testSpace {
  int run();
}

testSpace.cpp:

#include "testSpace.hpp"

namespace testSpace {
  int run() {
    return 1;
  }
}

Compiling with:

comp=clang++
$comp -fvisibility=hidden -c testSpace.cpp
$comp -fvisibility=hidden -c main.cpp
$comp -shared -o testSpace.so testSpace.o -fvisibility=hidden
$comp -o main main.o testSpace.so

Gives me:

/usr/bin/ld: main.o: in function `main':
main.cpp:(.text+0x10): undefined reference to `testSpace::run()'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

When comp is g++-15, it compiles and runs as expected.

Also, __has_cpp_attribute(visibility) seems to evaluate to false, but __has_cpp_attribute(gnu::visibility) evaluates to true. Is this expected / related? I ran into this in the larger project, but it may well be expected since it's an extension.

Metadata

Metadata

Assignees

No one assigned

    Labels

    clangClang issues not falling into any other category

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions