Re: [ardour-dev] ardour
On Thursday 12 September 2002 00:46, Paul Davis wrote:
> >> >work, helped by the autobuilders. Moreover, the build dependencies can
> >> >guarantee you the package will build fine if you try at home.
> >>
> >>=20
> >> !!NO THEY DO NOT!! why can people not understand this? there is no
> >
> >Why can't people understand that linking to a static library is BAD ?
>
> it poses some problems yes. but nothing as deep as programs that
> simply don't run correctly for completely inobvious reasons. i
> wouldn't advocate static linking for C, for example, but for C++, the
> situation is very difficult.
I was reading this thread and I understand both sides, that up front. I also
believe that you, Paul Davis, are not happy with workarounds like static
linking or maintaining a separate source-tree for required libs, just because
it is 'not a solution'. Still, I understand your concerns and can imagine the
problems that led you to start linking statically in the first place,
diagnosing remote bogus computers by email is hard. Been there, done that.
Maybe I'd have a different approach to make both sides happy, Joe Clue and
Joe Clueless: using a ports-like approach. The ardour team distributes it's
sources plus a build-script. This script relies on the tarballs of required
libs (which you could distribute in a version that you use and that is known
to work). Joe Clueless would then just execute the build-script and get a
version of ardour that runs. This is the foremost documented way to get
ardour running, just because it is the easiest (though not most elegant).
Apart from separating some parts, this is also mostly equivalent to what you
already do.
Joe Clue could call the same script with options like --use-sys-libsigc++ to
not use the sigc++ supplied alongside but the one installed system-wide. That
way, he doesn't have to use cludges like static linking as long as his system
is not bogus.
The third build-option (which is in fact partially wrapped by the above
script) is to use ./configure directly inside the ardour-sources. You can use
things like --with-sigc++-path=/path/to/sigC++/install-location/ to have a
fine-grained control over what libs are linked and the other autotools to
control where the program is installed.
I did leave out one thing and that is static linking. I'm also doubting that
that is really necessary as long as Ardour is installed in a separate
location (which the mentioned script would do). In fact renaming/moving
common libs and linking dynamically is in fact the same as static linking,
except that you can't do things like toy around with LD_ environment
variables.
I'd also not encourage Joe Clueless to install programs system-wide, btw.
For that, it might be worthwhile to then just transform the name of some libs
(feasible via a sed command given to configure) so they don't mess up with
the systems'. Speaking for Debian, I never found cases where it was
worthwhile to work around its package management system and I experienced
some cases where others broke their systems with that.
I know that for some cases it is advisable to run ardour as root or with
root privileges, but even if you thus make root a regular user doesn't mean
that root's playground must span the whole system.
BTW: IIRC, you had the problem with the C++ libs around one year ago. GCC 3
was just in the stage of appearing there and not many had experience with it.
Knowledge that there is something called ABI that might be incompatible is
far more widespread today.
> >What we are speaking of here is building a Debian package, with a
> >maintainer. Users don't build the package, the maintainer and the
> >autobuilders do. The maintainer ensures that the package is built with
> >the compiler that was already used to build the libraries it depends on.
> >All of this guarantees the program will work, and with *dynamic*
> >libraries, while the user never has to build the software. If the user
> >doesn't build the software himself, all the issues you describe will
> >never appear.
>
> *if* this is all completely true, then i *am* happy with the idea of
> debian packages dynamically linked against other C++ libraries.
It is. You can expect your packages to be built by someone that knows what
they are doing. Furthermore it will remain in testing/unstable for quite some
time which is a distribution that is only for advanced users. Those users
know that they are supposed to report bugs to the maintainer and not to
upstream or even fix them themselves.
> however, it will mean not be acceptable for a source package, and it
I'm not totally sure, but before misunderstandings come up, let me say that
there are so-called source-packages for Debian. Those are mainly used by the
autobuilders but can also be used by Joe Clue:
$ apt-get source ardour
$ cd ardour-x.y.z
$ dpkg-buildpackage -us -uc
YMMV, but I consider those a secure method. Especially since those packages
_where already successfully used_ for building a package, Joe Clue will know
that it is his fault (or his system's) if something breaks and not bugger
upstream.
> i would like to see a debian package of ardour, i really would. but
> the claims i have read about "complaints will go to the maintainer
> first" don't convince me, and neither does anything you have written
> so far, that such a package would not result in many emails to me
> and/or the ardour email lists talking about strange behaviour by the
> program on someone's machine. i could punt this back down to the
> maintainer, i suppose.
Hey, have confidence. :)
Reply to: