Re: Why link C with crtstuff? [patch]

Re: Why link C with crtstuff? [patch]

[Ian Lance Taylor]

   From: hjl@lucon.org (H.J. Lu)
   Date: Tue, 28 Apr 1998 10:13:19 -0700 (PDT)

   2. Modify the gnu linker to take

	   ld ... --local foo,bar,....

   which will make foo, bar .. local to libfoo.so. I believe everything
   is almost in binutils 2.9. We just need to add the --local option to
   ld.

I don't know if this is the right approach to take.  I'll just note
that you can already use a version script to force certain symbols to
be local to a shared library.

Ian

Re: Why link C with crtstuff? [patch]

[H.J. Lu]

> 
>    From: hjl@lucon.org (H.J. Lu)
>    Date: Tue, 28 Apr 1998 10:13:19 -0700 (PDT)
> 
>    2. Modify the gnu linker to take
> 
> 	   ld ... --local foo,bar,....
> 
>    which will make foo, bar .. local to libfoo.so. I believe everything
>    is almost in binutils 2.9. We just need to add the --local option to
>    ld.
> 
> I don't know if this is the right approach to take.  I'll just note
> that you can already use a version script to force certain symbols to
> be local to a shared library.
> 

That is why I said thet everything was almost in binutils 2.9. But
I'd like to see that force certain symbols to be local to a shared
library is independent of ELF symbol versioning. We should be able
to use it with and without ELF symbol versioning. 

-- 
H.J. Lu (hjl@gnu.org)

Re: Why link C with crtstuff? [patch]

[H.J. Lu]

> 
> Answers are reordered, the verified one first. ;-)
> 
> >
> > > A side note: dependence on gcc internals from shared libs it not only
> > > a problem of compatibility between gcc versions. A library could be
> > > rewritten/optimized so that it stops using a certain gcc internal
> > > so that it disappears. The author would normally change only a minor
> > > version, but in this case the library becomes incompatible.
> > > 
> > 
> > That is why we now add -lgcc to build shared libraries. Again show me
> > the problem. I will take a look.
> >
> 
> Here is an artificial case, a library libfoo.so and a program test-foo.
> libfoo uses long long division internally, so it has __divdi3 defined.
> test-foo is linked with -lfoo and uses __divdi3 itself. Since -lfoo
> goes to the linker before -lgcc, test-foo uses __divdi3 from libfoo.
> The first implementation of libfoo is inefficient, so there comes 
> a revision. :-) It does exactly the same but without using long long.
> Then test-foo fails because libfoo does not define __divdi3 any more.
> 
> System: i586-pc-linux-gnulibc1, egcs-1.0.2, libc-5.4.44, binutils-2.8.1.0.15.
> 
> This is run as root, assuming there is no useful /usr/lib/libfoo.so*
> ---------------
> #!/bin/sh
> rm /usr/lib/libfoo.so*
> gcc -c foo1.c -o foo.o
> gcc -shared foo.o -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0
> (cp libfoo.so.1.0 /usr/lib ; cd /usr/lib ; ln -sf libfoo.so.1.0 libfoo.so)
> ldconfig
> gcc test-foo.c -lfoo -o test-foo
> echo -n "libfoo 1.0: "
> ./test-foo
> gcc -c foo2.c -o foo.o
> gcc -shared foo.o -Wl,-soname,libfoo.so.1 -o libfoo.so.1.1
> (cp libfoo.so.1.1 /usr/lib ; cd /usr/lib ; ln -sf libfoo.so.1.1 libfoo.so)
> ldconfig
> echo -n "libfoo 1.1: "
> ./test-foo
> --------------
> This is foo1.c
> --------------
> int foo (void)
> {
>     long long a=1, b=1; return a/b;
> }
> --------------
> foo2.c
> --------------
> int foo (void)
> {
>     return 1;    
> }
> --------------
> test-foo.c
> --------------
> #include <stdio.h>
> 
> int main()
> {
>    long long x=1, y=1, z=x/y;
>    printf ("Ok\n");
>    return 0;
> }
> -------------
> and the output
> -------------
> libfoo 1.0: Ok
> libfoo 1.1: ./test-foo: can't resolve symbol '__divdi3'
> -------------
> 
> > 
> > > Still it is unpleasant that the binary appears dependent on these
> > > symbols if linked with the library (and now with weak symbols even 
> > > an extra -lgcc does not help).
> > 
> > What is the problem? Show me one. I will see what I can do.
> 
> No it is not a severe problem. It is just something that would be better
> not to have, if it's easy. Something close to "it's a problem" is the
> following. I recompiled libvga and main(){} with -lvga, then replaced
> libvga by a copy created with the previous patch (i.e. a library
> without __register_frame_info), and the binary failed. I suppose 
> the same would happen if the library was rebuilt with some another
> compiler. For example, gcc-2.7.2.x. (Or not rebuilt but overwritten
> from a binary archive or distribution. But I did not really try this.)
> 
> This is the same with or without the patch. The patch just makes this
> difiicult to avoid. If I'm paranoid I could put -lgcc before -lvga to
> prevent binding to gcc internals in libvga. But this fails for the weak
> __register_frame_info.
> 
> >
> > > Maybe use different names for static and shared things?  For example,
> > > let some __register_frame_info__static in libgcc be a copy/alias/call to
> > > __register_frame_info and let crtbegin.o have this new symbol weak extern
> > > while crtbeginS.o uses __register_frame_info.
> > 
> > Why? Can you give me an example how it is used?
> 
> I was addressing the above (pseudo?) problem with references from a new
> binary to the __register_frame_info in a shared library. Renaming weak
> symbols could prevent them from being hit by ones in the shared library
> and thus make the binary more self-contained w.r.t. gcc internals.
> 
> But sorry, I don't know how to make these symbols work for different
> orders of linking. They only do with the .o first, then libgcc, then
> shared libraries... So it was a stupid idea. :-(
> 

I have been thinking about it for a while now. It is a good idea to
include -lgcc to build libfoo.so. But exporting the symbols in libgcc.a
from libfoo.so is a different story. It may cause many problems down
the road. What I'd like to see is:

1. Create a libgcc.list along with libgcc.a which lists the global
symbols in libgcc.a.
2. Modify the gnu linker to take

	ld ... --local foo,bar,....

which will make foo, bar .. local to libfoo.so. I believe everything
is almost in binutils 2.9. We just need to add the --local option to
ld.
3. gcc -shared will read libgcc.list and pass those symbols to ld via
--local foo,bar,....

I can work on --local for ld if it is feasible.

Thanks.

-- 
H.J. Lu (hjl@gnu.org)

Re: Why link C with crtstuff? [patch]

[Sergei Ivanov]

Sorry if this is a double posting. Something went wrong at the first attempt.

> > No @@ here, patch (2.4) just skips this.
> 
> Ooops. Here is the new one.
> 
> > Also, it seems to be against a snapshot (there is no s-crtS in 1.0.2).
> 
> It is stamp-crtS in 1.0.2. Just apply it by hand for 1.0.2.

It works, in a sense that it does not statically link frame.o to main(){},
and a recompiled shared library has __register_frame_info etc,
so it does not break existing binaries.

Still it is unpleasant that the binary appears dependent on these
symbols if linked with the library (and now with weak symbols even 
an extra -lgcc does not help).

Maybe use different names for static and shared things?  For example,
let some __register_frame_info__static in libgcc be a copy/alias/call to
__register_frame_info and let crtbegin.o have this new symbol weak extern
while crtbeginS.o uses __register_frame_info.

A side note: dependence on gcc internals from shared libs it not only
a problem of compatibility between gcc versions. A library could be
rewritten/optimized so that it stops using a certain gcc internal
so that it disappears. The author would normally change only a minor
version, but in this case the library becomes incompatible.

Sergei

Re: Why link C with crtstuff? [patch]

[H.J. Lu]

> 
> > > > 
> > > > The patch is wrong. Please try this patch.
> > > > 
> > > Thanks. It works for all my primitive tests except one.
> > > I have a shared library compiled by gcc-2.8.1 (libvga-1.2.13, but this
> > > should not be important):
> > > 
> > 
> > Please try this one. BTW, it will only works on systems with crtbeginS.o
> > and crtendS.o.
> 
> It fails to apply to Makefile.in
> 
> > diff -u -r1.1.1.33 Makefile.in
> > --- Makefile.in	1998/04/26 16:06:39	1.1.1.33
> > +++ Makefile.in	1998/04/26 20:46:39
> >  s-crtS: crtstuff.c $(GCC_PASSES) $(CONFIG_H) \
> 
> No @@ here, patch (2.4) just skips this.

Ooops. Here is the new one.

> Also, it seems to be against a snapshot (there is no s-crtS in 1.0.2).

It is stamp-crtS in 1.0.2. Just apply it by hand for 1.0.2.

> Is it against the latest one?

Yes.


-- 
H.J. Lu (hjl@gnu.org)
---
Sun Apr 26 13:51:04 1998  H.J. Lu  (hjl@gnu.org)

	* crtstuff.c (__register_frame_info, __deregister_frame_info):
	If CRTSTUFFS_O is not defined and HANDLE_SYSV_PRAGMA is
	defined, make them weak and check if they are none-zero before
	calling them.

	* Makefile.in (crtbeginS.o crtendS.o): Add -fno-exceptions and
	-DCRTSTUFFS_O.

Index: crtstuff.c
===================================================================
RCS file: /home/work/cvs/gnu/egcs/gcc/crtstuff.c,v
retrieving revision 1.1.1.9
diff -u -r1.1.1.9 crtstuff.c
--- crtstuff.c	1998/04/05 19:07:15	1.1.1.9
+++ crtstuff.c	1998/04/26 20:44:57
@@ -80,6 +80,11 @@
 #endif
 #if !defined (EH_FRAME_SECTION_ASM_OP) && defined (DWARF2_UNWIND_INFO) && defined(ASM_OUTPUT_SECTION_NAME)
 #define EH_FRAME_SECTION_ASM_OP	".section\t.eh_frame,\"aw\""
+
+#if !defined(CRTSTUFFS_O) && defined(HANDLE_SYSV_PRAGMA)
+#pragma weak __register_frame_info
+#pragma weak __deregister_frame_info
+#endif
 #endif
 
 #ifdef OBJECT_FORMAT_ELF
@@ -142,8 +147,11 @@
     }
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+#if !defined(CRTSTUFFS_O) && defined(HANDLE_SYSV_PRAGMA)
+  if (__deregister_frame_info)
 #endif
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
+#endif
   completed = 1;
 }
 
@@ -170,7 +178,10 @@
 frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+#if !defined(CRTSTUFFS_O) && defined(HANDLE_SYSV_PRAGMA)
+  if (__register_frame_info)
+#endif
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 
 static void
@@ -254,8 +265,11 @@
     (*p) ();
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+#if !defined(CRTSTUFFS_O) && defined(HANDLE_SYSV_PRAGMA)
+  if (__deregister_frame_info)
 #endif
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
+#endif
 }
 
 #ifdef EH_FRAME_SECTION_ASM_OP
@@ -266,7 +280,10 @@
 __frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+#if !defined(CRTSTUFFS_O) && defined(HANDLE_SYSV_PRAGMA)
+  if (__register_frame_info)
+#endif
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 #endif
 #endif
Index: Makefile.in
===================================================================
RCS file: /home/work/cvs/gnu/egcs/gcc/Makefile.in,v
retrieving revision 1.1.1.33
diff -u -r1.1.1.33 Makefile.in
--- Makefile.in	1998/04/26 16:06:39	1.1.1.33
+++ Makefile.in	1998/04/26 20:46:39
@@ -1196,12 +1198,12 @@
 s-crtS: crtstuff.c $(GCC_PASSES) $(CONFIG_H) \
   defaults.h frame.h gbl-ctors.h
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) $(CRTSTUFF_T_CFLAGS_S) \
-	  -DCRT_BEGIN -finhibit-size-directive -fno-inline-functions \
-	  -g0 -c $(srcdir)/crtstuff.c 
+	  -DCRT_BEGIN -DCRTSTUFFS_O -finhibit-size-directive -fno-inline-functions \
+	  -fno-exceptions -g0 -c $(srcdir)/crtstuff.c 
 	mv crtstuff$(objext) crtbeginS$(objext)
 	$(GCC_FOR_TARGET) $(GCC_CFLAGS) $(INCLUDES) $(CRTSTUFF_T_CFLAGS_S) \
-	  -DCRT_END -finhibit-size-directive -fno-inline-functions \
-	  -g0 -c $(srcdir)/crtstuff.c -o crtendS$(objext)
+	  -DCRT_END -DCRTSTUFFS_O -finhibit-size-directive -fno-inline-functions \
+	  -fno-exceptions -g0 -c $(srcdir)/crtstuff.c -o crtendS$(objext)
 	touch s-crtS
 
 # Compile the start modules crt0.o and mcrt0.o that are linked with every program

