glibc2.1 [offtopic]

glibc2.1 [offtopic]

[nbecker]

I'm interested in trying out glibc2.1 on i686-pc-linux-gnu (kernel
2.2.1).

In the glibc2.1 FAQ it says that libstdc++ must be rebuilt.  So do I
understand correctly that I need to rebuild egcs-1.1.1 after
installing glibc2.1, and that all my existing c++ executables will
then be broken until they are relinked???

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> I'm interested in trying out glibc2.1 on i686-pc-linux-gnu (kernel
> 2.2.1).
> 
> In the glibc2.1 FAQ it says that libstdc++ must be rebuilt.  So do I
> understand correctly that I need to rebuild egcs-1.1.1 after
> installing glibc2.1, and that all my existing c++ executables will
> then be broken until they are relinked???
> 

Yes. That is true.

I have been trying to tell everyone that please include my library
versioining patch in egcs 1.1.1. But noone listened to me. That is
one reason why I have to mantain an egcs for Linux. The good news is
I do have a version of egcs 1.1.1 for Linux. The bad news is since
there will be egcs 1.1.2, I canceled egcs 1.1.1/Linux. If you really
want to use egcs 1.1.1 on Linux, try

ftp://ftp.varesearch.com/pub/support/hjl/egcs/egcs-1.1.1-19990115-linux.diff.gz

If you install it instead of egcs 1.1.1, your existing c++ executables
should be ok.

FYI, I will make egcs 1.1.2/Linux shortly after egcs 1.1.2 is released
to public.

Thanks.

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

Re: glibc2.1 [offtopic]

[Zack Weinberg]

On Thu, 11 Feb 1999 07:15:42 -0800 (PST), H.J. Lu wrote:
>> 
>> I'm interested in trying out glibc2.1 on i686-pc-linux-gnu (kernel
>> 2.2.1).
>> 
>> In the glibc2.1 FAQ it says that libstdc++ must be rebuilt.  So do I
>> understand correctly that I need to rebuild egcs-1.1.1 after
>> installing glibc2.1, and that all my existing c++ executables will
>> then be broken until they are relinked???
>> 
>
>Yes. That is true.
>
>I have been trying to tell everyone that please include my library
>versioining patch in egcs 1.1.1. But noone listened to me. That is
>one reason why I have to mantain an egcs for Linux. 

Your library versioning patch is broken.  It does not fix the problem
you created it to fix.  Instead it creates more binary
incompatibilities.

The patch that should be in 1.1.2 is the weak symbols in crtbegin patch.

zw

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> On Thu, 11 Feb 1999 07:15:42 -0800 (PST), H.J. Lu wrote:
> >> 
> >> I'm interested in trying out glibc2.1 on i686-pc-linux-gnu (kernel
> >> 2.2.1).
> >> 
> >> In the glibc2.1 FAQ it says that libstdc++ must be rebuilt.  So do I
> >> understand correctly that I need to rebuild egcs-1.1.1 after
> >> installing glibc2.1, and that all my existing c++ executables will
> >> then be broken until they are relinked???
> >> 
> >
> >Yes. That is true.
> >
> >I have been trying to tell everyone that please include my library
> >versioining patch in egcs 1.1.1. But noone listened to me. That is
> >one reason why I have to mantain an egcs for Linux. 
> 
> Your library versioning patch is broken.  It does not fix the problem

Well, it is on the mainline now.

> you created it to fix.  Instead it creates more binary
> incompatibilities.
> 

It works for me. You never gave me a convincing example to show
it is broken. Maybe we have different opinions on what "broken"
means in this context.


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

Re: glibc2.1 [offtopic]

[Zack Weinberg]

On Thu, 11 Feb 1999 07:44:24 -0800 (PST), H.J. Lu wrote:
>> 
>> On Thu, 11 Feb 1999 07:15:42 -0800 (PST), H.J. Lu wrote:
>> >> 
>> >> I'm interested in trying out glibc2.1 on i686-pc-linux-gnu (kernel
>> >> 2.2.1).
>> >> 
>> >> In the glibc2.1 FAQ it says that libstdc++ must be rebuilt.  So do I
>> >> understand correctly that I need to rebuild egcs-1.1.1 after
>> >> installing glibc2.1, and that all my existing c++ executables will
>> >> then be broken until they are relinked???
>> >> 
>> >
>> >Yes. That is true.
>> >
>> >I have been trying to tell everyone that please include my library
>> >versioining patch in egcs 1.1.1. But noone listened to me. That is
>> >one reason why I have to mantain an egcs for Linux. 
>> 
>> Your library versioning patch is broken.  It does not fix the problem
>
>Well, it is on the mainline now.

Are we talking about the same patch?  The one I don't like is the one
that localizes a bunch of symbols in libgcc.a.  AFAIK it hasn't gone in.

>> you created it to fix.  Instead it creates more binary
>> incompatibilities.
>
>It works for me. You never gave me a convincing example to show
>it is broken. Maybe we have different opinions on what "broken"
>means in this context.

"It works for me" != "it works for everyone".

You localized a bunch of symbols that have been in libgcc since GCC1
and will never go away.  Things like _muldi3.  Those symbols are
re-exported by libc.  We can't take them out without breaking every
binary that needs them.

zw

Re: glibc2.1 [offtopic]

[H.J. Lu]

> >
> >Well, it is on the mainline now.
> 
> Are we talking about the same patch?  The one I don't like is the one

No. I was talking about

Sat Jun 27 19:06:04 1998  H.J. Lu  (hjl@gnu.org)

        * configure (gxx_include_dir): Changed to
        '${prefix}/include/g++'-${libstdcxx_interface}.

        * config.if: New to determine the interfaces.
.....

> 
> >> you created it to fix.  Instead it creates more binary
> >> incompatibilities.
> >
> >It works for me. You never gave me a convincing example to show
> >it is broken. Maybe we have different opinions on what "broken"
> >means in this context.
> 
> "It works for me" != "it works for everyone".
> 
> You localized a bunch of symbols that have been in libgcc since GCC1
> and will never go away.  Things like _muldi3.  Those symbols are
> re-exported by libc.  We can't take them out without breaking every
> binary that needs them.

It is up to libc to export it, not libgcc. It still works for me.
_muldi3 is global even with my libgcc.map patch.

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

Re: glibc2.1 [offtopic]

[H.J. Lu]

> >
> >It works for me. You never gave me a convincing example to show
> >it is broken. Maybe we have different opinions on what "broken"
> >means in this context.
> 
> "It works for me" != "it works for everyone".
> 
> You localized a bunch of symbols that have been in libgcc since GCC1
> and will never go away.  Things like _muldi3.  Those symbols are
> re-exported by libc.  We can't take them out without breaking every
> binary that needs them.
> 

I have compiled glibc 2.1 with my egcs 1.1.1/Linux and installed
it on several RedHat 5.2 systems. Can you tell me which binary I
should check?


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

Re: glibc2.1 [offtopic]

[nbecker]

It sounds to me that we have a problem.  Glibc2.1 was announced to the
net, with a clear recommendation to replace glibc2.0.[1]  I think there's
going to be a bunch of unhappily surprised folks if they find all
their c++ binaries break - including all of kde, for example.  I don't
think this was clearly spelled out in the glibc2.1 release notes.  If
I understand this situation correctly, I suggest the glibc2.1
announcement be ammended to spell this out more clearly.

Footnotes: 
[1]  Yes, I know there are cautions that tell you not to try to
install glibc2.1 yourself unless you know what you are doing, but just 
the same, IMHO if we already know that all c++ binaries will break we
ought to tell everyone a lot more clearly.

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10AxqA-000392C@ocean.lucon.org >you write:
  > I have been trying to tell everyone that please include my library
  > versioining patch in egcs 1.1.1. But noone listened to me.
No, we rejected it as too risky.  "noone listened to me" is not a fair
characterization of what happened.  And I still believe it was the right
thing to do.


jeff

Re: glibc2.1 [offtopic]

[Zack Weinberg]

On Thu, 11 Feb 1999 08:08:17 -0800 (PST), H.J. Lu wrote:
>> >
>> >It works for me. You never gave me a convincing example to show
>> >it is broken. Maybe we have different opinions on what "broken"
>> >means in this context.
>> 
>> "It works for me" != "it works for everyone".
>> 
>> You localized a bunch of symbols that have been in libgcc since GCC1
>> and will never go away.  Things like _muldi3.  Those symbols are
>> re-exported by libc.  We can't take them out without breaking every
>> binary that needs them.
>> 
>
>I have compiled glibc 2.1 with my egcs 1.1.1/Linux and installed
>it on several RedHat 5.2 systems. Can you tell me which binary I
>should check?

I can't find one, which indicates how obscure the problem is.  The
characteristics are: program linked with libstdc++ compiled by a
compiler without your patch, run on system with libstdc++ compiled
with your patch.

zw

Re: glibc2.1 [offtopic]

[H.J. Lu]

> I can't find one, which indicates how obscure the problem is.  The
> characteristics are: program linked with libstdc++ compiled by a
> compiler without your patch, run on system with libstdc++ compiled
> with your patch.
> 

You'd better to find a binary to show me my patch breaks anything.

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

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < 199902111536.KAA17829@blastula.phys.columbia.edu >you write:
  > On Thu, 11 Feb 1999 07:15:42 -0800 (PST), H.J. Lu wrote:
  > >> 
  > >> I'm interested in trying out glibc2.1 on i686-pc-linux-gnu (kernel
  > >> 2.2.1).
  > >> 
  > >> In the glibc2.1 FAQ it says that libstdc++ must be rebuilt.  So do I
  > >> understand correctly that I need to rebuild egcs-1.1.1 after
  > >> installing glibc2.1, and that all my existing c++ executables will
  > >> then be broken until they are relinked???
  > >> 
  > >
  > >Yes. That is true.
  > >
  > >I have been trying to tell everyone that please include my library
  > >versioining patch in egcs 1.1.1. But noone listened to me. That is
  > >one reason why I have to mantain an egcs for Linux. 
  > 
  > Your library versioning patch is broken.  It does not fix the problem
  > you created it to fix.  Instead it creates more binary
  > incompatibilities.
  > 
  > The patch that should be in 1.1.2 is the weak symbols in crtbegin patch.
Can you please forward the "weak symbols" and "crtbegin" patch to me?  I
assume this is something that is already in the mainline tree, right?

jeff

Re: glibc2.1 [offtopic]

[H.J. Lu]

>   > incompatibilities.
>   > 
>   > The patch that should be in 1.1.2 is the weak symbols in crtbegin patch.
> Can you please forward the "weak symbols" and "crtbegin" patch to me?  I

Here it is.

> assume this is something that is already in the mainline tree, right?
> 

No. But I thought it should :-).



