static lib drops objects with side-effects

[terpstra@bagofholding.com]

On Tue, Feb 11, 2003 at 11:32:37AM +0000, Richard Earnshaw wrote:
> Correct, but incorrect.  The object hasn't been eliminated, since it was 
> never considered for inclusion in the first place.  That sentence in the 
> standard is talking out unused section elimination from single object 
> files.  An archive is not a single object file but a collection of object 
> files whose selection criteria is that they resolve a symbol by something 
> that is already needed.  The C++ standard has zilch to say on the issue of 
> how a list of objects to link together is formed, it just says that once 
> you have that list you can't eliminate static constructors from it.
> 
> So there is no bug in binutils; it's in the way you are trying to use them.

Ok. This makes sense.

How do you suggest one make the typical Singleton registry design pattern
work portably? Clearly one can simply stick with shared libraries instead,
but for systems without, how should it work?

Example:

Library 'image tranform' has: (written by foo.com)
	a registry for image transformation
		- it allows components to register in it
		- it can chain registered transforms for the desired effect

	a self-registering object for png->jpg
	a self-registering object for tif->png

Library 'image transform extras' from a 3rd party has: (from bar.com)
	a self-registering object for png->gif
	a self-registering object for gif->tif

An application for image conversion: (from foo.com)
	- wants all available transformation objects
	- doesn't know what all the objects are (and shouldn't)
	- only uses the registry directly

The whole thing has to work with .a files because the target system doesn't
suppose shared libraries. How is the best way to solve this portably?

---

In this case, the png->jpg and tif->png could have been referenced by the
registry object since at least the programmers of that library knew what
plugins they were including.

Similarily, the extras library could have some well-known proxy object which
references all their plugins.

Then the application references the registry and the 3rd party's proxy
object. This is harder to do though since foo.com didn't know about
bar.com's extra proxy object when they wrote the tool.

Is this really the only way to make things work?

Ideally, there should not need to be any central lists and the application
should not need to know which libraries will be providing plugins to it.
The objects get included, they self-register, and the transformation tool
sees all objects no matter whether they were created after the tool or not.

The whole point of this design pattern is to make it so the packager can
just pull all the plugin objects / libraries / etc he knows about into the
link line and the resulting application 'just works'.

With the current .a behaviour I do not see how to acheive this without 
specific tweaks like whole-archive or looking through the libraries with nm
for appropriately named symbols and building a table.

---
Wes