Re: Why link C with crtstuff? [patch]

[Sergei Ivanov]

> > > 
> > > The patch is wrong. Please try this patch.
> > > 
> > Thanks. It works for all my primitive tests except one.
> > I have a shared library compiled by gcc-2.8.1 (libvga-1.2.13, but this
> > should not be important):
> > 
> 
> Please try this one. BTW, it will only works on systems with crtbeginS.o
> and crtendS.o.

It fails to apply to Makefile.in

> diff -u -r1.1.1.33 Makefile.in
> --- Makefile.in	1998/04/26 16:06:39	1.1.1.33
> +++ Makefile.in	1998/04/26 20:46:39
>  s-crtS: crtstuff.c $(GCC_PASSES) $(CONFIG_H) \

No @@ here, patch (2.4) just skips this.
Also, it seems to be against a snapshot (there is no s-crtS in 1.0.2).
Is it against the latest one?

Sergei

Re: Why link C with crtstuff? [patch]

[Sergei Ivanov]

> 
> The patch is wrong. Please try this patch.
> 
Thanks. It works for all my primitive tests except one.
I have a shared library compiled by gcc-2.8.1 (libvga-1.2.13, but this
should not be important):

~/test$ nm -D /usr/lib/libvga.so.1 | grep register_frame_info
000164e0 T __deregister_frame_info
0001644c T __register_frame_info
00016498 T __register_frame_info_table

I compile "main(){}" with -lvga. It works ok but:

~/test/oldvga$ nm -D a.out | grep register_frame_info
         U __deregister_frame_info
         U __register_frame_info

Now I recompile the library and replace the old one:

~/test$ nm -D /usr/lib/libvga.so.1 | grep register_frame_info
         U __deregister_frame_info
         U __register_frame_info

(btw, are they really need to be U, not just absent?)
The binary stops working:

~/test/oldvga$ ./a.out
./a.out: can't resolve symbol '__register_frame_info'

This is a kind of vicious circle. With an old-gcc made library,
it's hard to compile a binary that will work with a new-gcc library.
(old-gcc = without the patch, new-gcc = with the patch).

Sergei

Re: Why link C with crtstuff? [patch]

[Ian Lance Taylor]

   Date: Sun, 26 Apr 1998 11:04:46 -0600
   From: Jeffrey A Law <law@cygnus.com>

     In message < m0yTKUE-000598C@ocean.lucon.org >you write:
     > BTW, Jim, I cannot get__ attribute__((weak)) to work on extern.
   I don't think it should work on a function declaration.

   Seems to me you have to have it on the function defintion or
   there's no way for it to actually mark the function in question
   as weak.

There are two kinds of weak symbols: weak defined symbols, which
clearly must be associated with a function definition, and weak
undefined symbols, which clearly can not be associated with a function
definition.

I don't know how to make a weak undefined symbol, except by using
#pragma weak.  Here is an example that will make a weak defined symbol
bar and a weak undefined symbol foo.  The attribute on foo has no
effect.  If you remove the pragma, foo will not be weak.

Ian

extern int foo (int) __attribute__((__weak__));
#pragma weak foo

int bar (int) __attribute__ ((__weak__));

int
bar (int i)
{
  if (foo)
    return foo (i);
  return i;
}

Re: Why link C with crtstuff? [patch]

[H.J. Lu]

> 
> 
>   In message < m0yTKUE-000598C@ocean.lucon.org >you write:
>   > BTW, Jim, I cannot get__ attribute__((weak)) to work on extern.
> I don't think it should work on a function declaration.
> 
> Seems to me you have to have it on the function defintion or
> there's no way for it to actually mark the function in question
> as weak.
> 

If that is the case, do I have to use

extern void foo ();
#pragma weak foo

in crtstuff.c to mark foo as weak?


-- 
H.J. Lu (hjl@gnu.org)

Re: Why link C with crtstuff? [patch]

[Jeffrey A Law]

  In message < m0yTKUE-000598C@ocean.lucon.org >you write:
  > BTW, Jim, I cannot get__ attribute__((weak)) to work on extern.
I don't think it should work on a function declaration.

Seems to me you have to have it on the function defintion or
there's no way for it to actually mark the function in question
as weak.

jeff

Re: Why link C with crtstuff? [patch]

[H.J. Lu]