-- 
H.J. Lu (hjl@gnu.org)
----
Fri Dec 11 08:00:57 1998  H.J. Lu  (hjl@gnu.org)

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

--- ../../../import/egcs/gcc/crtstuff.c	Tue Jul 14 07:16:05 1998
+++ ./crtstuff.c	Fri Dec 11 08:59:56 1998
@@ -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 SUPPORTS_WEAK
+#pragma weak __register_frame_info
+#pragma weak __deregister_frame_info
+#endif
 #endif
 
 #ifdef OBJECT_FORMAT_ELF
@@ -142,7 +147,10 @@
     }
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+#if SUPPORTS_WEAK
+  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 SUPPORTS_WEAK
+  if (__register_frame_info)
+#endif
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 
 static void __attribute__ ((__unused__))
@@ -254,7 +265,10 @@
     (*p) ();
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+#if SUPPORTS_WEAK
+  if (__deregister_frame_info)
+#endif
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
 }
 
@@ -266,7 +280,10 @@
 __frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+#if SUPPORTS_WEAK
+  if (__register_frame_info)
+#endif
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 #endif
 #endif

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> It sounds to me that we have a problem.  Glibc2.1 was announced to the
> net, with a clear recommendation to replace glibc2.0.[1]  I think there's
> going to be a bunch of unhappily surprised folks if they find all
> their c++ binaries break - including all of kde, for example.  I don't
> think this was clearly spelled out in the glibc2.1 release notes.  If
> I understand this situation correctly, I suggest the glibc2.1
> announcement be ammended to spell this out more clearly.
> 
> Footnotes: 
> [1]  Yes, I know there are cautions that tell you not to try to
> install glibc2.1 yourself unless you know what you are doing, but just 
> the same, IMHO if we already know that all c++ binaries will break we
> ought to tell everyone a lot more clearly.
> 

Just use my egcs 1.1.x/Linux. Nothing should be broken.

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

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10Clsr-000392C@ocean.lucon.org >you write:
  > >   > incompatibilities.
  > >   > 
  > >   > The patch that should be in 1.1.2 is the weak symbols in crtbegin pat
  > ch.
  > > Can you please forward the "weak symbols" and "crtbegin" patch to me?  I
  > 
  > Here it is.
  > 
  > > assume this is something that is already in the mainline tree, right?
  > > 
  > 
  > No. But I thought it should :-).
OK.  I remember this one.  Someone said it was wrong and would cause problems,
so I put it away and didn't install it.

So are we agreed that this is a good patch now?

Jeff

  > 
  > 
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ----
  > Fri Dec 11 08:00:57 1998  H.J. Lu  (hjl@gnu.org)
  > 
  > 	* crtstuff.c (__register_frame_info, __deregister_frame_info):
  > 	If SUPPORTS_WEAK is none zero, make them weak and check if they
  > 	are none-zero before calling them.
  > 

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10Clsr-000392C@ocean.lucon.org >you write:
  > >   > incompatibilities.
  > >   > 
  > >   > The patch that should be in 1.1.2 is the weak symbols in crtbegin pat
  > ch.
  > > Can you please forward the "weak symbols" and "crtbegin" patch to me?  I
  > 
  > Here it is.
  > 
  > > assume this is something that is already in the mainline tree, right?
  > > 
  > 
  > No. But I thought it should :-).
  > 
  > 
  > 
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ----
  > Fri Dec 11 08:00:57 1998  H.J. Lu  (hjl@gnu.org)
  > 
  > 	* crtstuff.c (__register_frame_info, __deregister_frame_info):
  > 	If SUPPORTS_WEAK is none zero, make them weak and check if they
  > 	are none-zero before calling them.
I went back and reviewed this discussion of this patch.

Use an attribute instead of a pragmas.

Kill the unnecessary #ifdefs around the test for nonzero.  This code is not
time critical at all, so the extra if (funcname) isn't going to have any
noticable performance impact.

These are the same things I asked you to do in December.

jeff

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> 
> 
>   In message < m10Clsr-000392C@ocean.lucon.org >you write:
>   > >   > incompatibilities.
>   > >   > 
>   > >   > The patch that should be in 1.1.2 is the weak symbols in crtbegin pat
>   > ch.
>   > > Can you please forward the "weak symbols" and "crtbegin" patch to me?  I
>   > 
>   > Here it is.
>   > 
>   > > assume this is something that is already in the mainline tree, right?
>   > > 
>   > 
>   > No. But I thought it should :-).
>   > 
>   > 
>   > 
>   > -- 
>   > H.J. Lu (hjl@gnu.org)
>   > ----
>   > Fri Dec 11 08:00:57 1998  H.J. Lu  (hjl@gnu.org)
>   > 
>   > 	* crtstuff.c (__register_frame_info, __deregister_frame_info):
>   > 	If SUPPORTS_WEAK is none zero, make them weak and check if they
>   > 	are none-zero before calling them.
> I went back and reviewed this discussion of this patch.
> 
> Use an attribute instead of a pragmas.
> 
> Kill the unnecessary #ifdefs around the test for nonzero.  This code is not
> time critical at all, so the extra if (funcname) isn't going to have any
> noticable performance impact.
> 
> These are the same things I asked you to do in December.
> 

I was on vacation in December. I may have missed your email. The
problem with attribute is you have to do

extern void foo (void);

......

#if SUPPORT_WEAK
extern void foo (void) __attribute__ ((weak));
#endif

That means we need to match foo's prototype in 2 places. We can do

#if SUPPORT_WEAK
extern void foo (void) __attribute__ ((weak));
#else
extern void foo (void);
#endif

But I don't like it. "#prama weak" is the standard for SVR4 and
is cleaner than __attribute__ for this case.


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

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10EkjF-000390C@ocean.lucon.org >you write:
  > #if SUPPORT_WEAK
  > extern void foo (void) __attribute__ ((weak));
  > #endif
  > 
  > That means we need to match foo's prototype in 2 places. We can do
  > 
  > #if SUPPORT_WEAK
  > extern void foo (void) __attribute__ ((weak));
  > #else
  > extern void foo (void);
  > #endif
Define an ATTRIBUTE_WEAK then write
extern void foo (void) ATTRIBUTE_WEAK;

This is how we deal with this problem elsewhere.  I see no reason for this
code to behave any differently.


  > But I don't like it. "#prama weak" is the standard for SVR4 and
  > is cleaner than __attribute__ for this case.
But the GNU standard is to use attributes, not pragmas.

Use an attribute please.

jeff

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> 
>   In message < m10EkjF-000390C@ocean.lucon.org >you write:
>   > #if SUPPORT_WEAK
>   > extern void foo (void) __attribute__ ((weak));
>   > #endif
>   > 
>   > That means we need to match foo's prototype in 2 places. We can do
>   > 
>   > #if SUPPORT_WEAK
>   > extern void foo (void) __attribute__ ((weak));
>   > #else
>   > extern void foo (void);
>   > #endif
> Define an ATTRIBUTE_WEAK then write
> extern void foo (void) ATTRIBUTE_WEAK;
> 
> This is how we deal with this problem elsewhere.  I see no reason for this
> code to behave any differently.

Have you really looked at how egcs deals with weak symbols for targets?
I did

# cd gcc
# grep ATTRIBUTE_WEAK *
# grep "pragma[ \t]+weak" *
gthr-dce.h:#pragma weak pthread_once
gthr-dce.h:#pragma weak pthread_once_init
gthr-dce.h:#pragma weak pthread_key_create
gthr-dce.h:#pragma weak pthread_key_delete
gthr-dce.h:#pragma weak pthread_getspecific
gthr-dce.h:#pragma weak pthread_setspecific
gthr-dce.h:#pragma weak pthread_create
gthr-dce.h:#pragma weak pthread_mutex_lock
gthr-dce.h:#pragma weak pthread_mutex_trylock
gthr-dce.h:#pragma weak pthread_mutex_unlock
gthr-posix.h:#pragma weak pthread_once
gthr-posix.h:#pragma weak pthread_key_create
gthr-posix.h:#pragma weak pthread_key_delete
gthr-posix.h:#pragma weak pthread_getspecific
gthr-posix.h:#pragma weak pthread_setspecific
gthr-posix.h:#pragma weak pthread_create
gthr-posix.h:#pragma weak pthread_mutex_lock 
gthr-posix.h:#pragma weak pthread_mutex_trylock 
gthr-posix.h:#pragma weak pthread_mutex_unlock 
gthr-solaris.h:#pragma weak thr_keycreate
gthr-solaris.h:#pragma weak thr_getspecific
gthr-solaris.h:#pragma weak thr_setspecific
gthr-solaris.h:#pragma weak thr_create
gthr-solaris.h:#pragma weak mutex_lock
gthr-solaris.h:#pragma weak mutex_trylock
gthr-solaris.h:#pragma weak mutex_unlock

> 
> 
>   > But I don't like it. "#prama weak" is the standard for SVR4 and
>   > is cleaner than __attribute__ for this case.
> But the GNU standard is to use attributes, not pragmas.
> 
> Use an attribute please.
> 

It looks to me that "#prama weak" is much more consistent than
attribute in egcs 1.1.2. Those gthr-*h files are not old codes. They
were added after we started egcs. I just copied what we had. Why now
suddenly do you want something different? I hate to see we do things
one way in one place and another way in a different place.


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

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10EyNO-000390C@ocean.lucon.org >you write:

  > Have you really looked at how egcs deals with weak symbols for targets?
  > I did
[ ... ]
This doesn't make it right.

Use an attribute.  I will not ask again.

  > It looks to me that "#prama weak" is much more consistent than
  > attribute in egcs 1.1.2. Those gthr-*h files are not old codes. They
  > were added after we started egcs. I just copied what we had. Why now
  > suddenly do you want something different? I hate to see we do things
  > one way in one place and another way in a different place.
No, it means that the gthr files are wrong and need to be fixed.

jeff
  > 

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
>   > It looks to me that "#prama weak" is much more consistent than
>   > attribute in egcs 1.1.2. Those gthr-*h files are not old codes. They
>   > were added after we started egcs. I just copied what we had. Why now
>   > suddenly do you want something different? I hate to see we do things
>   > one way in one place and another way in a different place.
> No, it means that the gthr files are wrong and need to be fixed.
> 

Thanks for clearing it up. I am gald I asked. Now, where should I
define ATTRIBUTE_WEAK? Since it will be used in more than once
place, it should be in somethere more general.

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

The tree.c patch breaks "make compare."

[H.J. Lu]

Hi, Jeff, Jason,

The append_random_chars/get_file_function_name_long changes in tree.c
in egcs 1.1.2 break "make compare" since you get a different mangled
name everytime when you compile some files. I got:

objc/NXConstStr.o differs
objc/Object.o differs
objc/Protocol.o differs

