Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)

Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)

[Haren Visavadia]

--- Kean Johnston <jkj@sco.com> wrote:
> System V Release 5 (UnixWare / OpenServer 6).
> 
 
Your system is NOT supported by GCC, please read
http://www.fsf.org/licensing/sco/




		
___________________________________________________________ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)

[Kean Johnston]

> Your system is NOT supported by GCC, please read
> http://www.fsf.org/licensing/sco/
Perhaps you should read README.SCO at the top of the GCC tree?

And for your information, SCO is supported by GCC. I am the
maintainer, and a few malcontents like yourself aside, I
have had little trouble doing so. Please do not confuse
my personal contribution to open source with my employers
position based on a legal matter that they are using the
courts to address.

I wish you much success and happiness.

Kean

Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)

[Haren Visavadia]

--- Kean Johnston wrote:
> Perhaps you should read README.SCO at the top of the
> GCC tree?

README.SCO contains:

"
The GCC team has been urged to drop support for SCO
Unix from GCC, as
a protest against SCO's irresponsible aggression
against free software
and GNU/Linux.  We have decided to take no action at
this time, as we
no longer believe that SCO is a serious threat.

For more on the FSF's position regarding SCO's attacks
on free
software, please read:

 http://www.fsf.org/licensing/sco/
"

May be YOU should read it.






	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)

[Kean Johnston]

> The GCC team has been urged to drop support for SCO
> Unix from GCC, as a protest against SCO's irresponsible
 > aggression against free software and GNU/Linux.
 > We have decided to take no action at this time, as we
> no longer believe that SCO is a serious threat.

What part of *NO ACTION* was unclear to you?

> 
> For more on the FSF's position regarding SCO's attacks
> on free software, please read:
> 
>  http://www.fsf.org/licensing/sco/

Where in any of those pages does it state that GCC is not
supported on SCO? Or that *any other GNU project* is not
supported on SCO?

I was taught never to enter a battle of wits with an
unarmed opponent, so I shall simply exercise my right
to ignore any future drivel from you.

# find . -name ChangeLog\* | xargs grep -iE 'Haren|themis' | wc -l
0
# find . -name ChangeLog\* | xargs grep -iE 'kean|jkj' | wc -l
21

I rest my case.

Kean

Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)

[Haren Visavadia]

--- Kean Johnston wrote:
> > The GCC team has been urged to drop support for
> SCO
> > Unix from GCC, as a protest against SCO's
> irresponsible
>  > aggression against free software and GNU/Linux.
>  > We have decided to take no action at this time,
> as we
> > no longer believe that SCO is a serious threat.
> 
> What part of *NO ACTION* was unclear to you?

You missed "The GCC team has been urged to drop
support for SCO Unix from GCC, as a protest against
SCO's irresponsible aggression against free software".








	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)

[Gabriel Dos Reis]

Haren Visavadia <themis_hv@yahoo.co.uk> writes:

| --- Kean Johnston wrote:
| > > The GCC team has been urged to drop support for
| > SCO
| > > Unix from GCC, as a protest against SCO's
| > irresponsible
| >  > aggression against free software and GNU/Linux.
| >  > We have decided to take no action at this time,
| > as we
| > > no longer believe that SCO is a serious threat.
| > 
| > What part of *NO ACTION* was unclear to you?
| 
| You missed "The GCC team has been urged to drop
| support for SCO Unix from GCC, as a protest against
| SCO's irresponsible aggression against free software".

Please stop your nonsensical selective quotes.  If you're going to
quote, please do so fully.  Otherwise, refrain from spreading FUD.

-- Gaby

Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)

[Kai Ruottu]

Haren Visavadia wrote:

> You missed "The GCC team has been urged to drop
> support for SCO Unix from GCC, as a protest against
> SCO's irresponsible aggression against free software".

  When starting my Unix learnings with SCO Xenix/286,
SCO Xenix/386 and SCO Unix (all some kind of trademarks),
I have always wondered what on earth this really meaned.

  Did it mean that the support for SCO Unix, the '3.2.[2-4]'
was dropped but the support for SCO OpenServer5 and SCO
UnixWare were continued or what?  Can it be so hard to ask
someone who knows something about the SCO products to write
some sane clauses to the FSF documents ?

  Maybe "SCO Unix" means something else for Haren and some
FSF people but my thought is that the majority understands
it to mean the SCO's SVR3.2 release from the late 80's and
early 90's... Ok, the heir for SCO Unix is the OSR5 but the
UnixWare got from Univel/Novell has always been called as
"UnixWare" so "SCO Unix" cannot be called so... If the "SCO
Unix" means all the SVR4 and SVR5 based Unices, then also
AIX, Solaris2, HP-UX, Irix and others were dropped from all
support....

Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)

[Kean Johnston]

Hi all,

I hope someone can help me. I am C++ impaired, and I am getting
the following error when trying to bootstrap the current 4.0.2
CVS. The error is coming from include/ext/bitmap_allocator.h
line 111. The relevant code snippet is:

class _Mutex {
   __gthread_mutex_t _M_mut;

   // Prevent Copying and assignment.
   _Mutex(_Mutex const&);
   _Mutex& operator=(_Mutex const&);