> 
> Hello
> 
> There is a feature of egcs (and gcc 2.8.x) that I don't like.
> It links everything with crtbegin[S].o/crtend[S].o which in turn
> reference symbols from frame.o. 
> This is not good because
> 
> 1. The executable size increases (+5Kb on my i586-pc-linux-gnulibc1).
> crtstuff itself is small, but frame.o is large.

It should be easy to fix.

> 
> 2. It also goes to shared libraries. Imagine one has a library
> libxxx.so and builds a program with -lxxx. The linker gets crtbegin.o
> and -lxxx before -lgcc, and what is referenced by crtbegin.o is found
> in libxxx.so - frame.o is there because of crtbeginS.o!
> Now what if the library was built with an older version of egcs/gcc,
> and things has been changed since that? Even worse, the binary now
> depends on something in libxxx about which only gcc knows.
> So future versions of gcc will have to include the same stuff,
> with the same interface, into shared libs. Otherwise recompiling
> the library will break programs depending on it.
> 
> On the other hand, crtstuff is a C++ related thing
> and is not needed for pure C code (AFAIK).

That is not true. crtstuff is used by C++, but not exclusively.
> 
> So why not link it just like libstdc++, i.e. only by g++ driver?
> Let good old C live in a world untouched by dirty hands of C++!
> 
> Please look at the below patch against egcs-1.0.2
> (quick and a bit illogical, but works for me at least).
> It enables %{x...} tests in specs and uses them in linux
> startfile/endfile to get rid of crt*.o when not using c++.
> 

The patch is wrong. Please try this patch.

BTW, Jim, I cannot get__ attribute__((weak)) to work on extern.


H.J.
----
Index: crtstuff.c
===================================================================
RCS file: /home/work/cvs/gnu/egcs/gcc/crtstuff.c,v
retrieving revision 1.1.1.9
diff -u -r1.1.1.9 crtstuff.c
--- crtstuff.c	1998/04/05 19:07:15	1.1.1.9
+++ crtstuff.c	1998/04/22 15:30:00
@@ -80,6 +80,11 @@
 #endif
 #if !defined (EH_FRAME_SECTION_ASM_OP) && defined (DWARF2_UNWIND_INFO) && defined(ASM_OUTPUT_SECTION_NAME)
 #define EH_FRAME_SECTION_ASM_OP	".section\t.eh_frame,\"aw\""
+
+#ifdef HANDLE_SYSV_PRAGMA
+#pragma weak __register_frame_info
+#pragma weak __deregister_frame_info
+#endif
 #endif
 
 #ifdef OBJECT_FORMAT_ELF
@@ -142,8 +147,11 @@
     }
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+#ifdef HANDLE_SYSV_PRAGMA
+  if (__deregister_frame_info)
 #endif
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
+#endif
   completed = 1;
 }
 
@@ -170,7 +178,10 @@
 frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+#ifdef HANDLE_SYSV_PRAGMA
+  if (__register_frame_info)
+#endif
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 
 static void
@@ -254,8 +265,11 @@
     (*p) ();
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+#ifdef HANDLE_SYSV_PRAGMA
+  if (__deregister_frame_info)
 #endif
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
+#endif
 }
 
 #ifdef EH_FRAME_SECTION_ASM_OP
@@ -266,7 +280,10 @@
 __frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+#ifdef HANDLE_SYSV_PRAGMA
+  if (__register_frame_info)
+#endif
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 #endif
 #endif

Re: Why link C with crtstuff? [patch]

[Jeffrey A Law]

  In message < m0yTDf2-000B93C@svivano.pdmi.ras.ru >you write:
  > There is a feature of egcs (and gcc 2.8.x) that I don't like.
  > It links everything with crtbegin[S].o/crtend[S].o which in turn
  > reference symbols from frame.o. 
Well, like it or it, it will stay.

  > On the other hand, crtstuff is a C++ related thing
  > and is not needed for pure C code (AFAIK).
It is needed if:

	* You want to link C & C++ together.

	* You use exceptions.

	* you use block profiling.

	* You write code which uses the constructor or destructor
	attributes.

	* Shared libraries need to be self-contained in respect
	to compiler intrinsics -- which include the EH mechanisms.

	ie, the library must have its own copy of those routines.

	Yes, this means we have to keep old interfaces for compiler
	intrinsics around.  But that's just the price we have to
	pay.


jeff

