11

Let's first explain what I mean with a stub shared library: a shared library that can be used to link against (w/ a certain interface provided by a real library) but don't contain the actual code (so has no functionality).

Along with the header files it provides everything needed to develop against the library.

Stubs can allow linking to a certain library without having the code available, but also for compatibility it can be useful to link against a stub of a certain library. See for example In Linux stubs are used for standard libraries. Why are stubs required?

Ideally what I need is a way to generate a dummy library from a symbol map file. This map file is, in turn, generated either from an existing .so library or in the same build process.

Are there any tools for this freely available? Or would I need to roll my own?

Community
  • 1
  • 1
wump
  • 4,277
  • 24
  • 25

1 Answers1

4

I guess that for simple C libraries, you could use the output of nm -D on your real shared library to make the stub. For instance you could pipe it into a small awk script which defines functions of that same name, etc.

Another approach would be to make your tiny MELT extension to a recent GCC compiler which would generate the stub (e.g. in C++ or C form) when compiling the real library, or which would clear every function body (in a special mode for compiling a stub-only library). This would work for any language compiled by GCC (but requires some understanding of GCC internals, e.g. Trees and Gimples). Ask on gcc-melt@googlegroups.com

However, I am not sure to understand the practical interest of such stubs. In practice a shared library has some specific coding rules and usage, and this is not verified when using stubs. To be concrete, if using Xlib, you need to call XOpenDisplay at first and XCloseDisplay at last, and such rule can't be checked with an automatically generated stub, etc...

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • I'm trying to do this with a huge C++ library, so I'm afraid the simple approach won't work. And indeed, the library cannot (sensibly) be used to verify anything at runtime, it's just there for linking. To provide an interface to link against although the underlying code can be different. – wump Sep 03 '14 at 12:34
  • Then you might consider the MELT approach i.e. customize your GCC (e.g. to clear every function body). – Basile Starynkevitch Sep 03 '14 at 12:36
  • 1
    FWIW stubs can be used to optimize a build system. In a "naive" build, you may re-link every transitive dependency of a particular library when it is rebuilt. However if the interface hasn't changed, you actually don't need to re-link anything. – cheshirekow Dec 20 '19 at 00:08
  • 1
    @BasileStarynkevitch: Stub libraries are useful for implementing self contained source packages that can be built without requiring to install the full set of dependencies' development packages. You just ship the stubs and the headers with the source. – datenwolf Oct 06 '20 at 10:37