  public:
   _Mutex()
   {
     if (__threads_enabled)
       {
#if !defined __GTHREAD_MUTEX_INIT
         _GTHREAD_MUTEX_INIT_FUNCTION(&_M_mut);
#else
         __gthread_mutex_t __mtemp = __GTHREAD_MUTEX_INIT;
         _M_mut = __mtemp;    <<<<<<<< THIS CAUSES THE ERROR
#endif
       }
   }

I get the following error message from the compiler:
error: no match for 'operator=' in 
'((__gnu_cxx::_Mutex)this)->__gnu_cxx::_Mutex::_M_Mut = __mtemp'

*/gcc/include/sys/types.h:678: note: candidates are: __pthread_mutex& 
__pthread_mutex::operator=(const __pthread_mutex&)

The contents of sys/types.h at that location are:
typedef volatile struct __pthread_mutex {
    mutex_t		__pt_mutex_mutex;
    pid_t		__pt_mutex_pid;
    thread_t		__pt_mutex_owner;
    int			__pt_mutex_depth;
    pthread_mutexattr_t	__pt_mutex_attr;
} pthread_mutex_t;

If I remove the 'volatile' keyword, then everything just works.
So, do I adjust fixincludes to remove the 'volatile' keyword,
or is this some weird side effect of the recent discussions on
volatile (which I didn't read).

Any help / advice appreciated.

Oh PS ... if I change that from a simple assignment to:
   __builtin_memcpy((void *)&_M_mut, (const void *)&__mtemp, 
sizeof(__gthread_mutex_t));
Then it also just works. I could of course adjust the header file
to do that for the platform.

Kean

Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)

[Michael Veksler]

Kean Johnston wrote on 22/07/2005 00:41:06:
[...]
>
> I hope someone can help me. I am C++ impaired, and I am getting
> the following error when trying to bootstrap the current 4.0.2
> CVS. The error is coming from include/ext/bitmap_allocator.h
> line 111. The relevant code snippet is:
>
> class _Mutex {
>    __gthread_mutex_t _M_mut;
>
>    // Prevent Copying and assignment.
>    _Mutex(_Mutex const&);
>    _Mutex& operator=(_Mutex const&);
>
>   public:
>    _Mutex()
>    {
>      if (__threads_enabled)
>        {
> #if !defined __GTHREAD_MUTEX_INIT
>          _GTHREAD_MUTEX_INIT_FUNCTION(&_M_mut);
> #else
>          __gthread_mutex_t __mtemp = __GTHREAD_MUTEX_INIT;
>          _M_mut = __mtemp;    <<<<<<<< THIS CAUSES THE ERROR
> #endif
>        }
>    }
>
> I get the following error message from the compiler:
> error: no match for 'operator=' in
> '((__gnu_cxx::_Mutex)this)->__gnu_cxx::_Mutex::_M_Mut = __mtemp'
>
> */gcc/include/sys/types.h:678: note: candidates are: __pthread_mutex&
> __pthread_mutex::operator=(const __pthread_mutex&)
>
> The contents of sys/types.h at that location are:
> typedef volatile struct __pthread_mutex {
>     mutex_t      __pt_mutex_mutex;
>     pid_t      __pt_mutex_pid;
>     thread_t      __pt_mutex_owner;
>     int         __pt_mutex_depth;
>     pthread_mutexattr_t   __pt_mutex_attr;
> } pthread_mutex_t;
>
> If I remove the 'volatile' keyword, then everything just works.
> So, do I adjust fixincludes to remove the 'volatile' keyword,
> or is this some weird side effect of the recent discussions on
> volatile (which I didn't read).
>

The error makes perfect sense. __pthread_mutex has only one
assignment operator for it (implicitly generated by the compiler):
   __pthread_mutex & operator=(const __pthread_mutex&).
When you try to pass a volatile __pthread_mutex (named as
pthread_mutex_t), the compiler can't pass it to the assignment
operator - because then `volatile' would be stripped off the
reference.

I have created a small test case to demonstrate this:
  typedef volatile struct A{} Av;
  void foo()
  {
     Av x;
     x = Av();
  }

This test gives an error with any compiler I could tested it with:
   gcc-2.96, gcc-3.2.1, gcc-4.0.0, xlC-6.0.0


> Any help / advice appreciated.
>
> Oh PS ... if I change that from a simple assignment to:
>    __builtin_memcpy((void *)&_M_mut, (const void *)&__mtemp,
> sizeof(__gthread_mutex_t));

I don't think it is a good idea in general to cast `volatile' away
from _M_mut in that way. I am not sure, but that may trigger
undefined behavior (the object is volatile, but it is being modified
through a non-volatile pointer). And this concern comes out from
the long thread on volatile.

Another option would be to define __gthread_mutex_t in terms of
struct __pthread_mutex
rather than using the volatile typedef.


> Then it also just works. I could of course adjust the header file
> to do that for the platform.
>

Do you know why the type itself is defined as volatile, as opposed to
declaring only relevant variables as volatile? What system is it anyway?

  Michael

Re: Problem compiling libstdc++ is current 4.0.2 cvs (volatile strikes again)

[Kean Johnston]

> The error makes perfect sense. __pthread_mutex has only one
> assignment operator for it (implicitly generated by the compiler):
>    __pthread_mutex & operator=(const __pthread_mutex&).
> When you try to pass a volatile __pthread_mutex (named as
> pthread_mutex_t), the compiler can't pass it to the assignment
> operator - because then `volatile' would be stripped off the
> reference.
> 
> I have created a small test case to demonstrate this:
>   typedef volatile struct A{} Av;
>   void foo()
>   {
>      Av x;
>      x = Av();
>   }
> 
> This test gives an error with any compiler I could tested it with:
>    gcc-2.96, gcc-3.2.1, gcc-4.0.0, xlC-6.0.0
Interestingly enough, it gives an error with the native
compiler too (based on teh EDG front-end).

To fix this for GCC, I will fixincludes the volatile away.

> Do you know why the type itself is defined as volatile, as opposed to
I don't, but I shall ask the person who wrote the header file.

> declaring only relevant variables as volatile? What system is it anyway?
System V Release 5 (UnixWare / OpenServer 6).

Kean