Hi, Enrico Zini wrote:
Later on it appeared that the -pic libraries were non-needed, at the cost of a bigger loading time and memory footprint because of textrels.
Well, that is only true for i386 and probably some other ports that can deal with it.
Policy 10.2:
The shared version of a library must be compiled with -fPIC, and the static version must not be. In other words, each source unit (*.c, for example, for C files) will need to be compiled twice.
Hrm, this is for libraries with a stable API/ABI however. We already break that if we do not provide shared libs, and it has been commonly accepted practice.
- build -fPIC libraries again (and in that case I'd like to find a better way to do it than before[1]
In the long run, libtool could be kicked into doing that sanely. It has one disadvantage though: New code will not be tested, as the plugins are still using the old code, and it will be difficult to tell which version is being run.
- build a .so and change its name at every upload
Preferable IMO. It makes pretty much clear that this is an unstable API, but has the disadvantage of requiring rebuilds of all applications that use it (but this can be fixed by NMUing unchanged source with the permission of the respective maintainer)
The good news this time is that I'm not alone anymore in solving this mess and we can work it out in a team. What do you think of this situation?
Not sanely solvable until my autobuilder project is finished and/or packages that are uninstallable but buildable are automatically rebuilt.
Simon
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Debtags-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debtags-devel
