Compilation Error with GCC Due to vprintf Definition Collision in libc

Hello,

I encountered a compilation error when trying to compile libc with GCC. The error message is as follows:

error: ‘int __llvm_libc_19_0_0_git::vprintf(const char*, __va_list_tag*)’ aliased to external symbol ‘vprintf’

Upon inspecting the preprocessor output, it appears that there is a collision between the definition of vprintf in the installed stdio.h and its definition in libc. For instance, this collision occurs with the following code in glibc:

extern __inline __attribute__ ((__gnu_inline__)) int
vprintf (const char *__restrict __fmt, __gnuc_va_list __arg)
{
  return vfprintf (stdout, __fmt, __arg);
}

Commenting out the above code block prevents the compilation error. I’m curious about why this collision causes an error and how I might resolve it. Could it be related to the way GCC handles inline functions and symbol aliasing?

Any guidance or suggestions on how to address this issue would be greatly appreciated.

  • Build Environment
    • OS: Arch Linux
    • GCC Version: 13.2.1
    • glibc Version: 2.39

Thank you for your time and help.

If this is a Release build in overlay mode it could be __llvm_libc::bsearch() aliased to external symbol 'bsearch' · Issue #60481 · llvm/llvm-project · GitHub. The only workaround seems to be building in debug mode or doing the full build.

@michaelrj-google I think you are involved in the libc. Has the situation here changed since the issue was last updated?

Also it would be cool if Compiler Support — The LLVM C Library noted what modes are supported for GCC, and if there was a code owners file in llvm-project/libc at main · llvm/llvm-project · GitHub so we’d know who to ping about these things.

1 Like

Yeah, this bug is __llvm_libc::bsearch() aliased to external symbol 'bsearch' · Issue #60481 · llvm/llvm-project · GitHub, let’s discuss the issue there.

+1 on adding code owners

1 Like

Hello!

It does seem like this is an issue specific to building LLVM-libc with gcc in overlay mode and release mode. If you’re just using this for testing, I’d recommend setting -DCMAKE_BUILD_TYPE=Debug. If you actually plan to use this build of libc in a project I’d recommend building with clang, since we tend to optimize for clang first.

Re: DavidSpeickett

I don’t think the status here has changed since the bug you linked, I’m honestly not sure why it’s broken in such a specific configuration.

Code owners are a good idea, and I’ll see about adding a note to the compiler support page.

1 Like

Thank you all!

Yes, as you mentioned, I had been building with the release build option in libc.
I switched to a debug build and it was successful.

If you actually plan to use this build of libc in a project I’d recommend building with clang

Understood! I’ll try building with clang as well.

Thank you!