Why link C with crtstuff? [patch]

[Sergei Ivanov]

Hello

There is a feature of egcs (and gcc 2.8.x) that I don't like.
It links everything with crtbegin[S].o/crtend[S].o which in turn
reference symbols from frame.o. 
This is not good because

1. The executable size increases (+5Kb on my i586-pc-linux-gnulibc1).
crtstuff itself is small, but frame.o is large.

2. It also goes to shared libraries. Imagine one has a library
libxxx.so and builds a program with -lxxx. The linker gets crtbegin.o
and -lxxx before -lgcc, and what is referenced by crtbegin.o is found
in libxxx.so - frame.o is there because of crtbeginS.o!
Now what if the library was built with an older version of egcs/gcc,
and things has been changed since that? Even worse, the binary now
depends on something in libxxx about which only gcc knows.
So future versions of gcc will have to include the same stuff,
with the same interface, into shared libs. Otherwise recompiling
the library will break programs depending on it.

On the other hand, crtstuff is a C++ related thing
and is not needed for pure C code (AFAIK).

So why not link it just like libstdc++, i.e. only by g++ driver?
Let good old C live in a world untouched by dirty hands of C++!

Please look at the below patch against egcs-1.0.2
(quick and a bit illogical, but works for me at least).
It enables %{x...} tests in specs and uses them in linux
startfile/endfile to get rid of crt*.o when not using c++.

E.g,  %{xc++:%{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}}
means that crtbegin[S].o is used by g++ but not by plain gcc.
More precisely, the text under %{xLANG:...} is substituted if either
-xLANG was given to gcc or LANG is defined as the "default language"
of the driver (the patch only defines c++ for g++ but this can be 
trivially extended).
It might be good to pay attention to suffuxes of input files,
but this is not done (yet?). 

Also: {x} is deleted from linker specs (could not work anyway),
and the warning "-x has no effect" is removed.

Maybe `language_specific_driver' (which hacks the command line) can be
completely eliminated and replaced by a similar language-dependent part
of linker specs.

Does this make sense?  Or is it completely silly from the beginning?

Thanks
Sergei
 

The patch follows

diff -urpN egcs-1.0.2.vanilla/gcc/config/linux.h egcs-1.0.2/gcc/config/linux.h
--- egcs-1.0.2.vanilla/gcc/config/linux.h	Sun Feb 15 22:43:54 1998
+++ egcs-1.0.2/gcc/config/linux.h	Thu Apr 23 00:40:41 1998
@@ -70,7 +70,7 @@ Boston, MA 02111-1307, USA.  */
      %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} \
 		       %{!p:%{profile:gcrt1.o%s} \
 			 %{!profile:crt1.o%s}}}} \
-   crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}"
+   crti.o%s %{xc++:%{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}}"
 
 /* Provide a ENDFILE_SPEC appropriate for Linux.  Here we tack on
    the Linux magical crtend.o file (see crtstuff.c) which
@@ -80,7 +80,7 @@ Boston, MA 02111-1307, USA.  */
 
 #undef	ENDFILE_SPEC
 #define ENDFILE_SPEC \
-  "%{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s"
+  "%{xc++:%{!shared:crtend.o%s} %{shared:crtendS.o%s}} crtn.o%s"
 
 /* This is for -profile to use -lc_p instead of -lc. */
 #ifndef CC1_SPEC
diff -urpN egcs-1.0.2.vanilla/gcc/cp/Make-lang.in egcs-1.0.2/gcc/cp/Make-lang.in
--- egcs-1.0.2.vanilla/gcc/cp/Make-lang.in	Sat Nov 22 00:04:09 1997
+++ egcs-1.0.2/gcc/cp/Make-lang.in	Wed Apr 22 23:21:08 1998
@@ -87,6 +87,7 @@ g++.o: $(CONFIG_H) multilib.h config.sta
 	$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
 	$(DRIVER_DEFINES) \
 	-DLANG_SPECIFIC_DRIVER \
+	-DDRIVER_LANGUAGE=\"c++\" \
   -c g++.c
 
 # Create the compiler driver for g++.
diff -urpN egcs-1.0.2.vanilla/gcc/gcc.c egcs-1.0.2/gcc/gcc.c
--- egcs-1.0.2.vanilla/gcc/gcc.c	Mon Sep  1 21:02:40 1997
+++ egcs-1.0.2/gcc/gcc.c	Thu Apr 23 13:27:49 1998
@@ -224,6 +224,12 @@ static struct obstack collect_obstack;
 
 extern char *version_string;
 
+#ifdef DRIVER_LANGUAGE
+static char *driver_language = DRIVER_LANGUAGE;
+#else
+static char *driver_language = 0;
+#endif
+
 /* Forward declaration for prototypes.  */
 struct path_prefix;
 
@@ -707,7 +713,7 @@ static int n_default_compilers
 static char *link_command_spec = "\
 %{!fsyntax-only: \
  %{!c:%{!M:%{!MM:%{!E:%{!S:ld %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} \
-			%{r} %{s} %{t} %{u*} %{x} %{z} %{Z}\
+			%{r} %{s} %{t} %{u*} %{z} %{Z}\
 			%{!A:%{!nostdlib:%{!nostartfiles:%S}}}\
 			%{static:} %{L*} %o\
 			%{!nostdlib:%{!nodefaultlibs:%G %L %G}}\
@@ -719,7 +725,7 @@ static char *link_command_spec = "\
 static char *link_command_spec = "\
 %{!fsyntax-only: \
  %{!c:%{!M:%{!MM:%{!E:%{!S:ld %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} \
-			%{r} %{s} %{t} %{u*} %{x} %{z} %{Z}\
+			%{r} %{s} %{t} %{u*} %{z} %{Z}\
 			%{!A:%{!nostdlib:%{!nostartfiles:%S}}}\
 			%{static:} %{L*} %D %o\
 			%{!nostdlib:%{!nodefaultlibs:%G %L %G}}\
@@ -2333,7 +2339,6 @@ process_command (argc, argv)
   register int i;
   char *temp;
   char *spec_lang = 0;
-  int last_language_n_infiles;
   int have_c = 0;
   int have_o = 0;
   int lang_n_infiles = 0;
@@ -2810,7 +2815,6 @@ process_command (argc, argv)
   infiles = (struct infile *) xmalloc ((n_infiles + 1) * sizeof (struct infile));
   n_switches = 0;
   n_infiles = 0;
-  last_language_n_infiles = -1;
 
   /* This, time, copy the text of each switch and store a pointer
      to the copy in the vector of switches.
@@ -2889,19 +2893,23 @@ process_command (argc, argv)
 
 	  if (c == 'x')
 	    {
-	      if (p[1] == 0 && i + 1 == argc)
-		fatal ("argument to `-x' is missing");
 	      if (p[1] == 0)