Can someone please fix "make compare" before 1.1.2?

Thanks.


H.J.

Re: The tree.c patch breaks "make compare."

[Jeffrey A Law]

  In message < m10F1XD-000390C@ocean.lucon.org >you write:
  > Hi, Jeff, Jason,
  > 
  > The append_random_chars/get_file_function_name_long changes in tree.c
  > in egcs 1.1.2 break "make compare" since you get a different mangled
  > name everytime when you compile some files. I got:
  > 
  > objc/NXConstStr.o differs
  > objc/Object.o differs
  > objc/Protocol.o differs
  > 
  > Can someone please fix "make compare" before 1.1.2?
I don't think there's a good way to make it work, other than by not comparing
those files.

They're part of the runtime, not the compiler itself.

jeff

Re: The tree.c patch breaks "make compare."

[H.J. Lu]

> 
> 
> 
>   In message < m10F1XD-000390C@ocean.lucon.org >you write:
>   > Hi, Jeff, Jason,
>   > 
>   > The append_random_chars/get_file_function_name_long changes in tree.c
>   > in egcs 1.1.2 break "make compare" since you get a different mangled
>   > name everytime when you compile some files. I got:
>   > 
>   > objc/NXConstStr.o differs
>   > objc/Object.o differs
>   > objc/Protocol.o differs
>   > 
>   > Can someone please fix "make compare" before 1.1.2?
> I don't think there's a good way to make it work, other than by not comparing
> those files.
> 

Anything is fine with me as long as "make compare" doesn't fail
because of it.


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

Re: glibc2.1 [offtopic]

[Marc Espie]

In article < m10EyNO-000390C@ocean.lucon.org > you write:
>>   In message < m10EkjF-000390C@ocean.lucon.org >you write:
>>   > #if SUPPORT_WEAK
>>   > extern void foo (void) __attribute__ ((weak));
>>   > #endif
>>   > 
>>   > That means we need to match foo's prototype in 2 places. We can do
>>   > 
>>   > #if SUPPORT_WEAK
>>   > extern void foo (void) __attribute__ ((weak));
>>   > #else
>>   > extern void foo (void);
>>   > #endif
>> Define an ATTRIBUTE_WEAK then write
>> extern void foo (void) ATTRIBUTE_WEAK;
>> 
>> This is how we deal with this problem elsewhere.  I see no reason for this
>> code to behave any differently.
>
>Have you really looked at how egcs deals with weak symbols for targets?
>I did

># cd gcc
># grep ATTRIBUTE_WEAK *
># grep "pragma[ \t]+weak" *
>gthr-posix.h:#pragma weak pthread_once
>gthr-posix.h:#pragma weak pthread_key_create
>gthr-posix.h:#pragma weak pthread_key_delete
>gthr-posix.h:#pragma weak pthread_getspecific
>gthr-posix.h:#pragma weak pthread_setspecific
>gthr-posix.h:#pragma weak pthread_create
>gthr-posix.h:#pragma weak pthread_mutex_lock 
>gthr-posix.h:#pragma weak pthread_mutex_trylock 
>gthr-posix.h:#pragma weak pthread_mutex_unlock 

Now, try to interpret the 3 last lines of gcc/config/openbsd.h 
with THAT in mind.

/* Otherwise, since we support weak, gthr.h errouneously tries to use
   #pragma weak. */
#define GTHREAD_USE_WEAK 0

Yep, that's right. You've got one operating system which *does* support
weak, but isn't  entirely too fond of #pragma, specifically does *not*
define HANDLE_SYSV_PRAGMA, and does not intend to unless something exterior
forces it too...

There are at least two issues to resolve there:
First, SUPPORTS_WEAK is definitely *not* a synonym for  
HANDLE_PRAGMA_WEAK, as defined *properly* in c-pragma.h
(maybe the definition should be moved to a more visible place, like
default.sh ?)

Second, attribute((weak)) is harder to use than pragma weak. Mainly,
#pragma weak acts as a lower level, where it only does change a symbol
property, whereas attribute((weak)) needs a proper declaration to work.
One pro is that it gets type-checking, and will work correctly for C++
identifiers. One con is that it is impossible to change the weakness status
of a symbol without knowing quite a lot about this symbol.

Maybe having the lower-level facility available without using pragma would
make sense ? Otherwise I see people continuing to use #pragma weak or,
failing that asm(".weak symbol"); to get around the type-checking system.

Re: The tree.c patch breaks "make compare."

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < m10F1XD-000390C@ocean.lucon.org >you write:
 >> Hi, Jeff, Jason,
 >> 
 >> The append_random_chars/get_file_function_name_long changes in tree.c
 >> in egcs 1.1.2 break "make compare" since you get a different mangled
 >> name everytime when you compile some files. I got:
 >> 
 >> objc/NXConstStr.o differs
 >> objc/Object.o differs
 >> objc/Protocol.o differs
 >> 
 >> Can someone please fix "make compare" before 1.1.2?

 > I don't think there's a good way to make it work, other than by not
 > comparing those files.

I don't see why the patch should affect those files; they have unique
definitions that we should be able to key off of.

Jason

Re: The tree.c patch breaks "make compare."

[H.J. Lu]

> 
> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
> 
>  >   In message < m10F1XD-000390C@ocean.lucon.org >you write:
>  >> Hi, Jeff, Jason,
>  >> 
>  >> The append_random_chars/get_file_function_name_long changes in tree.c
>  >> in egcs 1.1.2 break "make compare" since you get a different mangled
>  >> name everytime when you compile some files. I got:
>  >> 
>  >> objc/NXConstStr.o differs
>  >> objc/Object.o differs
>  >> objc/Protocol.o differs
>  >> 
>  >> Can someone please fix "make compare" before 1.1.2?
> 
>  > I don't think there's a good way to make it work, other than by not
>  > comparing those files.
> 
> I don't see why the patch should affect those files; they have unique
> definitions that we should be able to key off of.
> 

Have you tried to bootstrap egcs 1.1.2 on Linux/glibc2/x86?


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

Re: The tree.c patch breaks "make compare."

[Zack Weinberg]

On Mon, 22 Feb 1999 19:21:05 -0800 (PST), H.J. Lu wrote:
>> 
>> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
>> 
>>  >   In message < m10F1XD-000390C@ocean.lucon.org >you write:
>>  >> Hi, Jeff, Jason,
>>  >> 
>>  >> The append_random_chars/get_file_function_name_long changes in tree.c
>>  >> in egcs 1.1.2 break "make compare" since you get a different mangled
>>  >> name everytime when you compile some files. I got:
>>  >> 
>>  >> objc/NXConstStr.o differs
>>  >> objc/Object.o differs
>>  >> objc/Protocol.o differs
>>  >> 
>>  >> Can someone please fix "make compare" before 1.1.2?
>> 
>>  > I don't think there's a good way to make it work, other than by not
>>  > comparing those files.
>> 
>> I don't see why the patch should affect those files; they have unique
>> definitions that we should be able to key off of.

Why are these files in gcc/objc and not libobjc?  Moving them out
would fix the problem.

zw

Re: The tree.c patch breaks "make compare."

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

 >>  >> objc/NXConstStr.o differs
 >>  >> objc/Object.o differs
 >>  >> objc/Protocol.o differs
 >> 
 >> I don't see why the patch should affect those files; they have unique
 >> definitions that we should be able to key off of.

 > Have you tried to bootstrap egcs 1.1.2 on Linux/glibc2/x86?

Not yet.  I'm not denying that you are seeing problems; I'm just saying
that it's a bug rather than a design problem.

Jason

Re: The tree.c patch breaks "make compare."

[Jeffrey A Law]

  In message < 199902230325.WAA13877@blastula.phys.columbia.edu >you write:

  > Why are these files in gcc/objc and not libobjc?  Moving them out
  > would fix the problem.
Because the transition to a separate libobjc happened *after* egcs-1.1 was
branched.

ie, there is no libobjc in egcs-1.1.  The objc runtime is still sitting in
gcc/objc.


jeff

Re: The tree.c patch breaks "make compare."

[Jeffrey A Law]

  In message < u9ogmlesbh.fsf@yorick.cygnus.com >you write:
  >  >> Can someone please fix "make compare" before 1.1.2?
  > 
  >  > I don't think there's a good way to make it work, other than by not
  >  > comparing those files.
  > 
  > I don't see why the patch should affect those files; they have unique
  > definitions that we should be able to key off of.
There aren't any global symbols as far as I can tell in those files.  The
only defined externs found by nm would be:

nm -g NXConstStr.o Protocol.o Object.o | grep -v U

NXConstStr.o:
00000020 T _GLOBAL_.I._puke_law_egcs_1.1_gcc_objc_NXConstStr.mAcRlmb
00000004 R __objc_class_name_NXConstantString

Protocol.o:
000001cc T _GLOBAL_.I._puke_law_egcs_1.1_gcc_objc_Protocol.m7Izrta
00000008 R __objc_class_name_Protocol

Object.o:
00000a8c T _GLOBAL_.I._puke_law_egcs_1.1_gcc_objc_Object.mVM1cga
00000004 ? __objc_class_name_Object


Presumably first_global_object_name is empty, which causes us to
call the "append_random_chars" code which in turn causes the comparison
failure.

jeff

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10EzM4-000390C@ocean.lucon.org >you write:
  > > 
  > >   > It looks to me that "#prama weak" is much more consistent than
  > >   > attribute in egcs 1.1.2. Those gthr-*h files are not old codes. They
  > >   > were added after we started egcs. I just copied what we had. Why now
  > >   > suddenly do you want something different? I hate to see we do things
  > >   > one way in one place and another way in a different place.
  > > No, it means that the gthr files are wrong and need to be fixed.
  > > 
  > 
  > Thanks for clearing it up. I am gald I asked. Now, where should I
  > define ATTRIBUTE_WEAK? Since it will be used in more than once
  > place, it should be in somethere more general.
For the mainline it belongs in gansidecl.h with the rest of the attribute
definitions.

  Note that these attribute defines are not target specific defines and
  defining them in gansidecl.h is clean and the right thing to do.  If you
  look at the mainline you'll see that tm.h already includes gansidecl.h.

However, egcs-1.1 pre-dates the conversion to using gansidecl in a more
consistent manner.  So I would recommend that you place the define for
ATTRIBUTE_WEAK within crtstuff.c for the egcs-1.1 branch.

We can/should deal with fixing gthr-* as an independent patch.

jeff

