linker symbol name clashes between rts and system libs

[duncan]

Since we are still using static linking then we still have problems with linker name clashes since it is just one massive global linker namespace.

Example, while linking cabal, solaris ld reports:

Linking dist/build/cabal/cabal ...
ld: warning: symbol `store' has differing types:
	(file /usr/lib/libnsl.so type=FUNC; file /opt/ghc/lib/ghc-6.12.1/libHSrts.a(Globals.o) type=OBJT);
	/opt/ghc/lib/ghc-6.12.1/libHSrts.a(Globals.o) definition taken
ld: warning: symbol `store' has differing types:
	(file /usr/lib/libnsl.so type=FUNC; file /opt/ghc/lib/ghc-6.12.1/libHSrts.a(Globals.o) type=OBJT);

The symbol in question is in rts/Global.c:

static StgStablePtr store[MaxStoreKey];

This example got flagged up because the symbol type happens to be different (function vs data) but there must be loads of other examples where the symbol type is the same.

I've no idea how to systematically eliminate these clashes, nor how serious it might be when we do not.

[simonmar]

That symbol is already defined static, so I don't understand why ld would complain about it. If Solaris ld insists on complaining about private symbols in our libraries, there's not much we can do about it.

[igloo]

Actually, it wasn't static in 6.12.1, and works with more recent GHCs.