warning: heated soap follows:

(Sorry to sound so heated on this, but this subject has needed
"resolution" for well over a year. It breaks a lot of things on
macppc, not just mozilla, and totally prevents macppc being used as a
"serious" machine.  For instance, kde won't run (but with a simple
compile fix, it will -- see PR#8669, which includes David Barr's
workaround, similar to mine below).  People have repeatedly written to
tech-toolchain and port-macppc, without arousing much interest, except
amongst ourselves (but this problem crops up on other architectures,
too, I might add).  To an old, dumb machine programmer, this is crazy.
And actually, I was going down Charles' path in forming a solution to
this problem; I think, at least for the time being, he is correct.  So
let him proceed, and let the games begin.  It can hardly be worse than
what we have.)

\soap.

>  :       gnusrc/gnu/dist/gcc/config: netbsd.h
>  :       gnusrc/gnu/dist/toolchain/gcc/config: netbsd.h
>  : 
>  : Log Message:
>  : Modify LIB_SPEC and LIBGCC_SPEC so that -lc and -lgcc are not included when
>  : -shared or -symbolic (as on other platforms).  Also, override LIBGCC_SPEC for
>  : all platforms (where it would incorrectly include the .a file explicitly on
>  : some).
>  : This should fix Mozilla on macppc.
>  
>  This is the wrong solution.

Eh? must have pie in my ears.

>  -lgcc is needed in order to provide compiler support functions, and MUST be
>  present.  -lc is a convenience, since it provides the shlib dependency and
>  resolves symbols.

Then why does kde on macppc compile and work perfectly well if we
change pkglibtool like this:

--- /usr/local/bin/pkglibtool-ELF-1.2p2.orig    Mon Sep 13 21:55:52 1999
+++ /usr/local/bin/pkglibtool-ELF-1.2p2 Mon Nov 29 11:17:29 1999
@@ -121,9 +121,10 @@
 # Create an old-style archive from a shared archive.
 old_archive_from_new_cmds=""
 
 # Commands used to build and install a shared archive.
-archive_cmds="\$CC -shared \${wl}-soname \$wl\$soname -o \$lib\$libobjs"
+#archive_cmds="\$CC -shared \${wl}-soname \$wl\$soname -o \$lib\$libobjs"
+archive_cmds="\$LD -shared -soname \$soname -o \$lib\$libobjs"
 postinstall_cmds=""
 postuninstall_cmds=""

i.e. calling the linker directly, thus not passing -lgcc (or -lc)
_at_all_, but falls flat on its face if g++ passes -lgcc to ld (with a
"Unsupported relocation type 10in non-PLT relocations" error coming
from _lgcc_ being included in the (g++ built) shared libraries?

>  The correct solution is to fix Mozilla's build NOT to assume that
>  -Wl,--whole-archive may be used without -Wl,--no-whole-archive, and to fix
>  the old linker (for mac68k, now) to properly ignore "-l" arguments for
>  --whole-archive.

And what solution would that be for kde, "-Wl,--whole-archive" being
mighty scarce in a kde build?

The problem is that -lgcc, being "non-position-independent"
(not-quite static?, or whatever,) needs to be linked against the
"application program" or the shared library in a way that resolves
(all of?) _-lgcc_'s unresolved references.  The "Unsupported
relocation type 10 in non-PLT relocations" refers to (as I Remember,
this being a while ago,) a 24 bit relative jump address, which, I
gather, gcc uses for branches it expects to be resolved within 16(?)
megabytes of the jump.  (i.e. quote statically linked unquote -- part
of the local load module).

ld apparently gulps up -lgcc as a shared library, putting its
unresolved relocations into the GOT or whatnot.  I don't know whether
or not ld tries to resolve against the other objects in the library --
I suspect it would not.  But if it does, there are still quite a few
type 10 branches left.

Now, one would assume a reflexive branch out of a _shared_ library
could, probably would span _much_ larger than 16 meg, so I surmise
that a type 10 relocation might be OK for included, resolved library
functions, but out of the question for use in shared libraries.  So
ld.elf_so, finding a type 10 relocation in a shared library, would be
perfectly justified in not giving that kind of relocation the time of
day.

So, do we

1) Tell gcc to not any more produce 24 bit jumps, or, not to produce
   type 10 relocations?  I would guess this would contravene some
   interface spec (ABI?), and probably put off a lot of powerpc
   developers.  Besides, I suspect that there are more relocation
   types of this class in this set.

2) Compile -lgcc -pic -PIC or as a -shared library?  I don't know if
   -pic/-PIC would do the job, because the library is already pretty
   much PI, and 24 bit _relative_ branches (read _already_ PI) seem to
   be the immediate problem. The egcs people seem to be working toward
   the -shared library notion, but at this point implementing that
   could possibly be more bother than worth, since currently (I'm
   guessing) the shared library can pick up its unresolved lgcc's from
   the running program.

3) Link/resolve completely -lgcc to the shared library?  Except for (I
   think) redundant, multiple -lgcc includes in both the "running"
   program and the shared library(s), sounds good to me.  This is
   really the source of the problem.  But how do we do it?  How do we
   tell all the PKGSRC's that create shared libraries how to do it?

Come, now, let's reason together.  I think Charles is on the correct
track. Why should a collection of libraries need -lgcc?  Wouldn't a
shared library be just as happy deferring resolving its references to
-lgcc until such time as it married up with a "real program"
(whatever that is in this day and age)?

-Mike