build error -- can not find operator new

[skaller]

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