Re: The tree.c patch breaks "make compare."

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < u9ogmlesbh.fsf@yorick.cygnus.com >you write:
 >>  >> Can someone please fix "make compare" before 1.1.2?
 >> 
 >>  > I don't think there's a good way to make it work, other than by not
 >>  > comparing those files.
 >> 
 >> I don't see why the patch should affect those files; they have unique
 >> definitions that we should be able to key off of.

 > There aren't any global symbols as far as I can tell in those files.  The
 > only defined externs found by nm would be:

 > NXConstStr.o:
 > 00000020 T _GLOBAL_.I._puke_law_egcs_1.1_gcc_objc_NXConstStr.mAcRlmb
 > 00000004 R __objc_class_name_NXConstantString

Odd.  What does the compiler do with the method definitions?

Jason

Re: The tree.c patch breaks "make compare."

[Jeffrey A Law]

  In message < u9iuctegi5.fsf@yorick.cygnus.com >you write:
  > >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  >  >   In message < u9ogmlesbh.fsf@yorick.cygnus.com >you write:
  >  >>  >> Can someone please fix "make compare" before 1.1.2?
  >  >> 
  >  >>  > I don't think there's a good way to make it work, other than by not
  >  >>  > comparing those files.
  >  >> 
  >  >> I don't see why the patch should affect those files; they have unique
  >  >> definitions that we should be able to key off of.
  > 
  >  > There aren't any global symbols as far as I can tell in those files.  Th
  > e
  >  > only defined externs found by nm would be:
  > 
  >  > NXConstStr.o:
  >  > 00000020 T _GLOBAL_.I._puke_law_egcs_1.1_gcc_objc_NXConstStr.mAcRlmb
  >  > 00000004 R __objc_class_name_NXConstantString
  > 
  > Odd.  What does the compiler do with the method definitions?
Not 100% sure, since I don't know what they look like as symbols.  Those
files definitely have a boatload of local functions:

[ ... ]
000005a4 t _i_Object__perform_
000005f0 t _i_Object__perform_with_
00000644 t _i_Object__perform_with_with_
000006a0 t _i_Object__forward__
000006c8 t _i_Object__performv__
000006e0 t _c_Object__poseAs_
000006f4 t _i_Object__transmuteClassTo_
0000077c t _i_Object__subclassResponsibility_
000007b4 t _i_Object__notImplemented_
000007ec t _i_Object__shouldNotImplement_
00000844 t _i_Object__doesNotRecognize_
000008a4 t _i_Object__error_
000009fc t _c_Object__version
00000a18 t _c_Object__setVersion_
00000a34 t _c_Object__streamVersion_
00000a68 t _i_Object__read_
00000a74 t _i_Object__write_
00000a80 t _i_Object__awake

I don't know enough about ObjC to know if those are method definitions, and
if so how user code would get to them since just about everything is static.

jeff

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> 
> 
>   In message < m10EzM4-000390C@ocean.lucon.org >you write:
>   > > 
>   > >   > It looks to me that "#prama weak" is much more consistent than
>   > >   > attribute in egcs 1.1.2. Those gthr-*h files are not old codes. They
>   > >   > were added after we started egcs. I just copied what we had. Why now
>   > >   > suddenly do you want something different? I hate to see we do things
>   > >   > one way in one place and another way in a different place.
>   > > No, it means that the gthr files are wrong and need to be fixed.
>   > > 
>   > 
>   > Thanks for clearing it up. I am gald I asked. Now, where should I
>   > define ATTRIBUTE_WEAK? Since it will be used in more than once
>   > place, it should be in somethere more general.
> For the mainline it belongs in gansidecl.h with the rest of the attribute
> definitions.
> 
>   Note that these attribute defines are not target specific defines and
Its use in frame.h is target specific.

>   defining them in gansidecl.h is clean and the right thing to do.  If you
>   look at the mainline you'll see that tm.h already includes gansidecl.h.
> 
> However, egcs-1.1 pre-dates the conversion to using gansidecl in a more
> consistent manner.  So I would recommend that you place the define for
> ATTRIBUTE_WEAK within crtstuff.c for the egcs-1.1 branch.
> 

Since those functions are delcared in frame.h, did you mean to say I
should put ATTRIBUTE_WEAK in frame.h?


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

Re: The tree.c patch breaks "make compare."

[Ovidiu Predescu]

On Tue, 23 Feb 1999 00:39:55 -0700, Jeffrey A Law <law@hurl.cygnus.com> wrote:

>   In message < u9iuctegi5.fsf@yorick.cygnus.com >you write:
>   > >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
>   > 
>   >  >   In message < u9ogmlesbh.fsf@yorick.cygnus.com >you write:
>   >  >>  >> Can someone please fix "make compare" before 1.1.2?
>   >  >> 
>   >  >>  > I don't think there's a good way to make it work, other than by not
>   >  >>  > comparing those files.
>   >  >> 
>   >  >> I don't see why the patch should affect those files; they have unique
>   >  >> definitions that we should be able to key off of.
>   > 
>   >  > There aren't any global symbols as far as I can tell in those files.  Th
>   > e
>   >  > only defined externs found by nm would be:
>   > 
>   >  > NXConstStr.o:
>   >  > 00000020 T _GLOBAL_.I._puke_law_egcs_1.1_gcc_objc_NXConstStr.mAcRlmb
>   >  > 00000004 R __objc_class_name_NXConstantString
>   > 
>   > Odd.  What does the compiler do with the method definitions?
> Not 100% sure, since I don't know what they look like as symbols.  Those
> files definitely have a boatload of local functions:
> 
> [ ... ]
> 000005a4 t _i_Object__perform_
> 000005f0 t _i_Object__perform_with_
> 00000644 t _i_Object__perform_with_with_
> 000006a0 t _i_Object__forward__
> 000006c8 t _i_Object__performv__
> 000006e0 t _c_Object__poseAs_
> 000006f4 t _i_Object__transmuteClassTo_
> 0000077c t _i_Object__subclassResponsibility_
> 000007b4 t _i_Object__notImplemented_
> 000007ec t _i_Object__shouldNotImplement_
> 00000844 t _i_Object__doesNotRecognize_
> 000008a4 t _i_Object__error_
> 000009fc t _c_Object__version
> 00000a18 t _c_Object__setVersion_
> 00000a34 t _c_Object__streamVersion_
> 00000a68 t _i_Object__read_
> 00000a74 t _i_Object__write_
> 00000a80 t _i_Object__awake
> 
> I don't know enough about ObjC to know if those are method definitions, and
> if so how user code would get to them since just about everything is static.

The compiler doesn't generate references to the methods themselves because in
ObjC the method binding is dynamic. Instead the compiler calls a function with
a method descriptor and the runtime returns the appropriate function. The
runtime is able to collect information about all the methods defined in all the
object files during the initialization process of the program.

Ovidiu

Re: The tree.c patch breaks "make compare."

[Jeffrey A Law]

  In message < 199902231633.IAA32127@hpcll563.cup.hp.com >you write:
  > The compiler doesn't generate references to the methods themselves because 
  > in ObjC the method binding is dynamic. Instead the compiler calls a
  > function with a method descriptor and the runtime returns the appropriate
  > function. The runtime is able to collect information about all the methods
  > defined in all the object files during the initialization process of the
  > program.
OK. Thanks for the clarification.

jeff

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10FKRf-000390C@ocean.lucon.org >you write:
  > >   > Thanks for clearing it up. I am gald I asked. Now, where should I
  > >   > define ATTRIBUTE_WEAK? Since it will be used in more than once
  > >   > place, it should be in somethere more general.
  > > For the mainline it belongs in gansidecl.h with the rest of the attribute
  > > definitions.
  > > 
  > >   Note that these attribute defines are not target specific defines and
  > Its use in frame.h is target specific.
HJ, there is nothing about that attribute that is target specific.  It's
just like the unused attribute, any other attribute.  There is NOTHING
target specific about it.

Please put the define in gansidecl.h with all the rest of the attribute
definitions for the mainline tree.

  > > However, egcs-1.1 pre-dates the conversion to using gansidecl in a more
  > > consistent manner.  So I would recommend that you place the define for
  > > ATTRIBUTE_WEAK within crtstuff.c for the egcs-1.1 branch.
  > > 
  > 
  > Since those functions are delcared in frame.h, did you mean to say I
  > should put ATTRIBUTE_WEAK in frame.h?
frame.h is fine for egcs-1.1 if that's where we'll actually use
ATTRIBUTE_WEAK.

jeff

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10AxqA-000392C@ocean.lucon.org >you write:
  > I have been trying to tell everyone that please include my library
  > versioining patch in egcs 1.1.1. But noone listened to me.
No, we rejected it as too risky.  "noone listened to me" is not a fair
characterization of what happened.  And I still believe it was the right
thing to do.


jeff

Re: The tree.c patch breaks "make compare."

[Jeffrey A Law]

  In message < u9iuctegi5.fsf@yorick.cygnus.com >you write:
  > >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  >  >   In message < u9ogmlesbh.fsf@yorick.cygnus.com >you write:
  >  >>  >> Can someone please fix "make compare" before 1.1.2?
  >  >> 
  >  >>  > I don't think there's a good way to make it work, other than by not
  >  >>  > comparing those files.
  >  >> 
  >  >> I don't see why the patch should affect those files; they have unique
  >  >> definitions that we should be able to key off of.
  > 
  >  > There aren't any global symbols as far as I can tell in those files.  Th
  > e
  >  > only defined externs found by nm would be:
  > 
  >  > NXConstStr.o:
  >  > 00000020 T _GLOBAL_.I._puke_law_egcs_1.1_gcc_objc_NXConstStr.mAcRlmb
  >  > 00000004 R __objc_class_name_NXConstantString
  > 
  > Odd.  What does the compiler do with the method definitions?
Not 100% sure, since I don't know what they look like as symbols.  Those
files definitely have a boatload of local functions:

[ ... ]
000005a4 t _i_Object__perform_
000005f0 t _i_Object__perform_with_
00000644 t _i_Object__perform_with_with_
000006a0 t _i_Object__forward__
000006c8 t _i_Object__performv__
000006e0 t _c_Object__poseAs_
000006f4 t _i_Object__transmuteClassTo_
0000077c t _i_Object__subclassResponsibility_
000007b4 t _i_Object__notImplemented_
000007ec t _i_Object__shouldNotImplement_
00000844 t _i_Object__doesNotRecognize_
000008a4 t _i_Object__error_
000009fc t _c_Object__version
00000a18 t _c_Object__setVersion_
00000a34 t _c_Object__streamVersion_
00000a68 t _i_Object__read_
00000a74 t _i_Object__write_
00000a80 t _i_Object__awake

I don't know enough about ObjC to know if those are method definitions, and
if so how user code would get to them since just about everything is static.

jeff

Re: The tree.c patch breaks "make compare."

[Jeffrey A Law]

  In message < m10F1XD-000390C@ocean.lucon.org >you write:
  > Hi, Jeff, Jason,
  > 
  > The append_random_chars/get_file_function_name_long changes in tree.c
  > in egcs 1.1.2 break "make compare" since you get a different mangled
  > name everytime when you compile some files. I got:
  > 
  > objc/NXConstStr.o differs
  > objc/Object.o differs
  > objc/Protocol.o differs
  > 
  > Can someone please fix "make compare" before 1.1.2?
I don't think there's a good way to make it work, other than by not comparing
those files.

They're part of the runtime, not the compiler itself.

jeff

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10Clsr-000392C@ocean.lucon.org >you write:
  > >   > incompatibilities.
  > >   > 
  > >   > The patch that should be in 1.1.2 is the weak symbols in crtbegin pat
  > ch.
  > > Can you please forward the "weak symbols" and "crtbegin" patch to me?  I
  > 
  > Here it is.
  > 
  > > assume this is something that is already in the mainline tree, right?
  > > 
  > 
  > No. But I thought it should :-).
OK.  I remember this one.  Someone said it was wrong and would cause problems,
so I put it away and didn't install it.

So are we agreed that this is a good patch now?

Jeff

  > 
  > 
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ----
  > Fri Dec 11 08:00:57 1998  H.J. Lu  (hjl@gnu.org)
  > 
  > 	* crtstuff.c (__register_frame_info, __deregister_frame_info):
  > 	If SUPPORTS_WEAK is none zero, make them weak and check if they
  > 	are none-zero before calling them.
  > 

Re: glibc2.1 [offtopic]

[H.J. Lu]

> I can't find one, which indicates how obscure the problem is.  The
> characteristics are: program linked with libstdc++ compiled by a
> compiler without your patch, run on system with libstdc++ compiled
> with your patch.
> 

You'd better to find a binary to show me my patch breaks anything.

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

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10EzM4-000390C@ocean.lucon.org >you write:
  > > 
  > >   > It looks to me that "#prama weak" is much more consistent than
  > >   > attribute in egcs 1.1.2. Those gthr-*h files are not old codes. They
  > >   > were added after we started egcs. I just copied what we had. Why now
  > >   > suddenly do you want something different? I hate to see we do things
  > >   > one way in one place and another way in a different place.
  > > No, it means that the gthr files are wrong and need to be fixed.
  > > 
  > 
  > Thanks for clearing it up. I am gald I asked. Now, where should I
  > define ATTRIBUTE_WEAK? Since it will be used in more than once
  > place, it should be in somethere more general.
For the mainline it belongs in gansidecl.h with the rest of the attribute
definitions.

  Note that these attribute defines are not target specific defines and
  defining them in gansidecl.h is clean and the right thing to do.  If you
  look at the mainline you'll see that tm.h already includes gansidecl.h.

However, egcs-1.1 pre-dates the conversion to using gansidecl in a more
consistent manner.  So I would recommend that you place the define for
ATTRIBUTE_WEAK within crtstuff.c for the egcs-1.1 branch.

We can/should deal with fixing gthr-* as an independent patch.

jeff

glibc2.1 [offtopic]

[nbecker]

I'm interested in trying out glibc2.1 on i686-pc-linux-gnu (kernel
2.2.1).

In the glibc2.1 FAQ it says that libstdc++ must be rebuilt.  So do I
understand correctly that I need to rebuild egcs-1.1.1 after
installing glibc2.1, and that all my existing c++ executables will
then be broken until they are relinked???

Re: glibc2.1 [offtopic]

[nbecker]

It sounds to me that we have a problem.  Glibc2.1 was announced to the
net, with a clear recommendation to replace glibc2.0.[1]  I think there's
going to be a bunch of unhappily surprised folks if they find all
their c++ binaries break - including all of kde, for example.  I don't
think this was clearly spelled out in the glibc2.1 release notes.  If
I understand this situation correctly, I suggest the glibc2.1
announcement be ammended to spell this out more clearly.

Footnotes: 
[1]  Yes, I know there are cautions that tell you not to try to
install glibc2.1 yourself unless you know what you are doing, but just 
the same, IMHO if we already know that all c++ binaries will break we
ought to tell everyone a lot more clearly.

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> It sounds to me that we have a problem.  Glibc2.1 was announced to the
> net, with a clear recommendation to replace glibc2.0.[1]  I think there's
> going to be a bunch of unhappily surprised folks if they find all
> their c++ binaries break - including all of kde, for example.  I don't
> think this was clearly spelled out in the glibc2.1 release notes.  If
> I understand this situation correctly, I suggest the glibc2.1
> announcement be ammended to spell this out more clearly.
> 
> Footnotes: 
> [1]  Yes, I know there are cautions that tell you not to try to
> install glibc2.1 yourself unless you know what you are doing, but just 
> the same, IMHO if we already know that all c++ binaries will break we
> ought to tell everyone a lot more clearly.
> 

Just use my egcs 1.1.x/Linux. Nothing should be broken.

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

Re: The tree.c patch breaks "make compare."

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

 >>  >> objc/NXConstStr.o differs
 >>  >> objc/Object.o differs
 >>  >> objc/Protocol.o differs
 >> 
 >> I don't see why the patch should affect those files; they have unique
 >> definitions that we should be able to key off of.

 > Have you tried to bootstrap egcs 1.1.2 on Linux/glibc2/x86?

Not yet.  I'm not denying that you are seeing problems; I'm just saying
that it's a bug rather than a design problem.

Jason

Re: The tree.c patch breaks "make compare."

[Jeffrey A Law]

  In message < 199902230325.WAA13877@blastula.phys.columbia.edu >you write:

  > Why are these files in gcc/objc and not libobjc?  Moving them out
  > would fix the problem.
Because the transition to a separate libobjc happened *after* egcs-1.1 was
branched.

ie, there is no libobjc in egcs-1.1.  The objc runtime is still sitting in
gcc/objc.


jeff

Re: glibc2.1 [offtopic]

[Zack Weinberg]

On Thu, 11 Feb 1999 07:15:42 -0800 (PST), H.J. Lu wrote:
>> 
>> I'm interested in trying out glibc2.1 on i686-pc-linux-gnu (kernel
>> 2.2.1).
>> 
>> In the glibc2.1 FAQ it says that libstdc++ must be rebuilt.  So do I
>> understand correctly that I need to rebuild egcs-1.1.1 after
>> installing glibc2.1, and that all my existing c++ executables will
>> then be broken until they are relinked???
>> 
>
>Yes. That is true.
>
>I have been trying to tell everyone that please include my library
>versioining patch in egcs 1.1.1. But noone listened to me. That is
>one reason why I have to mantain an egcs for Linux. 

Your library versioning patch is broken.  It does not fix the problem
you created it to fix.  Instead it creates more binary
incompatibilities.

The patch that should be in 1.1.2 is the weak symbols in crtbegin patch.

zw

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
>   > It looks to me that "#prama weak" is much more consistent than
>   > attribute in egcs 1.1.2. Those gthr-*h files are not old codes. They
>   > were added after we started egcs. I just copied what we had. Why now
>   > suddenly do you want something different? I hate to see we do things
>   > one way in one place and another way in a different place.
> No, it means that the gthr files are wrong and need to be fixed.
> 

Thanks for clearing it up. I am gald I asked. Now, where should I
define ATTRIBUTE_WEAK? Since it will be used in more than once
place, it should be in somethere more general.

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

Re: The tree.c patch breaks "make compare."

[Jeffrey A Law]

  In message < u9ogmlesbh.fsf@yorick.cygnus.com >you write:
  >  >> Can someone please fix "make compare" before 1.1.2?
  > 
  >  > I don't think there's a good way to make it work, other than by not
  >  > comparing those files.
  > 
  > I don't see why the patch should affect those files; they have unique
  > definitions that we should be able to key off of.
There aren't any global symbols as far as I can tell in those files.  The
only defined externs found by nm would be:

nm -g NXConstStr.o Protocol.o Object.o | grep -v U

NXConstStr.o:
00000020 T _GLOBAL_.I._puke_law_egcs_1.1_gcc_objc_NXConstStr.mAcRlmb
00000004 R __objc_class_name_NXConstantString

Protocol.o:
000001cc T _GLOBAL_.I._puke_law_egcs_1.1_gcc_objc_Protocol.m7Izrta
00000008 R __objc_class_name_Protocol

Object.o:
00000a8c T _GLOBAL_.I._puke_law_egcs_1.1_gcc_objc_Object.mVM1cga
00000004 ? __objc_class_name_Object


Presumably first_global_object_name is empty, which causes us to
call the "append_random_chars" code which in turn causes the comparison
failure.

jeff

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> On Thu, 11 Feb 1999 07:15:42 -0800 (PST), H.J. Lu wrote:
> >> 
> >> I'm interested in trying out glibc2.1 on i686-pc-linux-gnu (kernel
> >> 2.2.1).
> >> 
> >> In the glibc2.1 FAQ it says that libstdc++ must be rebuilt.  So do I
> >> understand correctly that I need to rebuild egcs-1.1.1 after
> >> installing glibc2.1, and that all my existing c++ executables will
> >> then be broken until they are relinked???
> >> 
> >
> >Yes. That is true.
> >
> >I have been trying to tell everyone that please include my library
> >versioining patch in egcs 1.1.1. But noone listened to me. That is
> >one reason why I have to mantain an egcs for Linux. 
> 
> Your library versioning patch is broken.  It does not fix the problem

Well, it is on the mainline now.

> you created it to fix.  Instead it creates more binary
> incompatibilities.
> 

It works for me. You never gave me a convincing example to show
it is broken. Maybe we have different opinions on what "broken"
means in this context.


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

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10EkjF-000390C@ocean.lucon.org >you write:
  > #if SUPPORT_WEAK
  > extern void foo (void) __attribute__ ((weak));
  > #endif
  > 
  > That means we need to match foo's prototype in 2 places. We can do
  > 
  > #if SUPPORT_WEAK
  > extern void foo (void) __attribute__ ((weak));
  > #else
  > extern void foo (void);
  > #endif
Define an ATTRIBUTE_WEAK then write
extern void foo (void) ATTRIBUTE_WEAK;

This is how we deal with this problem elsewhere.  I see no reason for this
code to behave any differently.


  > But I don't like it. "#prama weak" is the standard for SVR4 and
  > is cleaner than __attribute__ for this case.
But the GNU standard is to use attributes, not pragmas.

Use an attribute please.

jeff

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> I'm interested in trying out glibc2.1 on i686-pc-linux-gnu (kernel
> 2.2.1).
> 
> In the glibc2.1 FAQ it says that libstdc++ must be rebuilt.  So do I
> understand correctly that I need to rebuild egcs-1.1.1 after
> installing glibc2.1, and that all my existing c++ executables will
> then be broken until they are relinked???
> 

Yes. That is true.

