65;6601;1cOn Thu, Nov 25, 2021 at 06:50:04PM +0300, Ivan Maidanski wrote: > >How come --enable-static means the .so doesn't use symbol visibility? > >Would it be a better idea to build twice -- once to enable symbol > >visibility on the .so and then again to produce the .a?
> Good point. This is how CMake works — you can either request cmake > to build shared libraries or static ones but not both. In case of > GNU build process, the configure could be requested to build both > static and shared libraries with just a single make invocation. In > the Debian configuration, we pass --enable-static but > --enable-shared option is implied, thus make builds both static and > shared libs. Of course, we could prohibit building of both static > and shared libs in configure, I think I will do it to avoid > confusion, not now. But this would inevitably force the Debian libgc > build script to be changed (to invoke configure 2 times if both > static and shared libs are required). This shouldn't be too hard to separate out in the package build, and I think is probably a good idea for maintainability. > >> Is there any restriction in the Debian policy against deletion of > >> the exported symbols that were not exported publicly (i.e. were > >> never mentioned in the public headers or documentation)? > > > >I will have to extract some of the old packages and compare the symbol > >file ... not sure if this is the first time, or if previous uploads > >have just dropped missing symbols on the basis they are not > >documented? > Comparing libgc1c2.symbols between 7.4.2 and 7.6.4: GC_finalize_now > and GC_dirty_maintained symbols (and some others) were removed in > 7.6.4. So, it’s not a unique case. Thanks, I agree so we can just follow that precedent. Since the Vcs-Git was pointing at the old anonscm bits, I've imported everything into salsa as https://salsa.debian.org/debian/libgc I've uploaded 8.0.6-1.1 built from there as a NMU to the 7-day delay queue (https://ftp-master.debian.org/deferred.html) Thanks, -i
