Change to DSO-linking semantics of the compiler

[Roland McGrath]

> 78 of those seem to be caused by separated libtinfo. In default
> ncurses configuration libtinfo is included in libncurses, so I don't
> think the upstreams will be very happy about adding support for
> non-standard configurations.
> 
> Petr Machata suggested we could work around it by replacing
> libncurses.so and libncursesw.so symlinks with linker scripts
> including both libraries.
> 
> Is that acceptable?

Yes, that's the right thing to do in this sort of case.  If as the
maintainer of the -devel package providing -lncurses, you are saying
you want -lncurses to go along with an API that is actually provided
in more than one DSO, then that is your choice.  You've decided that
you want your API to map to an ABI in a non-default way, which is fine
when you think it makes sense for your case.

The way you implement this is to make libncurses.so a plain text file
that looks like (modulo indentation):

	# Your comment here.
	AS_NEEDED ( libncurses.so.5 libtinfo.so.5 )


Thanks,
Roland