0

We are currently migrating from AIX and the xlC compiler to Linux and the GNU toolchain. In our C/C++ compilation process we use the -qnoweakexp compiler flags to disable the export of weak symbols. Please see the xlc compiler reference.

I cannot find an equivalent compiler flag in the gcc Options Summary. The end goal is that no weak symbols get exported to our compilation targets. The closest gcc flag I could find was -fno-weak, however the gcc manual states that this flag is not intended to be used in production code.

Background: We need to link with some C libraries of the framework we are using with our compilation targets, and these libraries export some of the same weak symbols, which our own code would without the use of this flag. This has caused segmentation faults to occur sporiadically. These symbols were apparently generated for some STL containers we are using, for example:

std::vector<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::_Clear()

I.e. it is not a case of some of the symbols having been explicitly annotated as weak in the source code, and as such the problem cannot be remedied by removing the annotations.

too honest for this site
  • 12,050
  • 4
  • 30
  • 52
Gábor Ferencz
  • 243
  • 2
  • 9
  • That's not C, but C++. They are **different** languages! – too honest for this site Nov 21 '16 at 11:33
  • Are you quite certain that a) your C++ compiler generates _weak_ symbols for the STL (the default for GCC is strong), and b) mangled C++ symbols collide with C symbols from other libraries? Are those libraries compiled by you as well? Can you modify their source? – Michael Foukarakis Nov 21 '16 at 11:42
  • Also, have you looked into `-fvisibility=hidden`? (this only applies to the C libraries, if you have control over building them) – Michael Foukarakis Nov 21 '16 at 11:48
  • On AIX we were using the very same compilation flag, `-qnoweakexp` for the C code (copiled with xlc) as well as the C++ codes (compiled with xlC), hence I presumed there would similarly be a compilation flag for gcc and g++ as well which would control the export of weak symbols. We are currently in the process of checking the weakness of the problematic symbols on linux, resp. if they still collide with the exported symbols of the framework we are using. The libraries we need to link with are unfortunately not compiled by us, and we cannot even strip the problematic symbols. – Gábor Ferencz Nov 21 '16 at 12:21
  • So we have exported all symbols from the linked C libraries as well as our compiled targets, demangled all symbol names marked as weak and compared the resulting list - it seems to match. In this case under AIX we got errors for each and every such weak symbol, saying that it was a duplicate symbol. Under linux with g++ however we don't get any errors (warnings are turned on with the `-Wall` option, intentionally created duplicate symbol problems get listed). What else should I check to be reasonably sure we won't get a segfault? Where could I read more about his? – Gábor Ferencz Nov 21 '16 at 15:40
  • AIX is an exotic platform, and C++ is very problematic even on common platforms, let alone on AIX. http://web.axelero.hu/lzsiga/aix-linking.html#Q0004 – Zsigmond Lőrinczy Nov 21 '16 at 15:42
  • Yes, I figured. let me rephrase the question then: is symbol preemption something to worry about when using gcc and g++? This was the problem on AIX that warranted us to dismiss weak symbols. Please see here: https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/ – Gábor Ferencz Nov 22 '16 at 11:32

1 Answers1

0

Not entirely equivalent but should be enough for your use-case: -fvisibility-inlines-hidden. This option would cause inline functions (like STL definitions coming from headers) to not be exported from the library. For more info on this check GCC wiki.

yugr
  • 19,769
  • 3
  • 51
  • 96