Re: [ardour-dev] ardour
>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
thats correct. i wasn't happy about adopting this approach, and i
still find it cumbersome and ugly. it was responsible for the complete
eliminaton of a certain category of bug report, however. that in
itself was a certain kind of validation.
>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.
yes, i agree that this is basically what we do already.
the problem is that this doesn't address the person who downloads a
binary package to their machine that is dynamically linked, and who
doesn't know (and has no way to know) that for some reason or another,
the C++ libraries on their machine will cause bizarre problems.
and that's the second part of the two-part problem here:
* binary dynamically linked to (incompatible) libs
* source code compiled and then dynamically linked against
(incompatible) libs
its ensuring that the (incompatible) part is taken care of that is
hard. have you see how many RPM's there are of various libraries out
there? my responsibility, remember, is not just to debian, but to
linux in general. i don't know if there are multiple dpkg's, it seems
less likely ...
> 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.
right, if we hack up LD_LIBRARY_PATH and put private copies of the
libs in some place (say /usr/local/lib/ardour), then what we've done
is, as you note, just like static linkage, and has no benefits over
it.
> 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
this is still private linkage against libraries, which goes against
(as i understand it) debian policy. it violates both security and
resource usage guidelines.
>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.
this was before gcc3 emerged. problems started with RH's distribution
of gcc 2.96.
if someone sends me patches that provide configure with options like:
--with-<lib>-path
for each library, i will read over them and probably apply them. the
patches should turn off in-tree compilation of the --with'ed
libraries. ok?
--p
Reply to: