> From: Ulrich Weigand <uweig...@de.ibm.com> > Date: Wed, 26 Aug 2015 13:45:35 +0200
> Hans-Peter Nilsson wrote: > > > From: Ulrich Weigand <uweig...@de.ibm.com> > > > Date: Tue, 25 Aug 2015 19:45:06 +0200 > > > > > However, neither works for the SPU, because in both cases libtool > > > will only do the test whether the target supports the -fPIC option. > > > It will not test whether the target supports dynamic libraries. > > > > > > [ It will do that test; and default to --disable-shared on SPU. > > > That is a no-op for libbacktrace however, since it calls LT_INIT > > > with the disable-shared option anyway. > > > > Maybe it shouldn't? > > Huh? We do want libbacktrace solely as static library, that's the > whole point ... I meant that as a *suggestion for a possible workaround* to stop libtool from refusing to compile with PIC, but then I take it you don't need hints to try another angle than adjusting compilation flags. > > > When adding back the -fPIC > > > flag due to either the pic-only LT_INIT option or the -prefer-pic > > > libtool command line option, it does not check for that again. ] > > > > Sounds like a bug somewhere, in libtool or its current use: > > there *should* be a way to specify "I'd prefer PIC code in these > > static libraries". > > But that's what the option *does*. > > Let me try again, maybe we can reduce confusion a bit :-) I don't feel very confused, but I understand you've investigated things down to a point where we can conclude that libtool can't do what SPU needs without also at least fiddling with compilation options. > I guess we can always fall back to just hard-coding SPU once > more; that's certainly the simplest solution right now. Maybe. brgds, H-P
