3.Work4.1:STICK/ctor_test> test_dyn
foo
bar
f 123
main result 123
3.Work4.1:STICK/ctor_test>

3.Work4.1:STICK/ctor_test> readelf -s lib.o

Symbol table '.symtab' contains 22 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS lib.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 4
5: 00000000 0 SECTION LOCAL DEFAULT 5
6: 00000000 0 SECTION LOCAL DEFAULT 6
7: 000000a8 56 FUNC LOCAL DEFAULT 1 _ZN12_GLOBAL__N_115foo_ct
8: 000000a8 56 FUNC LOCAL DEFAULT 1 _ZN12_GLOBAL__N_115foo_ct
9: 00000000 1 OBJECT LOCAL DEFAULT 4 _ZN12_GLOBAL__N_1L18foo_c
10: 000000e0 56 FUNC LOCAL DEFAULT 1 _ZN12_GLOBAL__N_115bar_ct
11: 000000e0 56 FUNC LOCAL DEFAULT 1 _ZN12_GLOBAL__N_115bar_ct
12: 00000001 1 OBJECT LOCAL DEFAULT 4 _ZN12_GLOBAL__N_1L18bar_c
13: 00000184 128 FUNC LOCAL DEFAULT 1 _Z41__static_initializati
14: 00000204 60 FUNC LOCAL DEFAULT 1 _GLOBAL__sub_I_lib.c
15: 00000000 0 SECTION LOCAL DEFAULT 8
16: 00000000 0 SECTION LOCAL DEFAULT 10
17: 00000004 80 FUNC GLOBAL DEFAULT 1 _Z3foov
18: 00000000 0 NOTYPE GLOBAL DEFAULT UND puts
19: 00000058 80 FUNC GLOBAL DEFAULT 1 _Z3barv
20: 0000011c 100 FUNC GLOBAL DEFAULT 1 _Z1fi
21: 00000000 0 NOTYPE GLOBAL DEFAULT UND printf
3.Work4.1:STICK/ctor_test>

IIRC there is no code inside crtend.o and shcrtend.o, they only include the end markers of the constuctor/destructor arrays, the code for calling the functions is in crtbegin.o and shcrtbegin.o.
If there is a problem with crtend.o or shcrtend.o it can only be because of a wrong linking order, i.e. something is wrong in the specs file of GCC.

I found where the __shlib_call_de-/constructors are "defined". they are part of the newlib c library and only present in the shcrtbegin.o file.

Well I cannot be 100% sure, because I have no insight in how sobjs loading is implemented. Maybe elfpipe can confirm it/look into it.

if (!local_undefweak
&& !h->def_regular
&& (h->plt.offset != (bfd_vma) -1
|| eh->plt_got.offset != (bfd_vma) -1))
{
/* Mark the symbol as undefined, rather than as defined in
the .plt section. Leave the value if there were any
relocations where pointer equality matters (this is a clue
for the dynamic linker, to make function pointer
comparisons work between an application and shared
library), otherwise set it to zero. If a function is only
called from a binary, there is no need to slow down
shared libraries because of that. */
sym->st_shndx = SHN_UNDEF;
if (!h->pointer_equality_needed)
sym->st_value = 0;
}

I won't go for the general way to perform a lookup. As the ABI states, it should only be made
if the value of the symbol is zero and a UNDEF function.

Amiga bless the ones who kill the Alf !:) Is it changes was only in the file you with Max point out ? (i just about needs to commit them to adtools repo, so no one will have the same issue again)

10.STICK:shlib_test> app_dyn
lib: 0x7f99d420
main: 0x7f99d420
10.STICK:shlib_test>

With the help of skateman i got access to a compiled example under linux ppc. My idea way to look how the 'symtab' and 'dynsym' entries look like.

As one can see the value is for the linux example 00000000 and not like the amiga executable 01001058. Checking the ABI a 00000000 should
trigger the dynamic linker to resolve the address of the function in the shared object file, and not the address of the PLT entry.

So i used a HEX editor to modify the amiga executable to have even a 00000000 value for the two entries, so see if running it would result
in the expected behavior. Sadly is doesn't:

a) The gcc which writes a wrong entry into the 'symtab' and 'dyntab'
b) The dynamic linker, which just uses the value of the 'symtab' and 'dyntab' entry for UNDEF FUNC, without triggering a resoling if the value is zero.