On Tuesday 10 March 2009 22:55:12 Joseph S. Myers wrote:
> On Tue, 10 Mar 2009, Mike Frysinger wrote:
> > On Tuesday 10 March 2009 21:44:23 Joseph S. Myers wrote:
> > > On Tue, 10 Mar 2009, Mike Frysinger wrote:
> > > > perhaps we need to extend the libgcc.map function to allow people to
> > > > in
On Tue, 10 Mar 2009, Mike Frysinger wrote:
> On Tuesday 10 March 2009 21:44:23 Joseph S. Myers wrote:
> > On Tue, 10 Mar 2009, Mike Frysinger wrote:
> > > perhaps we need to extend the libgcc.map function to allow people to
> > > insert $(FPBIT_FUNCS) and such into the map so libgcc_s.so exports t
On Tuesday 10 March 2009 21:44:23 Joseph S. Myers wrote:
> On Tue, 10 Mar 2009, Mike Frysinger wrote:
> > perhaps we need to extend the libgcc.map function to allow people to
> > insert $(FPBIT_FUNCS) and such into the map so libgcc_s.so exports these
> > suckers ?
>
> Exporting functions that are
On Tue, 10 Mar 2009, Mike Frysinger wrote:
> perhaps we need to extend the libgcc.map function to allow people to insert
> $(FPBIT_FUNCS) and such into the map so libgcc_s.so exports these suckers ?
Exporting functions that are internal to fp-bit rather than part of the
documented libgcc interf
if working with a softfloat toolchain, we end up with copies of softfloat
symbols everywhere (from fp-bit.c and dp-bit.c). should these files really
end up with symbols with hidden visibility ? seems like a waste to force
copying of these symbols into binaries when libgcc_s.so itself already h