-		spec_lang = argv[++i];
-	      else
-		spec_lang = p + 1;
-	      if (! strcmp (spec_lang, "none"))
-		/* Suppress the warning if -xnone comes after the last input
-		   file, because alternate command interfaces like g++ might
-		   find it useful to place -xnone after each input file.  */
-		spec_lang = 0;
-	      else
-		last_language_n_infiles = n_infiles;
+		{
+	          if (i + 1 == argc)
+		    fatal ("argument to `-x' is missing");
+		  /* Pretend that -x is not separated from its argument
+		     so that %{x...} in specs can work.  */
+		  p = xmalloc (strlen (argv[i+1]) + 2);
+		  p[0] = c;
+		  strcpy (p+1, argv[++i]);
+		}
+	      switches[n_switches].part1 = p;
+	      switches[n_switches].args = 0;
+	      switches[n_switches].live_cond = 0;
+	      switches[n_switches].valid = 1;
+	      n_switches++;
+
+	      spec_lang = strcmp (p+1, "none") ? 0 : p+1;
 	      continue;
 	    }
 	  switches[n_switches].part1 = p;
@@ -2975,9 +2983,6 @@ process_command (argc, argv)
 	}
     }
 
-  if (n_infiles == last_language_n_infiles && spec_lang != 0)
-    error ("Warning: `-x %s' after last input file has no effect", spec_lang);
-
   switches[n_switches].part1 = 0;
   infiles[n_infiles].name = 0;
 }
@@ -4038,6 +4043,11 @@ handle_braces (p)
 		  break;
 		}
 	    }
+	  /* -xLANG is "implicitly present" if LANG is the driver's
+	     default language.  */
+	  if (!present && filter[0]=='x' && driver_language
+	      && !strncmp (driver_language, filter+1, p-filter-1))
+	    present = 1;
 	}
 
       /* If it is as desired (present for %{s...}, absent for %{-s...})