delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1998/01/28/18:43:36

From: Andrew Crabtree <andrewc AT typhoon DOT rose DOT hp DOT com>
Message-Id: <199801282342.AA056180971@typhoon.rose.hp.com>
Subject: Re: iostream concern
To: robert DOT hoehne AT gmx DOT net (Robert Hoehne)
Date: Wed, 28 Jan 1998 15:42:50 PST
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <34CFA8EE.D826946F@gmx.net>; from "Robert Hoehne" at Jan 28, 98 10:53 pm
Reply-To: andrewc AT rosemail DOT rose DOT hp DOT com

> > Is this relevant to the problem with _G_fpos_t?  AFAIK, compiling GCC
> > doesn't require using the C++ headers.  Or is it?
I guess that _G_fpos_t is distributed in different packages in 
different forms.  Apparently glibc includes a copy of it that 
is different that the one that iostream came with.  You get the 
same unresolved externals problems that the pg++ users see.  This was the
discussion that went on in the egcs list by the linux folks.  Probably
just an egcs specific thing that it got installed.  But, perhaps 
we should consider releasing 'official' versions of egcs as well as gcc 2.8.
Egcs is faster than regular 2.8 but more stable than pgcc.

> Since there were in the
> past some problems with it, I would include libstdcxx.a in gpp280b.zip
> and would have in lgpp280b.zip only libgxx.a . Are you agree?
Sounds good.  The stdc++ and iostream libraries are better tied to 
the c++ compiler.  libgpp is more an add on package.

> As you could see, I have changed the libgpp.a to libgxx.a. Is this a
> problem in general?
Isn't it called libgpp.a on unix as well?  Even if not this seems like
we would be asking for trouble as people would still have the old version
and would then have to change libraries listed in makefiles.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019