Re: libstdc++/6827: Unreasonable dependencies on ctype.h

Re: libstdc++/6827: Unreasonable dependencies on ctype.h

[bkoz]

Synopsis: Unreasonable dependencies on ctype.h

State-Changed-From-To: feedback->closed
State-Changed-By: bkoz
State-Changed-When: Mon Jun  3 02:47:28 2002
State-Changed-Why:
    This issue is resolved, I think. If you have additional configure questions, please bring them up on the libstdc++ list.
    
    -benjamin

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6827

Re: libstdc++/6827: Unreasonable dependencies on ctype.h

[Phil Edwards]

The following reply was made to PR libstdc++/6827; it has been noted by GNATS.

From: Phil Edwards <phil@jaj.com>
To: Tony Bryant <brd@paradise.net.nz>
Cc: gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/6827: Unreasonable dependencies on ctype.h
Date: Tue, 28 May 2002 14:17:00 -0400

 On Wed, May 29, 2002 at 12:42:23AM +1200, Tony Bryant wrote:
 > How valid is the assumption that we'll be using always be using newlib on 
 > cross compilers? 
 
 It's not so much an assumption, rather it's nobody has contributed support
 for any other embedded C library to libstdc++-v3.
 
 "Embedded" isn't actually a requirement here, of course.  It's just that
 newlib also makes a darn good portable C library, sort of as a byproduct
 of being targeted to embedded platforms.  /That's/ why we use it.
 
 If another portable C library were available and popular (heck, even if
 it weren't popular), we would cheerfully support it for cross-compilers.
 
 
 > Is is reasonable for configure to check if newlib is installed, and if 
 > not, resort to the generic interface?
 
 Checking whether it's /installed/ isn't reasonable, because we may be
 building newlib in the same tree as libstdc++-v3, at the same time.
 I do this, and libstdc++-v3 gets built before newlib.
 
 But it probably would be useful to check for --with-newlib or
 --without-newlib, and change os_include_dir appropriately.  The top-level
 configue.in tests for those options, but I don't seem them documented
 anywhere else.  The only question is the default setting.
 
 
 Phil
 
 -- 
 If ye love wealth greater than liberty, the tranquility of servitude greater
 than the animating contest for freedom, go home and leave us in peace.  We seek
 not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
 and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: libstdc++/6827: Unreasonable dependencies on ctype.h

[bkoz]

Synopsis: Unreasonable dependencies on ctype.h

Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Mon May 27 04:53:45 2002
Responsible-Changed-Why:
    Mine.
State-Changed-From-To: open->feedback
State-Changed-By: bkoz
State-Changed-When: Mon May 27 04:53:45 2002
State-Changed-Why:
    I think you are mistaken. The ctype implementation is pretty flexible, although a bit baroque.
    
    See config/os/newlib/bits/ctype* for the default cross compiler bits (using newlib.) There is another configuration for glibc (under gnu-linux/bits/ctype*). There are also specific configs for most other commercial unices. You might check it out.
    
    -benjamin
    

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6827

libstdc++/6827: Unreasonable dependencies on ctype.h

[brd]

>Number:         6827
>Category:       libstdc++
>Synopsis:       Unreasonable dependencies on ctype.h
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon May 27 00:46:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Tony Bryant
>Release:        unknown-1.0
>Organization:
>Environment:
builing sh-elf cross compiler
>Description:
libstdc++ assumes the following symbols are available from ctype.h:

_N 
_L
_X
_U
_P
_S
_B
_C
_ctype_

I assume that these are not part of the ISO standard C ctype.h definition.

This bug stops libstdc++ from being compilable with headers other than glibc's
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: