Re: egcs on AIX: native or gnu ld?

[Andrey Slepuhin <pooh at msu dot ru>]

David Edelsohn wrote:
> 
>         Most of your questions deal with G++ implementation issues which I
> cannot address.  I really do not know how -frepo works or about additional
> files it creates and how linkers other than GNU ld are suppose to handle
> them.  It sounds like at least some of the features of G++ are relying
> upon GNU ld or SVR4/ELF-like linkers.

-frepo option applies also -fno-implicit-templates option and cause g++
to generate for each source file .rpo file with a list of needed templates.
The linker (or linker driver in the case of native linker) looks at this list
and at the result of link stage, marks what templates really must be
instantiated
in each module, then recompiles source modules and repeat the process until
success (i.e. until there will be no undefined symbols).
Well, I discover that passing -bnoquiet option to AIX linker I'll get better
results. The only problem is that I receive messages like the following:

  ld: 0711-319 WARNING: Exported symbol not defined: _GLOBAL_.I.f__Fv
  ld: 0711-318 ERROR: Undefined symbols were found.
          The following symbols are in error:
  Symbol                    Inpndx  TY CL Source-File(Object-File) OR      
Import-File{Shared-object}
                                RLD: Address  Section  Rld-type Referencing
Symbol
    
--------------------------------------------------------------------------------
  _GLOBAL_.I.f__Fv          [2]     ER DS ccMav3Ma.c(/tmp/ccMav3Ma.o)
                                     00000004 .data    R_POS    [16]   
__CTOR_LIST__
  ER: The return code is 8.

Manually relinking files once more I obtain correct exexutable (If extra pass
is needed why not to do it automatically?). Unfortunately, -frepo option is
bad documented :-(

>         The _GLOBAL__DI/_GLOBAL_DD symbols invoke the global constructors
> and destructors for a shared object and are exported for AIX.  Because
> each shared object will contain those same entry points, they will be
> duplicated and the AIX linker will warn about them.  In AIX 4, the linker
> now announced a lot more warnings about these type of issues which always
> were produced by GCC.

Well, I undestand this, but if I link my program with several shared objects,
can I be sure that global constructors/destructors code will be called for
each object?

> | 5) What about including support of shared libraries with native ld to the
> | future snapshots of egcs? Now I am using hacked version of system script
> | makeC++SharedLib, but it only needed for generating correct exports
> | list. At least, I have no problems yet with shared libraries built with
> | native ld.
> 
>         To what type of support of shared libraries are you refering?
> Specifically creating an export list?  Because AIX's XCOFF object file
> format has finer granularity about the visibility of symbols than ELF, it
> takes more work to make it behave like other Unix systems where all global
> symbols are visible outside the module.
> 
>         I am not sure that the FSF would be allowed to include a modified
> version of AIX XLC's makeC++SharedLib script, but if you were to
> reimplement the functionality for G++ as makeG++SharedLib, it probably
> could be included in the egcs distributions and installed automatically.

As I understand, the main goal of makeC++SharedLib script is to provide
correct calling of global constructors/destructors. In egcs this task is done
by linker driver, which generates extra code to do this. So, the only problem
is to generate correct export list, and makeC++SharedLib do this simply by
piping nm output to awk. This can be easy included in egcs linker driver.
Moreover, we do not need to omit some special symbol names (but may be we must
omit others? linker driver for AIX automatically exports some symbols,
but I don't know what rules it uses to do this).

But I am seriously worried about strange segmentation faults of omniORB linked
with shared libs built with gnu ld. For example, while debugging, I find
the following strange situation: in the statement

pd_rx_begin = (void*)((omni::ptr_arith_t )pd_rx_begin + total );
// omni::ptr_arith_t=int, total is int, pd_rx_begin is void*

(It doesn't look like as a good C++ code, but I'm not author of it :-)) after
a number of normal executions once the high byte of pd_rx_begin become zero
(all the time total=0) - so later this cause segmentation fault. This may be
caused by another thread, but effect is stable, and all works fine with static
libraries and also with shared libraries built with native linker. Any ideas?
And what about mixing shared libraries built with native ld (always libc,
for example) and shared libraries built with gnu ld?

Andrey.