I have been trying to tell everyone that please include my library
versioining patch in egcs 1.1.1. But noone listened to me. That is
one reason why I have to mantain an egcs for Linux. The good news is
I do have a version of egcs 1.1.1 for Linux. The bad news is since
there will be egcs 1.1.2, I canceled egcs 1.1.1/Linux. If you really
want to use egcs 1.1.1 on Linux, try

ftp://ftp.varesearch.com/pub/support/hjl/egcs/egcs-1.1.1-19990115-linux.diff.gz

If you install it instead of egcs 1.1.1, your existing c++ executables
should be ok.

FYI, I will make egcs 1.1.2/Linux shortly after egcs 1.1.2 is released
to public.

Thanks.

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

Re: glibc2.1 [offtopic]

[Marc Espie]

In article < m10EyNO-000390C@ocean.lucon.org > you write:
>>   In message < m10EkjF-000390C@ocean.lucon.org >you write:
>>   > #if SUPPORT_WEAK
>>   > extern void foo (void) __attribute__ ((weak));
>>   > #endif
>>   > 
>>   > That means we need to match foo's prototype in 2 places. We can do
>>   > 
>>   > #if SUPPORT_WEAK
>>   > extern void foo (void) __attribute__ ((weak));
>>   > #else
>>   > extern void foo (void);
>>   > #endif
>> Define an ATTRIBUTE_WEAK then write
>> extern void foo (void) ATTRIBUTE_WEAK;
>> 
>> This is how we deal with this problem elsewhere.  I see no reason for this
>> code to behave any differently.
>
>Have you really looked at how egcs deals with weak symbols for targets?
>I did

># cd gcc
># grep ATTRIBUTE_WEAK *
># grep "pragma[ \t]+weak" *
>gthr-posix.h:#pragma weak pthread_once
>gthr-posix.h:#pragma weak pthread_key_create
>gthr-posix.h:#pragma weak pthread_key_delete
>gthr-posix.h:#pragma weak pthread_getspecific
>gthr-posix.h:#pragma weak pthread_setspecific
>gthr-posix.h:#pragma weak pthread_create
>gthr-posix.h:#pragma weak pthread_mutex_lock 
>gthr-posix.h:#pragma weak pthread_mutex_trylock 
>gthr-posix.h:#pragma weak pthread_mutex_unlock 

Now, try to interpret the 3 last lines of gcc/config/openbsd.h 
with THAT in mind.

/* Otherwise, since we support weak, gthr.h errouneously tries to use
   #pragma weak. */
#define GTHREAD_USE_WEAK 0

Yep, that's right. You've got one operating system which *does* support
weak, but isn't  entirely too fond of #pragma, specifically does *not*
define HANDLE_SYSV_PRAGMA, and does not intend to unless something exterior
forces it too...

There are at least two issues to resolve there:
First, SUPPORTS_WEAK is definitely *not* a synonym for  
HANDLE_PRAGMA_WEAK, as defined *properly* in c-pragma.h
(maybe the definition should be moved to a more visible place, like
default.sh ?)

Second, attribute((weak)) is harder to use than pragma weak. Mainly,
#pragma weak acts as a lower level, where it only does change a symbol
property, whereas attribute((weak)) needs a proper declaration to work.
One pro is that it gets type-checking, and will work correctly for C++
identifiers. One con is that it is impossible to change the weakness status
of a symbol without knowing quite a lot about this symbol.

Maybe having the lower-level facility available without using pragma would
make sense ? Otherwise I see people continuing to use #pragma weak or,
failing that asm(".weak symbol"); to get around the type-checking system.

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> 
>   In message < m10EkjF-000390C@ocean.lucon.org >you write:
>   > #if SUPPORT_WEAK
>   > extern void foo (void) __attribute__ ((weak));
>   > #endif
>   > 
>   > That means we need to match foo's prototype in 2 places. We can do
>   > 
>   > #if SUPPORT_WEAK
>   > extern void foo (void) __attribute__ ((weak));
>   > #else
>   > extern void foo (void);
>   > #endif
> Define an ATTRIBUTE_WEAK then write
> extern void foo (void) ATTRIBUTE_WEAK;
> 
> This is how we deal with this problem elsewhere.  I see no reason for this
> code to behave any differently.

Have you really looked at how egcs deals with weak symbols for targets?
I did

# cd gcc
# grep ATTRIBUTE_WEAK *
# grep "pragma[ \t]+weak" *
gthr-dce.h:#pragma weak pthread_once
gthr-dce.h:#pragma weak pthread_once_init
gthr-dce.h:#pragma weak pthread_key_create
gthr-dce.h:#pragma weak pthread_key_delete
gthr-dce.h:#pragma weak pthread_getspecific
gthr-dce.h:#pragma weak pthread_setspecific
gthr-dce.h:#pragma weak pthread_create
gthr-dce.h:#pragma weak pthread_mutex_lock
gthr-dce.h:#pragma weak pthread_mutex_trylock
gthr-dce.h:#pragma weak pthread_mutex_unlock
gthr-posix.h:#pragma weak pthread_once
gthr-posix.h:#pragma weak pthread_key_create
gthr-posix.h:#pragma weak pthread_key_delete
gthr-posix.h:#pragma weak pthread_getspecific
gthr-posix.h:#pragma weak pthread_setspecific
gthr-posix.h:#pragma weak pthread_create
gthr-posix.h:#pragma weak pthread_mutex_lock 
gthr-posix.h:#pragma weak pthread_mutex_trylock 
gthr-posix.h:#pragma weak pthread_mutex_unlock 
gthr-solaris.h:#pragma weak thr_keycreate
gthr-solaris.h:#pragma weak thr_getspecific
gthr-solaris.h:#pragma weak thr_setspecific
gthr-solaris.h:#pragma weak thr_create
gthr-solaris.h:#pragma weak mutex_lock
gthr-solaris.h:#pragma weak mutex_trylock
gthr-solaris.h:#pragma weak mutex_unlock

> 
> 
>   > But I don't like it. "#prama weak" is the standard for SVR4 and
>   > is cleaner than __attribute__ for this case.
> But the GNU standard is to use attributes, not pragmas.
> 
> Use an attribute please.
> 

It looks to me that "#prama weak" is much more consistent than
attribute in egcs 1.1.2. Those gthr-*h files are not old codes. They
were added after we started egcs. I just copied what we had. Why now
suddenly do you want something different? I hate to see we do things
one way in one place and another way in a different place.


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

Re: glibc2.1 [offtopic]

[Zack Weinberg]

On Thu, 11 Feb 1999 08:08:17 -0800 (PST), H.J. Lu wrote:
>> >
>> >It works for me. You never gave me a convincing example to show
>> >it is broken. Maybe we have different opinions on what "broken"
>> >means in this context.
>> 
>> "It works for me" != "it works for everyone".
>> 
>> You localized a bunch of symbols that have been in libgcc since GCC1
>> and will never go away.  Things like _muldi3.  Those symbols are
>> re-exported by libc.  We can't take them out without breaking every
>> binary that needs them.
>> 
>
>I have compiled glibc 2.1 with my egcs 1.1.1/Linux and installed
>it on several RedHat 5.2 systems. Can you tell me which binary I
>should check?

I can't find one, which indicates how obscure the problem is.  The
characteristics are: program linked with libstdc++ compiled by a
compiler without your patch, run on system with libstdc++ compiled
with your patch.

zw

Re: The tree.c patch breaks "make compare."

[Zack Weinberg]

On Mon, 22 Feb 1999 19:21:05 -0800 (PST), H.J. Lu wrote:
>> 
>> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
>> 
>>  >   In message < m10F1XD-000390C@ocean.lucon.org >you write:
>>  >> Hi, Jeff, Jason,
>>  >> 
>>  >> The append_random_chars/get_file_function_name_long changes in tree.c
>>  >> in egcs 1.1.2 break "make compare" since you get a different mangled
>>  >> name everytime when you compile some files. I got:
>>  >> 
>>  >> objc/NXConstStr.o differs
>>  >> objc/Object.o differs
>>  >> objc/Protocol.o differs
>>  >> 
>>  >> Can someone please fix "make compare" before 1.1.2?
>> 
>>  > I don't think there's a good way to make it work, other than by not
>>  > comparing those files.
>> 
>> I don't see why the patch should affect those files; they have unique
>> definitions that we should be able to key off of.

Why are these files in gcc/objc and not libobjc?  Moving them out
would fix the problem.

zw

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10FKRf-000390C@ocean.lucon.org >you write:
  > >   > Thanks for clearing it up. I am gald I asked. Now, where should I
  > >   > define ATTRIBUTE_WEAK? Since it will be used in more than once
  > >   > place, it should be in somethere more general.
  > > For the mainline it belongs in gansidecl.h with the rest of the attribute
  > > definitions.
  > > 
  > >   Note that these attribute defines are not target specific defines and
  > Its use in frame.h is target specific.
HJ, there is nothing about that attribute that is target specific.  It's
just like the unused attribute, any other attribute.  There is NOTHING
target specific about it.

Please put the define in gansidecl.h with all the rest of the attribute
definitions for the mainline tree.

  > > However, egcs-1.1 pre-dates the conversion to using gansidecl in a more
  > > consistent manner.  So I would recommend that you place the define for
  > > ATTRIBUTE_WEAK within crtstuff.c for the egcs-1.1 branch.
  > > 
  > 
  > Since those functions are delcared in frame.h, did you mean to say I
  > should put ATTRIBUTE_WEAK in frame.h?
frame.h is fine for egcs-1.1 if that's where we'll actually use
ATTRIBUTE_WEAK.

jeff

Re: The tree.c patch breaks "make compare."

[H.J. Lu]

> 
> 
> 
>   In message < m10F1XD-000390C@ocean.lucon.org >you write:
>   > Hi, Jeff, Jason,
>   > 
>   > The append_random_chars/get_file_function_name_long changes in tree.c
>   > in egcs 1.1.2 break "make compare" since you get a different mangled
>   > name everytime when you compile some files. I got:
>   > 
>   > objc/NXConstStr.o differs
>   > objc/Object.o differs
>   > objc/Protocol.o differs
>   > 
>   > Can someone please fix "make compare" before 1.1.2?
> I don't think there's a good way to make it work, other than by not comparing
> those files.
> 

Anything is fine with me as long as "make compare" doesn't fail
because of it.


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

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < 199902111536.KAA17829@blastula.phys.columbia.edu >you write:
  > On Thu, 11 Feb 1999 07:15:42 -0800 (PST), H.J. Lu wrote:
  > >> 
  > >> I'm interested in trying out glibc2.1 on i686-pc-linux-gnu (kernel
  > >> 2.2.1).
  > >> 
  > >> In the glibc2.1 FAQ it says that libstdc++ must be rebuilt.  So do I
  > >> understand correctly that I need to rebuild egcs-1.1.1 after
  > >> installing glibc2.1, and that all my existing c++ executables will
  > >> then be broken until they are relinked???
  > >> 
  > >
  > >Yes. That is true.
  > >
  > >I have been trying to tell everyone that please include my library
  > >versioining patch in egcs 1.1.1. But noone listened to me. That is
  > >one reason why I have to mantain an egcs for Linux. 
  > 
  > Your library versioning patch is broken.  It does not fix the problem
  > you created it to fix.  Instead it creates more binary
  > incompatibilities.
  > 
  > The patch that should be in 1.1.2 is the weak symbols in crtbegin patch.
