🚀 go-pugleaf

> gcc -r -o new.o one.o two. three.o
>
> if you use the -v line we find that the -e __start options is automaticlly
> generated which causes the error message : -r and -e options are mutually
> exclusive. What can we do to get output object like we used to with
> the -r flag without having he -e option defined.

Wow, I didn't know gcc took -r directly.  I admit it seems to work but
I can't find it documented anywhere for gcc or cc.  Since it is really
a linker option you might want to be more explicit and use:

	gcc -Xlinker -r

Furthermore, typically when linking with -r, you'll want to tell gcc not
to pass the standard libraries to the linker in which case you'll want
to add the "nostdlib" option leading to:

	gcc -Xlinker -r -nostdlib -o new.o one.o two.o three.o

Now, back to your original problem of the -e __start being passed to the
linker when it is obviously inappropriate since __start comes out of
crt.o (which is considered part of the standard libraries in gcc terminology).
I encountered this problem and fixed it by modifying the gcc "specs" file as
shown below.  I sent this in as a fix to 2.1 and RMS replied that he was
incorporating it.  If this is not fixed when you use -nostdlib with GCC 2.2.2.
(which I have not gotten a chance to rebuild) please let me know.

    specs.ORIG:
	 %{!e*:-e start} -dc -dp %{static:-Bstatic} %{assert*}

    specs.FIXED:
	 %{!nostdlib:%{!e*:-e start}} -dc -dp %{static:-Bstatic} %{assert*}

--Marc Ullman
  Stanford University

P.S.  Oh, I almost forgot to mention, the bit about -r and -e being mutually
      exclusive is a new bug (Sun considers it a feature) in ld in 4.1.2.
      I got a message back from a Sun developer telling me that they could
      never haved worked together, however, I wrote a commercially distributed
      implementation of dynamic linking (as part of a bigger program) that
      made use of that combination and it ran fine on SunOS 3.5 to 4.1.1.