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 ... > > 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 :-) We've been discussing three potential sets of options to use with the LT_INIT call here. Those are: A) LT_INIT # no options Build both a static and a shared library. If the target does not support shared libraries, build the static library only. The code landing in the static library is built without -fPIC; code for the shared library is built with -fPIC (or the appropriate target flag). B) LT_INIT([disable-shared]) Build *solely* a static library. Code is compiled without -fPIC. C) LT_INIT([disable-shared,pic-only]) Build solely a static library, but compile code with -fPIC or the appropriate target flag (may be none if the target does not support -fPIC). [Note that in all cases, behaviour can be overridden via configure options like --enable/disable-shared and --enable/disable-static.] As I understand it, we deliberately do not use option A. As the comment in the libbacktrace configure.ac says: # When building as a target library, shared libraries may want to link # this in. We don't want to provide another shared library to # complicate dependencies. Instead, we just compile with -fPIC. That's why libbacktrace currently uses option B and manually adds a -fPIC flag. Now, after the latest check-in, the behaviour is mostly equivalent to using option C (and not manually changing PIC flags). However, none of the options do exactly what would be right for the SPU, which would be: Build solely a static library, using code that is compiled so that it can be linked as part of a second library (static or shared). This is equivalent to: Build solely a static library, but compile code with -fPIC or the appropriate target flag *if the target supports shared libraries*. This again is *mostly* equivalent to option C, *except* on targets that support -fPIC but do not support shared libraries. I'm not sure if it is worthwhile to try and change libtool to support targets with that property (e.g. adding a new LT_INIT option), if this in practice only affects SPU. > But, I'll have to leave solving this PIC-failing-at-linkage > problem to you; I committed the current approved fix for > PIC-failing-at-compilation. I guess we can always fall back to just hard-coding SPU once more; that's certainly the simplest solution right now. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
