9

One of the many key differences between C++ Compilers GCC & MSVC is that in the first all symbols from a shared library are exported by default, while MSVC exports nothing.

Some implications are that in, In MSVC, you have to export explict instantiated template classes.

While I have accepted this as a fact of life, I was wondering what are the design implications, trade offs, from a compiler designer perspective, etc. of each approach?

Fernando Gonzalez Sanchez
  • 3,315
  • 4
  • 32
  • 45
  • 6
    GCC's behaviour was almost certainly chosen for compatibility with existing UNIX compilers. The [ELF](http://en.wikipedia.org/wiki/Executable_and_Linkable_Format) spec says that symbols have global visibility by default. That's the traditional behaviour of the C language: symbols are global unless declared `static`. – Jonathan Wakely Mar 13 '15 at 18:20

1 Answers1

2

It probably has something to do with what executables and libraries are in their respective OS's.

On Windows, both libraries (DLL) and executables are the same thing. Literally, you can rename a .dll to .exe and it will run the protected mode stub and output some error (again, protected mode, so it will only work on a 16-bit system). Given that they're the same, and you can (and do!) export symbols from actual executables, you'd expect the default to be to export nothing right?

On Linux however, executables are their own thing, and code libraries (shared objects, .so) are something else. In fact .so files are closer to archives (.a, sort of gcc libraries -- but are not actually archives) if I recall correctly. There's no need for a .lib to be included to use the shared library like in Windows because it is a library file of sorts. Given that you're explicitly compiling your output as this shared library, I don't really see anything weird with it just exporting everything by default.

Blindy
  • 65,249
  • 10
  • 91
  • 131
  • 2
    A .so is really nothing like a .a – Jonathan Wakely Mar 13 '15 at 18:13
  • A library then? It's one of those things right? It's been a while since I used the Linux tool chain. – Blindy Mar 13 '15 at 18:14
  • "Library" can refer to either a `.so` (dynamic library, or shared library) or a `.a` (static library, or archive) but they are very different things. – Jonathan Wakely Mar 13 '15 at 18:21
  • Ok I added a note to that. It doesn't change the point of the post though, since you're compiling and linking with the intent of making a (shared) library, there's nothing wrong with the compiler going ahead and actually exporting the things you're compiling. – Blindy Mar 13 '15 at 18:25
  • 1
    When using ELF, there is no important difference between executables and shared objects. In fact, many distros use PIC-executables (which are marked as ET_DYN, and not as ET_EXEC as you'd expect) as a hardening measure. – ninjalj Mar 13 '15 at 18:36
  • A common example is that you can execute libc.so (with glibc). – Marc Glisse Mar 14 '15 at 09:53