Can you please forward the "weak symbols" and "crtbegin" patch to me?  I
assume this is something that is already in the mainline tree, right?

jeff

Re: glibc2.1 [offtopic]

[H.J. Lu]

> >
> >It works for me. You never gave me a convincing example to show
> >it is broken. Maybe we have different opinions on what "broken"
> >means in this context.
> 
> "It works for me" != "it works for everyone".
> 
> You localized a bunch of symbols that have been in libgcc since GCC1
> and will never go away.  Things like _muldi3.  Those symbols are
> re-exported by libc.  We can't take them out without breaking every
> binary that needs them.
> 

I have compiled glibc 2.1 with my egcs 1.1.1/Linux and installed
it on several RedHat 5.2 systems. Can you tell me which binary I
should check?


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

Re: The tree.c patch breaks "make compare."

[H.J. Lu]

> 
> >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
> 
>  >   In message < m10F1XD-000390C@ocean.lucon.org >you write:
>  >> Hi, Jeff, Jason,
>  >> 
>  >> The append_random_chars/get_file_function_name_long changes in tree.c
>  >> in egcs 1.1.2 break "make compare" since you get a different mangled
>  >> name everytime when you compile some files. I got:
>  >> 
>  >> objc/NXConstStr.o differs
>  >> objc/Object.o differs
>  >> objc/Protocol.o differs
>  >> 
>  >> Can someone please fix "make compare" before 1.1.2?
> 
>  > I don't think there's a good way to make it work, other than by not
>  > comparing those files.
> 
> I don't see why the patch should affect those files; they have unique
> definitions that we should be able to key off of.
> 

Have you tried to bootstrap egcs 1.1.2 on Linux/glibc2/x86?


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

Re: The tree.c patch breaks "make compare."

[Ovidiu Predescu]

On Tue, 23 Feb 1999 00:39:55 -0700, Jeffrey A Law <law@hurl.cygnus.com> wrote:

>   In message < u9iuctegi5.fsf@yorick.cygnus.com >you write:
>   > >>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:
>   > 
>   >  >   In message < u9ogmlesbh.fsf@yorick.cygnus.com >you write:
>   >  >>  >> Can someone please fix "make compare" before 1.1.2?
>   >  >> 
>   >  >>  > I don't think there's a good way to make it work, other than by not
>   >  >>  > comparing those files.
>   >  >> 
>   >  >> I don't see why the patch should affect those files; they have unique
>   >  >> definitions that we should be able to key off of.
>   > 
>   >  > There aren't any global symbols as far as I can tell in those files.  Th
>   > e
>   >  > only defined externs found by nm would be:
>   > 
>   >  > NXConstStr.o:
>   >  > 00000020 T _GLOBAL_.I._puke_law_egcs_1.1_gcc_objc_NXConstStr.mAcRlmb
>   >  > 00000004 R __objc_class_name_NXConstantString
>   > 
>   > Odd.  What does the compiler do with the method definitions?
> Not 100% sure, since I don't know what they look like as symbols.  Those
> files definitely have a boatload of local functions:
> 
> [ ... ]
> 000005a4 t _i_Object__perform_
> 000005f0 t _i_Object__perform_with_
> 00000644 t _i_Object__perform_with_with_
> 000006a0 t _i_Object__forward__
> 000006c8 t _i_Object__performv__
> 000006e0 t _c_Object__poseAs_
> 000006f4 t _i_Object__transmuteClassTo_
> 0000077c t _i_Object__subclassResponsibility_
> 000007b4 t _i_Object__notImplemented_
> 000007ec t _i_Object__shouldNotImplement_
> 00000844 t _i_Object__doesNotRecognize_
> 000008a4 t _i_Object__error_
> 000009fc t _c_Object__version
> 00000a18 t _c_Object__setVersion_
> 00000a34 t _c_Object__streamVersion_
> 00000a68 t _i_Object__read_
> 00000a74 t _i_Object__write_
> 00000a80 t _i_Object__awake
> 
> I don't know enough about ObjC to know if those are method definitions, and
> if so how user code would get to them since just about everything is static.

The compiler doesn't generate references to the methods themselves because in
ObjC the method binding is dynamic. Instead the compiler calls a function with
a method descriptor and the runtime returns the appropriate function. The
runtime is able to collect information about all the methods defined in all the
object files during the initialization process of the program.

Ovidiu

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10EyNO-000390C@ocean.lucon.org >you write:

  > Have you really looked at how egcs deals with weak symbols for targets?
  > I did
[ ... ]
This doesn't make it right.

Use an attribute.  I will not ask again.

  > It looks to me that "#prama weak" is much more consistent than
  > attribute in egcs 1.1.2. Those gthr-*h files are not old codes. They
  > were added after we started egcs. I just copied what we had. Why now
  > suddenly do you want something different? I hate to see we do things
  > one way in one place and another way in a different place.
No, it means that the gthr files are wrong and need to be fixed.

jeff
  > 

Re: glibc2.1 [offtopic]

[Zack Weinberg]

On Thu, 11 Feb 1999 07:44:24 -0800 (PST), H.J. Lu wrote:
>> 
>> On Thu, 11 Feb 1999 07:15:42 -0800 (PST), H.J. Lu wrote:
>> >> 
>> >> I'm interested in trying out glibc2.1 on i686-pc-linux-gnu (kernel
>> >> 2.2.1).
>> >> 
>> >> In the glibc2.1 FAQ it says that libstdc++ must be rebuilt.  So do I
>> >> understand correctly that I need to rebuild egcs-1.1.1 after
>> >> installing glibc2.1, and that all my existing c++ executables will
>> >> then be broken until they are relinked???
>> >> 
>> >
>> >Yes. That is true.
>> >
>> >I have been trying to tell everyone that please include my library
>> >versioining patch in egcs 1.1.1. But noone listened to me. That is
>> >one reason why I have to mantain an egcs for Linux. 
>> 
>> Your library versioning patch is broken.  It does not fix the problem
>
>Well, it is on the mainline now.

Are we talking about the same patch?  The one I don't like is the one
that localizes a bunch of symbols in libgcc.a.  AFAIK it hasn't gone in.

>> you created it to fix.  Instead it creates more binary
>> incompatibilities.
>
>It works for me. You never gave me a convincing example to show
>it is broken. Maybe we have different opinions on what "broken"
>means in this context.

"It works for me" != "it works for everyone".

You localized a bunch of symbols that have been in libgcc since GCC1
and will never go away.  Things like _muldi3.  Those symbols are
re-exported by libc.  We can't take them out without breaking every
binary that needs them.

zw

Re: glibc2.1 [offtopic]

[H.J. Lu]

>   > incompatibilities.
>   > 
>   > The patch that should be in 1.1.2 is the weak symbols in crtbegin patch.
> Can you please forward the "weak symbols" and "crtbegin" patch to me?  I

Here it is.

> assume this is something that is already in the mainline tree, right?
> 

No. But I thought it should :-).



-- 
H.J. Lu (hjl@gnu.org)
----
Fri Dec 11 08:00:57 1998  H.J. Lu  (hjl@gnu.org)

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

--- ../../../import/egcs/gcc/crtstuff.c	Tue Jul 14 07:16:05 1998
+++ ./crtstuff.c	Fri Dec 11 08:59:56 1998
@@ -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 SUPPORTS_WEAK
+#pragma weak __register_frame_info
+#pragma weak __deregister_frame_info
+#endif
 #endif
 
 #ifdef OBJECT_FORMAT_ELF
@@ -142,7 +147,10 @@
     }
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+#if SUPPORTS_WEAK
+  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 SUPPORTS_WEAK
+  if (__register_frame_info)
+#endif
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 
 static void __attribute__ ((__unused__))
@@ -254,7 +265,10 @@
     (*p) ();
 
 #ifdef EH_FRAME_SECTION_ASM_OP
-  __deregister_frame_info (__EH_FRAME_BEGIN__);
+#if SUPPORTS_WEAK
+  if (__deregister_frame_info)
+#endif
+    __deregister_frame_info (__EH_FRAME_BEGIN__);
 #endif
 }
 
@@ -266,7 +280,10 @@
 __frame_dummy ()
 {
   static struct object object;
-  __register_frame_info (__EH_FRAME_BEGIN__, &object);
+#if SUPPORTS_WEAK
+  if (__register_frame_info)
+#endif
+    __register_frame_info (__EH_FRAME_BEGIN__, &object);
 }
 #endif
 #endif

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> 
> 
>   In message < m10EzM4-000390C@ocean.lucon.org >you write:
>   > > 
>   > >   > It looks to me that "#prama weak" is much more consistent than
>   > >   > attribute in egcs 1.1.2. Those gthr-*h files are not old codes. They
>   > >   > were added after we started egcs. I just copied what we had. Why now
>   > >   > suddenly do you want something different? I hate to see we do things
>   > >   > one way in one place and another way in a different place.
>   > > No, it means that the gthr files are wrong and need to be fixed.
>   > > 
>   > 
>   > Thanks for clearing it up. I am gald I asked. Now, where should I
>   > define ATTRIBUTE_WEAK? Since it will be used in more than once
>   > place, it should be in somethere more general.
> For the mainline it belongs in gansidecl.h with the rest of the attribute
> definitions.
> 
>   Note that these attribute defines are not target specific defines and
Its use in frame.h is target specific.

>   defining them in gansidecl.h is clean and the right thing to do.  If you
>   look at the mainline you'll see that tm.h already includes gansidecl.h.
> 
> However, egcs-1.1 pre-dates the conversion to using gansidecl in a more
> consistent manner.  So I would recommend that you place the define for
> ATTRIBUTE_WEAK within crtstuff.c for the egcs-1.1 branch.
> 

Since those functions are delcared in frame.h, did you mean to say I
should put ATTRIBUTE_WEAK in frame.h?


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

Re: glibc2.1 [offtopic]

