Re: build error -- can not find operator new

[Lin George <george4academic at yahoo dot com>]

Thanks John,


The reference from ld help is great! I think from your reply, it is better that we use non-default configuration of ld to use --no-allow-shlib-undefined option, which could find the error in the 1st place. Right?


regards,
George

----- Original Message ----
From: skaller <skaller@users.sourceforge.net>
To: Lin George <george4academic@yahoo.com>
Cc: gcc-help@gcc.gnu.org
Sent: Monday, November 5, 2007 7:13:11 PM
Subject: Re: build error -- can not find operator new


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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com