Additional research disclosed this exact issue surfaced here:

http://trinity-users.pearsoncomputing.net/?0::2661

However in my case ALL components have been built from the git tree and in
order.

Looking at the out-of-source build dir, the cmake file that is failing is:

/build/kcontrol/kcontrol/kcontrol_tdeinit_executable.cpp

The contents are:

extern "C" int kdemain(int argc, char* argv[]);
int main(int argc, char* argv[]) { return kdemain(argc,argv); }

Looking at the only other cpp file in the build directory,
kcontrol_tdeinit_module.cpp, it's contents are:

#include <kdemacros.h>
extern "C" int kdemain(int argc, char* argv[]);
extern "C" KDE_EXPORT int tdeinitmain(int argc, char* argv[]) { return
kdemain(argc,argv); }

So it almost looks like there is an 'extern "C"' missing from
kcontrol_tdeinit_executable.cpp. 

What say the masters?

old but possibly on point kde bug:

https://bugs.kde.org/show_bug.cgi?id=93347

(In reply to comment #2)
> old but possibly on point kde bug:
> 
> https://bugs.kde.org/show_bug.cgi?id=93347

THAT'S IT!!!

removing:     -DWITH_GCC_VISIBILITY=ON \

allows tdebase to continue building. That still means there are issues in tdebase that need fixing, but 4 hours later (and tired of searching) we at least know what the heck it is! (thanks to a 2004 bug report -- a decade ago)

Bumped from Blocker to Major as building with WITH_GCC_VISIBILITY=OFF will allow the build to proceed in this case on Arch. If others find the same problem and are unable to modify WITH_GCC_VISIBILITY and build re-elevate to Blocker.

How did you build tdelibs - you had WITH_GCC_VISIBILITY turned ON? At what value is set __KDE_HAVE_GCC_VISIBILITY in kdemacros.h (line 24) created by building tdelibs?

(In reply to comment #5)
> How did you build tdelibs - you had WITH_GCC_VISIBILITY turned ON? At what
> value is set __KDE_HAVE_GCC_VISIBILITY in kdemacros.h (line 24) created by
> building tdelibs?

/* #undef __KDE_HAVE_GCC_VISIBILITY */

I see what happened. It is an all or nothing. You either build everything starting with (what?) with -DWITH_GCC_VISIBILITY=ON or you don't use it at all. What is the first module you must start with?

Also, shouldn't we add a check in the CMake files that tests if WITH_GCC_VISIBILITY=ON, check __KDE_HAVE_GCC_VISIBILITY, if not, then throw "Error: Can't use WITH_GCC_VISIBILITY=ON"?

(Odpověď na komentář #6)
> (In reply to comment #5)
> > How did you build tdelibs - you had WITH_GCC_VISIBILITY turned ON? At what
> > value is set __KDE_HAVE_GCC_VISIBILITY in kdemacros.h (line 24) created by
> > building tdelibs?
> 
> /* #undef __KDE_HAVE_GCC_VISIBILITY */
> 
> I see what happened. It is an all or nothing. You either build everything
> starting with (what?) with -DWITH_GCC_VISIBILITY=ON or you don't use it at all.
> What is the first module you must start with?
> 
> Also, shouldn't we add a check in the CMake files that tests if
> WITH_GCC_VISIBILITY=ON, check __KDE_HAVE_GCC_VISIBILITY, if not, then throw
> "Error: Can't use WITH_GCC_VISIBILITY=ON"?

Yes, it is. If tdelibs was not built with WITH_GCC_VISIBILITY="ON" is not possible to build other modules with WITH_GCC_VISIBILITY="ON". Verification WITH_GCC_VISIBILITY="ON" along with __KDE_HAVE_GCC_VISIBILITY is a good idea!

>Verification WITH_GCC_VISIBILITY="ON" along with __KDE_HAVE_GCC_VISIBILITY is a
> good idea!
I agree.

To my understanding, visibility is automatically built into tqt3. arts, tdelibs, and tdebase are the only modules where ON is explicitly supported. Other modules have the same configuration option but are not yet implemented. I ran into that discovery a few months ago.

I remember Tim mentioning long ago that support does not exist in other modules. That is why we created bug 1285.

Fixed in commit 69da674b (tdebase).