[Jeffrey A Law]

  In message < m10Clsr-000392C@ocean.lucon.org >you write:
  > >   > incompatibilities.
  > >   > 
  > >   > The patch that should be in 1.1.2 is the weak symbols in crtbegin pat
  > ch.
  > > Can you please forward the "weak symbols" and "crtbegin" patch to me?  I
  > 
  > Here it is.
  > 
  > > assume this is something that is already in the mainline tree, right?
  > > 
  > 
  > No. But I thought it should :-).
  > 
  > 
  > 
  > -- 
  > H.J. Lu (hjl@gnu.org)
  > ----
  > Fri Dec 11 08:00:57 1998  H.J. Lu  (hjl@gnu.org)
  > 
  > 	* crtstuff.c (__register_frame_info, __deregister_frame_info):
  > 	If SUPPORTS_WEAK is none zero, make them weak and check if they
  > 	are none-zero before calling them.
I went back and reviewed this discussion of this patch.

Use an attribute instead of a pragmas.

Kill the unnecessary #ifdefs around the test for nonzero.  This code is not
time critical at all, so the extra if (funcname) isn't going to have any
noticable performance impact.

These are the same things I asked you to do in December.

jeff

Re: The tree.c patch breaks "make compare."

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < m10F1XD-000390C@ocean.lucon.org >you write:
 >> Hi, Jeff, Jason,
 >> 
 >> The append_random_chars/get_file_function_name_long changes in tree.c
 >> in egcs 1.1.2 break "make compare" since you get a different mangled
 >> name everytime when you compile some files. I got:
 >> 
 >> objc/NXConstStr.o differs
 >> objc/Object.o differs
 >> objc/Protocol.o differs
 >> 
 >> Can someone please fix "make compare" before 1.1.2?

 > I don't think there's a good way to make it work, other than by not
 > comparing those files.

I don't see why the patch should affect those files; they have unique
definitions that we should be able to key off of.

Jason

The tree.c patch breaks "make compare."

[H.J. Lu]

Hi, Jeff, Jason,

The append_random_chars/get_file_function_name_long changes in tree.c
in egcs 1.1.2 break "make compare" since you get a different mangled
name everytime when you compile some files. I got:

objc/NXConstStr.o differs
objc/Object.o differs
objc/Protocol.o differs

Can someone please fix "make compare" before 1.1.2?

Thanks.


H.J.

Re: The tree.c patch breaks "make compare."

[Jeffrey A Law]

  In message < 199902231633.IAA32127@hpcll563.cup.hp.com >you write:
  > The compiler doesn't generate references to the methods themselves because 
  > in ObjC the method binding is dynamic. Instead the compiler calls a
  > function with a method descriptor and the runtime returns the appropriate
  > function. The runtime is able to collect information about all the methods
  > defined in all the object files during the initialization process of the
  > program.
OK. Thanks for the clarification.

jeff

Re: glibc2.1 [offtopic]

[H.J. Lu]

> >
> >Well, it is on the mainline now.
> 
> Are we talking about the same patch?  The one I don't like is the one

No. I was talking about

Sat Jun 27 19:06:04 1998  H.J. Lu  (hjl@gnu.org)

        * configure (gxx_include_dir): Changed to
        '${prefix}/include/g++'-${libstdcxx_interface}.

        * config.if: New to determine the interfaces.
.....

> 
> >> you created it to fix.  Instead it creates more binary
> >> incompatibilities.
> >
> >It works for me. You never gave me a convincing example to show
> >it is broken. Maybe we have different opinions on what "broken"
> >means in this context.
> 
> "It works for me" != "it works for everyone".
> 
> You localized a bunch of symbols that have been in libgcc since GCC1
> and will never go away.  Things like _muldi3.  Those symbols are
> re-exported by libc.  We can't take them out without breaking every
> binary that needs them.

It is up to libc to export it, not libgcc. It still works for me.
_muldi3 is global even with my libgcc.map patch.

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

Re: The tree.c patch breaks "make compare."

[Jason Merrill]

>>>>> Jeffrey A Law <law@hurl.cygnus.com> writes:

 >   In message < u9ogmlesbh.fsf@yorick.cygnus.com >you write:
 >>  >> Can someone please fix "make compare" before 1.1.2?
 >> 
 >>  > I don't think there's a good way to make it work, other than by not
 >>  > comparing those files.
 >> 
 >> I don't see why the patch should affect those files; they have unique
 >> definitions that we should be able to key off of.

 > There aren't any global symbols as far as I can tell in those files.  The
 > only defined externs found by nm would be:

 > NXConstStr.o:
 > 00000020 T _GLOBAL_.I._puke_law_egcs_1.1_gcc_objc_NXConstStr.mAcRlmb
 > 00000004 R __objc_class_name_NXConstantString

Odd.  What does the compiler do with the method definitions?

Jason

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> 
> 
>   In message < m10Clsr-000392C@ocean.lucon.org >you write:
>   > >   > incompatibilities.
>   > >   > 
>   > >   > The patch that should be in 1.1.2 is the weak symbols in crtbegin pat
>   > ch.
>   > > Can you please forward the "weak symbols" and "crtbegin" patch to me?  I
>   > 
>   > Here it is.
>   > 
>   > > assume this is something that is already in the mainline tree, right?
>   > > 
>   > 
>   > No. But I thought it should :-).
>   > 
>   > 
>   > 
>   > -- 
>   > H.J. Lu (hjl@gnu.org)
>   > ----
>   > Fri Dec 11 08:00:57 1998  H.J. Lu  (hjl@gnu.org)
>   > 
>   > 	* crtstuff.c (__register_frame_info, __deregister_frame_info):
>   > 	If SUPPORTS_WEAK is none zero, make them weak and check if they
>   > 	are none-zero before calling them.
> I went back and reviewed this discussion of this patch.
> 
> Use an attribute instead of a pragmas.
> 
> Kill the unnecessary #ifdefs around the test for nonzero.  This code is not
> time critical at all, so the extra if (funcname) isn't going to have any
> noticable performance impact.
> 
> These are the same things I asked you to do in December.
> 

I was on vacation in December. I may have missed your email. The
problem with attribute is you have to do

extern void foo (void);

......

#if SUPPORT_WEAK
extern void foo (void) __attribute__ ((weak));
#endif

That means we need to match foo's prototype in 2 places. We can do

#if SUPPORT_WEAK
extern void foo (void) __attribute__ ((weak));
#else
extern void foo (void);
#endif

But I don't like it. "#prama weak" is the standard for SVR4 and
is cleaner than __attribute__ for this case.


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

Re: glibc2.1 [offtopic]

[Paul Derbyshire]

How the hell did this get to the list when it was missent to
"egcs@cyngus.com"? (Note the typo!) It oughto've bounced with "host
unknown". Instead it succeeded in being posted to the list, whereby it
dodged both my filter for egcs@egcs.cygnus.com mail and the new filter I
set up to catch egcs@cygnus.com.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: glibc2.1 [offtopic]

[Jonathan Larmour]

In article <199902222345.AAA06230.cygnus.egcs@quatramaran.ens.fr> you write:
>In article < m10EyNO-000390C@ocean.lucon.org > you write:
>
>Second, attribute((weak)) is harder to use than pragma weak. Mainly,
>#pragma weak acts as a lower level, where it only does change a symbol
>property, whereas attribute((weak)) needs a proper declaration to work.
>One pro is that it gets type-checking, and will work correctly for C++
>identifiers. One con is that it is impossible to change the weakness status
>of a symbol without knowing quite a lot about this symbol.

I don't see the problem - it needs to be done in the place the function
is defined in any case. And even then you could use __typeof. The
following would probably work:

#define MAKEWEAK(_name_) extern __typeof (_name_) _name_
__attribute__((weak));

And just use MAKEWEAK(myfun) in the same place as you would use #pragma
weak.
Just a guess though.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"Women marry hoping their husbands will change, men||Home e-mail: jifl @ 
marry hoping their wives never do. Both are rare." ||     jifvik.demon.co.uk
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> On Mon, 22 Feb 1999 09:41:16 -0800 (PST), H.J. Lu wrote:
> >> 
> >>   > It looks to me that "#prama weak" is much more consistent than
> >>   > attribute in egcs 1.1.2. Those gthr-*h files are not old codes. They
> >>   > were added after we started egcs. I just copied what we had. Why now
> >>   > suddenly do you want something different? I hate to see we do things
> >>   > one way in one place and another way in a different place.
> >> No, it means that the gthr files are wrong and need to be fixed.
> >> 
> >
> >Thanks for clearing it up. I am gald I asked. Now, where should I
> >define ATTRIBUTE_WEAK? Since it will be used in more than once
> >place, it should be in somethere more general.
> 
> With the rest of 'em, in gansidecl.h?
> 

I don't think gansidecl.h is the place for the target macros.


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

Re: glibc2.1 [offtopic]

[Jonathan Larmour]

In article <199902222345.AAA06230.cygnus.egcs@quatramaran.ens.fr> you write:
>In article < m10EyNO-000390C@ocean.lucon.org > you write:
>
>Second, attribute((weak)) is harder to use than pragma weak. Mainly,
>#pragma weak acts as a lower level, where it only does change a symbol
>property, whereas attribute((weak)) needs a proper declaration to work.
>One pro is that it gets type-checking, and will work correctly for C++
>identifiers. One con is that it is impossible to change the weakness status
>of a symbol without knowing quite a lot about this symbol.

I don't see the problem - it needs to be done in the place the function
is defined in any case. And even then you could use __typeof. The
following would probably work:

#define MAKEWEAK(_name_) extern __typeof (_name_) _name_
__attribute__((weak));

And just use MAKEWEAK(myfun) in the same place as you would use #pragma
weak.
Just a guess though.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"Women marry hoping their husbands will change, men||Home e-mail: jifl @ 
marry hoping their wives never do. Both are rare." ||     jifvik.demon.co.uk
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: glibc2.1 [offtopic]

[H.J. Lu]

> 
> On Mon, 22 Feb 1999 09:41:16 -0800 (PST), H.J. Lu wrote:
> >> 
> >>   > It looks to me that "#prama weak" is much more consistent than
> >>   > attribute in egcs 1.1.2. Those gthr-*h files are not old codes. They
> >>   > were added after we started egcs. I just copied what we had. Why now
> >>   > suddenly do you want something different? I hate to see we do things
> >>   > one way in one place and another way in a different place.
> >> No, it means that the gthr files are wrong and need to be fixed.
> >> 
> >
> >Thanks for clearing it up. I am gald I asked. Now, where should I
> >define ATTRIBUTE_WEAK? Since it will be used in more than once
> >place, it should be in somethere more general.
> 
> With the rest of 'em, in gansidecl.h?
> 

I don't think gansidecl.h is the place for the target macros.


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

Re: glibc2.1 [offtopic]

[Paul Derbyshire]

How the hell did this get to the list when it was missent to
"egcs@cyngus.com"? (Note the typo!) It oughto've bounced with "host
unknown". Instead it succeeded in being posted to the list, whereby it
dodged both my filter for egcs@egcs.cygnus.com mail and the new filter I
set up to catch egcs@cygnus.com.

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|