Bug#532690: [Openal-devel] ALURE 1.0 Debian packages

Andres Mejia mcitadel at gmail.com
Mon Jun 15 02:08:32 UTC 2009


On Sunday 14 June 2009 10:25:40 Reinhard Tartler wrote:
> Andres Mejia <mcitadel at gmail.com> writes:
> >> > Also, I see there's an option for building a static library but
> >> > doesn't allow it to be built with the shared library. This isn't like
> >> > OpenAL Soft where there's no such option and the -DLIBTYPE=STATIC
> >> > option has to be passed into cmake. For ALURE, do you have any
> >> > objections for installing static libraries alongside shared libraries?
> >>
> >> My main reservation with static libraries with ALURE (as opposed to
> >> OpenAL) is that it shares the same name as the shared lib. If you
> >> install both libalure.so and libalure.a, then linking with -lalure will
> >> always pick the shared lib AFAIK. Conversely, libalure.a isn't needed
> >> for any pre-compiled binaries, and since pkg-config isn't flexible
> >> enough to "select" between shared and static, all linking the user does
> >> would use the shared lib if it's there.
> >
> > -lalure would indeed pick the shared lib by default. I will go ahead and
> > provide a static library for ALURE in Debian as well.
>
> May I ask why? For debian, we generally try to avoid static libraries if
> there is no good reason for that. If there is a good reason[1] for dong
> so, please add a note in the package.  If it is only for convenience for
> the users, I'd recommend to not ship the .a and .la files at all, since
> IME it avoids headaches in the future.
>
>
> [1] good reasons include massive performance gains, extra features, etc.

It's merely for convenience to users.

Who's "we" by the way? I see various static libraries on my system alone, 
including static libs for libc, zlib, libbz2, and freealut, so I'm guessing "we" 
is not Debian.

-- 
Regards,
Andres





More information about the Pkg-games-devel mailing list