On Mon, 2007-11-05 at 02:24 -0800, Lin George wrote:
> Thanks John,
>
>
> Your reply is great! I have two points which I am still confused.
>
> 1. Why the unresolved symbol occurs in step 3?
Because Linux/ld is a screwed up linker ;(
It doesn't resolve external symbols by default when
linking a shared library against a shared library at "compile time".
This is REALLY BAD from a software engineering viewpoint.
There is a switch to ld:
--allow-shlib-undefined
--no-allow-shlib-undefined
Allows (the default) or disallows unde‐
fined symbols in shared libraries.
This switch is similar to --no-unde‐
fined except that it determines the
behaviour when the undefined symbols
are in a shared library rather than a
regular object file. It does not
affect how undefined symbols in regular
object files are handled.
The reason that --allow-shlib-undefined
is the default is that the shared
library being specified at link time
may not be the same as the one that is
available at load time, so the symbols
might actually be resolvable at load
time. Plus there are some systems, (eg
BeOS) where undefined symbols in shared
libraries is normal. (The kernel
patches them at load time to select
which function is most appropriate for
the current architecture. This is used
for example to dynamically select an
appropriate memset function). Appar‐
ently it is also normal for HPPA shared
libraries to have undefined symbols.
UNfortunately if you use that switch you ALSO have to
link in system dependent library code
which is the compiler's responsibility.
I believe this is a serious bug in gcc. It should
ensure public symbols are properly linked at
compile time, and make the system dependent
stuff 'magic' so it can be left unresolved,
so that you don't have to specify the 'magic'
library name. [ld-linux-x86-64.so.2 on my system
I think, but I'm not sure]
however I can't remember the details.. anyhow
that's the explanation.
> 2. I have tried to replace gcc with g++ in step 3, and the build is successful.
> I have also performed some preliminary testing and it seems successful.
> How do you think of this solution?
Fine: if you can compile application code as C++ you should
always do so. C++ has much better type checking, type safe
linkage, etc etc.
In the case of libraries, you should always TEST compile as
C++ if you can, even if you want the production version as
a C library .. for the same reason: C++ will find more
errors. In fact using both C and C++ compilers on the code
yields even better errors than either one or the other alone,
and writing in the common subset of both is generally a good
idea.
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
