On 2011-08-06 16:25, Pedro Lopez-Cabanillas wrote:
On Saturday 06 August 2011, David Henningsson wrote:
CMake has a libtool alternative as part of its toolchain, and we use it
as default. And yes, we provide a numbering scheme equivalent to libtool
there.
But something happened with the auto-t
On Sat, Aug 06, 2011 at 04:40:02PM +0200, Pedro Lopez-Cabanillas wrote:
> Because the SONAME is part of the file name of the runtime shared
(Is *precisely* the file name; the SONAME field is copied into a
DT_NEEDED entry when linking, and the elf loader searches for a file
by that name to complete
On Saturday 06 August 2011, Andrew Suffield wrote:
> On Sat, Aug 06, 2011 at 04:13:16PM +0200, David Henningsson wrote:
> > Thanks for the pointers. As the FLUIDSYNTH_API is already in place,
> > if we could make that evaluate to something like __attribute__
> > ((visibility ("default"))) on gcc pl
On Saturday 06 August 2011, David Henningsson wrote:
> >> 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 because this bug is too much a burden for everybody.
>
> Sorry, I'm not f
On Saturday 06 August 2011, David Henningsson wrote:
> CMake has a libtool alternative as part of its toolchain, and we use it
> as default. And yes, we provide a numbering scheme equivalent to libtool
> there.
But something happened with the auto-tools buildsystem in this release. It
created t
On Sat, Aug 06, 2011 at 04:13:16PM +0200, David Henningsson wrote:
> Thanks for the pointers. As the FLUIDSYNTH_API is already in place,
> if we could make that evaluate to something like __attribute__
> ((visibility ("default"))) on gcc platform, that would be the
> simplest way of solving this pr
On 08/06/2011 02:13 PM, Pedro Lopez-Cabanillas wrote:
On Saturday 06 August 2011, 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
On 08/06/2011 03:24 PM, Andrew Suffield wrote:
On Sat, Aug 06, 2011 at 03:05:06PM +0200, Pedro Lopez-Cabanillas wrote:
On Saturday 06 August 2011, Andrew Suffield wrote:
On Sat, Aug 06, 2011 at 02:42:59PM +0200, Pedro Lopez-Cabanillas wrote:
The auto-tools based build system of FluidSynth is d
On Sat, Aug 06, 2011 at 03:20:54PM +0200, Pedro Lopez-Cabanillas wrote:
> On Saturday 06 August 2011, Andrew Suffield wrote:
> > On Sat, Aug 06, 2011 at 10:00:21PM +1000, Matt Giuca wrote:
> > > - Release FluidSynth 2.0, with soname libfluidsynth.so.2, or
> >
> > It is generally unwise to attempt
On Sat, Aug 06, 2011 at 03:05:06PM +0200, Pedro Lopez-Cabanillas wrote:
> On Saturday 06 August 2011, Andrew Suffield wrote:
> > On Sat, Aug 06, 2011 at 02:42:59PM +0200, Pedro Lopez-Cabanillas wrote:
> > > The auto-tools based build system of FluidSynth is deprecated, and
> > > was using libtool.
On Saturday 06 August 2011, Andrew Suffield wrote:
> On Sat, Aug 06, 2011 at 10:00:21PM +1000, Matt Giuca wrote:
> > - Release FluidSynth 2.0, with soname libfluidsynth.so.2, or
>
> It is generally unwise to attempt to keep SONAME versions and project
> versions in sync. This leads to confusion an
On Saturday 06 August 2011, Andrew Suffield wrote:
> On Sat, Aug 06, 2011 at 02:42:59PM +0200, Pedro Lopez-Cabanillas wrote:
> > The auto-tools based build system of FluidSynth is deprecated, and
> > was using libtool. The new CMake based build system does not use
> > libtool.
>
> That's unfortuna
On Sat, Aug 06, 2011 at 02:42:59PM +0200, Pedro Lopez-Cabanillas wrote:
> The auto-tools based build system of FluidSynth is deprecated, and
> was using libtool. The new CMake based build system does not use
> libtool.
That's unfortunate. Consider using libtool. This level of shared
library manipu
On Sat, Aug 06, 2011 at 10:00:21PM +1000, Matt Giuca wrote:
> - Release FluidSynth 2.0, with soname libfluidsynth.so.2, or
It is generally unwise to attempt to keep SONAME versions and project
versions in sync. This leads to confusion and inappropriate
compatibility problems. Best practice is to k
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 u
On Saturday 06 August 2011, 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.
I agree with Andrew's first paragraph (and I don't know enough about
libtool to endorse the second).
> 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?
The Fluidsynth soname is currently libfluidsynth.so.1. As
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
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
19 matches
Mail list logo
