This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: __strtoll, __strtoull and _GLIBCPP_USE_LONG_LONG underhppa64-hpux
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Fri, 12 Apr 2002 13:41:00 -0700
- Subject: Re: __strtoll, __strtoull and _GLIBCPP_USE_LONG_LONG underhppa64-hpux
- References: <200204112209.g3BM9IK63412@latour.rsch.comm.mot.com>
--On Thursday, April 11, 2002 05:09:18 PM -0500 Loren James Rittle
<rittle@latour.rsch.comm.mot.com> wrote:
> In article <200204111819.g3BIJ7MN000812@hiauly1.hia.nrc.ca> you write:
>> I noticed when I tried a static link of capacity.cc that __strtoll and
>> __strtoull are not defined under hppa64-hpux. I know that various
>> solutions for the long long issue have been proposed but none seem to
>> have received approval.
>
>> Since strtoll and strtoull are not available, is a reasonable solution
>> to this problem just to add an ifdef __LP64__ to hpux/os_defines.h
>> defining _GLIBCPP_USE_LONG_LONG to be 0? We need to eliminate the
>> undefined symbols.
>
> Given the hot potato of an issue it became (I privately reviewed the
> -liberty approach; but I just didn't see all the tied issues), I
> personally support disabling all long long support for any platform
> that does not have the required library routines. I admit it is the
> easy way out but until a more aggressive patch is developed and
> accepted into the tree, it seems more acceptable than breaking bootstraps.
I agree.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com