public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Josh <sundog@mindspring.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Bootstrap failure on Sparc Solaris2.8
Date: Tue, 27 May 2003 17:51:00 -0000	[thread overview]
Message-ID: <200305271946.53796.ebotcazou@libertysurf.fr> (raw)
In-Reply-To: <8134855.1054054386555.JavaMail.nobody@wamui07.slb.atl.earthlink.net>

> I have now tried to bootstrap with the snapshot dated 20030526, with the
> same result: eh_alloc.cc fails at line 81, with or without LIBCXXFLAGS
> set. I probably shouldn't have, but I did, go in and change the files
> listed below, commenting out initializations of the __gthread_mutex_t
> type.  This allowed the bootstrap to finish.
>
> In directory libstdc++-v3/include/libsupc++: eh_alloc.cc
> In directory libstdc++-v3/include/bits: stl_alloc.h, stl_threads.h

I should have thought about it earlier: there are these lines in 
fixinc/inclhack.def:

/*
 * Sun Solaris defines PTHREAD_MUTEX_INITIALIZER with a trailing
 * "0" for the last field of the pthread_mutex_t structure, which is
 * of type upad64_t, which itself is typedef'd to int64_t, but with
 * __STDC__ defined (e.g. by -ansi) it is a union. So change the
 * initializer to "{0}" instead
 */
fix = {
    hackname = solaris_mutex_init_2;
    select = '@\(#\)pthread.h' "[ \t]+1.[0-9]+[ \t]+[0-9/]+ SMI";
    files = pthread.h;
    c_fix = format;
    c_fix_arg = "#if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)\n"
                "%0\n"
                "#else\n"
                "%1, {0}}%3\n"
                "#endif";
    c_fix_arg = "(^#define[ \t]+PTHREAD_(MUTEX|COND)_INITIALIZER[ \t]+{.*)"
                ",[ \t]*0}" "(|[ \t].*)$";
    test_text =
    '#ident "@(#)pthread.h  1.26  98/04/12 SMI"'"\n"
    "#define PTHREAD_MUTEX_INITIALIZER\t{{{0},0}, {{{0}}}, 0}\n"
    "#define PTHREAD_COND_INITIALIZER\t{{{0}, 0}, 0}\t/* DEFAULTCV */\n"
    "#define PTHREAD_RWLOCK_INITIALIZER\t"
             "{0, 0, 0, {0, 0, 0}, {0, 0}, {0, 0}}";
};

which means that GCC is supposed to fix alone a problem that is very similar 
to the one you encountered.

Could you see if there is a pthread.h header file in $(objdir)/gcc/include?

-- 
Eric Botcazou

  reply	other threads:[~2003-05-27 17:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-27 17:08 Josh
2003-05-27 17:51 ` Eric Botcazou [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-28 20:43 Josh Loeb
2003-05-28 20:53 ` Albert Chin
2003-05-27 18:08 Josh
2003-05-27 19:13 ` Eric Botcazou
2003-05-23 13:59 Josh
2003-05-23 16:14 ` Eric Botcazou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200305271946.53796.ebotcazou@libertysurf.fr \
    --to=ebotcazou@libertysurf.fr \
    --cc=gcc@gcc.gnu.org \
    --cc=sundog@mindspring.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).