public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
To: Basile STARYNKEVITCH <basile@starynkevitch.net>, gcc@gcc.gnu.org
Subject: Re: libiberty should be a shared library when cc1 has plugin  enabled.
Date: Thu, 09 Jul 2009 15:07:00 -0000	[thread overview]
Message-ID: <20090709150648.GB23570@ins.uni-bonn.de> (raw)
In-Reply-To: <20090709134318.GA8237@caradoc.them.org>

* Daniel Jacobowitz wrote on Thu, Jul 09, 2009 at 03:43:18PM CEST:
> While Ralf's point about static data is valid, the functions likely to
> be in libiberty on any platform supporting plugins should not suffer
> from this problem.

Solaris 9 and IRIX 6.5 support dlopen; gnulib documents them as missing
setenv, and of course they are tertiary platforms only.  However, I
wouldn't be surprised if plugins such as melt used setenv, esp. if they
spawn other processes, e.g., to compile code.

> If you're concerned about it, then build a subset.  I've considered a
> separation of libiberty into replacements and utilities, anyway.

Why would that help in this case?  Even if the static data issue
concerns one set of these functions only now (does it?), it won't
prevent anyone from adding problems to the other set tomorrow, unless
you also introduce a policy that libiberty functions be safe against
multiple entities.

Cheers,
Ralf

  parent reply	other threads:[~2009-07-09 15:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-09  8:49 Basile Starynkevitch
2009-07-09 11:41 ` Dave Korn
2009-07-09 11:58   ` Basile STARYNKEVITCH
2009-07-09 12:17     ` Dave Korn
2009-07-09 12:38       ` Basile STARYNKEVITCH
2009-07-09 12:50 ` Daniel Jacobowitz
2009-07-09 13:01   ` Basile STARYNKEVITCH
2009-07-09 13:43     ` Daniel Jacobowitz
2009-07-09 13:46       ` Basile STARYNKEVITCH
2009-07-09 13:59         ` Daniel Jacobowitz
2009-07-09 14:06           ` Basile STARYNKEVITCH
2009-07-09 15:07       ` Ralf Wildenhues [this message]
2009-07-09 15:20         ` Basile STARYNKEVITCH
2009-07-09 13:07   ` Ralf Wildenhues

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=20090709150648.GB23570@ins.uni-bonn.de \
    --to=ralf.wildenhues@gmx.de \
    --cc=basile@starynkevitch.net \
    --cc=gcc@gcc.gnu.org \
    /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).