On Saturday 06 August 2011, Andrew Suffield wrote: > On Sat, Aug 06, 2011 at 12:54:20PM +0200, David Henningsson wrote: > > As reported in ticket #98, FluidSynth 1.1.4 dropped one symbol. > > However, this symbol (fluid_defsfont_get_sample) is not part of the > > public API, so no programs should use it anyway. > > > > I don't know how much of a big deal this is, really. Can you help me > > determine that, and the proper action for it? > > > > Is it something that alone calls for a new release (1.1.5) or can we > > just update svn? What implications does bumping the SONAME have? > > Changing the SONAME field implies that things using the library must > be recompiled against the new version, and would break if used against > the old one. Whether this is merited here depends on what you think > about applications using that symbol. It would break them obviously > while rebuilding, rather than at runtime (potentially long after the > application starts). > > > IMO, the ideal would be if we could tell gcc to stop exporting all > > symbols that are not part of the public API. Then we would get rid > > of this problem altogether. Is that possible? > > Yes, you want to add a version script for the linker. Since you're > using libtool, I think you can avoid messing around with the tricky > platform-specific details by using the -export-symbols argument. (I > know it does the right thing on glibc-elf platforms; haven't tried it > on others, and some platforms simply don't have this feature)
The auto-tools based build system of FluidSynth is deprecated, and was using libtool. The new CMake based build system does not use libtool. Regards, Pedro _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
