23 May
2007
23 May
'07
1:19 p.m.
Good morning all,
Lately there has been some posts from me and others about the lack of
a recent version of jack in the debian repos. I tried an approach
this week that didn't quite work out, but I think I'm on the right
track, and I wanted to see what everyone thought.
I installed debian from the net install cd, and installed only the
base system. I apt-got (forgive the made-up word) the very basic
stuff - xorg, fluxbox, aterm, screen, etc. Then I began to download
the most recent version of the applications I use - jack, qjackctl,
dssi and brethern, etc. - and things seemed to work okay; I had the
most recent versions of most everything I use. Everything was fine
until I needed something (can't remember what) that depended on
libjack0.100.whatever. I installed it, and things fell apart...apt
wanted to install some things, remove others, and essentially
everything was f*cked.
So where did I go wrong? I've been reading Ken Restivo's blog lately
(great blog, b/t/w), and he has actually built debian packages from
source of what he needs - is that the solution I'm looking for? Is my
approach good or flawed, and what should I do differently?
--
Josh Lawrence
http://www.hardbop200.com
http://www.joshlawrencetrio.com
23 May
23 May
4:17 p.m.
On Wed, May 23, 2007 at 10:19:14AM -0500, Josh Lawrence wrote:
So where did I go wrong? I've been reading Ken Restivo's blog lately
(great blog, b/t/w), and he has actually built debian packages from
source of what he needs - is that the solution I'm looking for? Is my
approach good or flawed, and what should I do differently?
Basically if something depends on the old version of jack, then
yes the best method would be to make a new package that depends
on the up to date version, or alternatively wait for the
packagers to sort it out.
One last option is just to install the program as a non-debian
package. I do this quite a lot because it is much quicker than
debianizing everything, but it is not the recommended approach,
and it leads to breakages if you install a debian version of a
package you installed from source.
Best,
James
5:15 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, May 23, 2007 at 07:16:59PM +0100, James Stone wrote:
I did it the hard way. Because, that's just the way I do stuff. I wouldn't
recommend it.
The easy way would be to install UbuntuStudio, Musix, 64studio, etc.
On Wed, May 23, 2007 at 10:19:14AM -0500, Josh
Lawrence wrote:
>
> So where did I go wrong? I've been reading Ken Restivo's blog lately
> (great blog, b/t/w), and he has actually built debian packages from
Thanks!
source of what
he needs - is that the solution I'm looking for? Is my
approach good or flawed, and what should I do differently?
Basically if something depends on the old version of
jack, then
yes the best method would be to make a new package that depends
on the up to date version, or alternatively wait for the
packagers to sort it out.
One last option is just to install the program as a non-debian
package. I do this quite a lot because it is much quicker than
debianizing everything, but it is not the recommended approach,
and it leads to breakages if you install a debian version of a
package you installed from source.
That's what I had to do in order to get Ardour2 going, since the Debian package uses
SYSLIBS=1 and thusly makes it non-functional on my machine.
I tried checkinstall too, but that had issues: apparently the Ardour2 scons target tries
to make symlinks for /usr/bin/gcc, and dpkg rightly refused to allow it to something so
dangerous.
I also tried hacking the Debian ardour2 package to take out the SYSLIBS, but that
didn't work either. Finally I filed a bugs.debian.org problem report and just let Free
and Gunther et al deal with it.
FWIW, my /usr/local/bin looks like this:
aseq2jackmidi
ardour2
chuck
cygnal
dumpOSC
elven
elven_guiloader
ghostess
ghostess_universal_gui
gtf
ingen
ingen_load
jace
jack_capture
jack_mididump
ladspa2lv2
lv2_inspect
lv2_jack_host
lv2_list
lv2peg
lv2_simple_jack_host
midi_led.py
midirgui
paqtest
patchage
phasex
roll
sendOSC
sockettest
tuneit
zynjacku
zynjacku.py
Everything else is in Debian packages (via sid).
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFGVJKMe8HF+6xeOIcRAlSLAKCZkSbfLzDF6pnvm5wrMpOnb3T8+ACbBRFr
o5A4RkDx/pEdN285phAuhYA=
=9CxR
-----END PGP SIGNATURE-----
5:25 p.m.
On Wed, 2007-05-23 at 12:14 -0700, Ken Restivo wrote:
That's what I had to do in order to get Ardour2
going, since the Debian package uses SYSLIBS=1 and thusly makes it non-functional on my
machine.
I tried checkinstall too, but that had issues: apparently the Ardour2 scons target tries
to make symlinks for /usr/bin/gcc, and dpkg rightly refused to allow it to something so
dangerous.
THIS IS NOT TRUE.
its also the 2nd time that its been claimed. please either point to the
line in our scons build system where this happens, or stop claiming that
it does.
I am very disappointed to hear that the Debian package is using
SYSLIBS=1. This means that we will refuse to support any Debian users
that have issues with Ardour. The Debian packager(s) have been told
about this in the past, and we made the consequences of their choices
clear.
--p
5:55 p.m.
On Wed, May 23, 2007 at 03:25:26PM -0400, Paul Davis wrote:
I am very disappointed to hear that the Debian package
is using
SYSLIBS=1.
This gives me two occasions to show my ignorance instead of just
the one I was going to post :-)
1. What does SYSLIBS=1 imply ?
2. (Original reason for this post)
I've been chasing a bug for hours this afternoon, and the conclusion
is that apparently g++, under some conditions, is not consistent
in the way it rounds floats to ints in a expression such as
float a, b, x;
int y;
y = (int)((x - a) * b + 0.5f);
I have this calculation twice, in the same source file. In one
case it's within a for loop, in the second case it's just a single
calculation. Both use exactly the same values for a, b, and x, yet
the result is different (by 1). The value before the cast its something
like 115.50424, and that gets rounded up in one case and down in the
other.
This is with -O3. Same with -O2, -O1, but OK without optimisation, and
also OK if I use -O3 -march=pentium4.
Is this to be expected, and should I use floorf() to avoid it, or is it
something that should not happen ?
--
FA
Follie! Follie! Delirio vano è questo !
6:33 p.m.
On Wed, May 23, 2007 at 10:00:38PM +0200, Fons Adriaensen wrote:
On Wed, May 23, 2007 at 03:25:26PM -0400, Paul Davis
wrote:
$ apt-get source ardour # current unstable
...
$ find . -type f -print0 | xargs -0 grep SYSLIB
./SConstruct: BoolOption('SYSLIBS', 'USE AT YOUR OWN RISK: CANCELS ALL
SUPPORT FROM ARDOUR AUTHORS: Use existing system versions of various libraries instead of
internal ones', 0),
./SConstruct:if env['SYSLIBS']:
./debian/rules: SYSLIBS=yes \
$
I am very disappointed to hear that the Debian
package is using
SYSLIBS=1.
This gives me two occasions to show my ignorance instead of just
the one I was going to post :-)
1. What does SYSLIBS=1 imply ? 2. (Original reason for this post)
I've been chasing a bug for hours this afternoon, and the conclusion
is that apparently g++, under some conditions, is not consistent
in the way it rounds floats to ints in a expression such as
float a, b, x;
int y;
y = (int)((x - a) * b + 0.5f);
I have this calculation twice, in the same source file. In one
case it's within a for loop, in the second case it's just a single
calculation. Both use exactly the same values for a, b, and x, yet
the result is different (by 1). The value before the cast its something
like 115.50424, and that gets rounded up in one case and down in the
other.
This is with -O3. Same with -O2, -O1, but OK without optimisation, and
also OK if I use -O3 -march=pentium4.
Is this to be expected, and should I use floorf() to avoid it, or is it
something that should not happen ?
It might not be a bug. You are not guaranteed of the same order of
evaluation of arithmetic expressions in C. If you want that you have
to use FORTRAN or assembler (maybe some other language has it also).
You might get around it with parantheses and/or temporary variables to
force the compiler to do the plusses etc. in a fixed order.
Beware that floating point values (in numerical circles) are considered
to be inexact, also, you might have better luck if you are using
doubles.
Regards,
/Karl
-----------------------------------------------------------------------
Karl Hammar Aspö Data karl(a)aspodata.se
Lilla Aspö 2340 Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
-----------------------------------------------------------------------
7:48 p.m.
On Wed, May 23, 2007 at 10:33:12PM +0200, Karl Hammar wrote:
On Wed, May 23, 2007 at 10:00:38PM +0200, Fons Adriaensen wrote:
1. There is absolutely no ambiguity in order of execution of the statement
above.
- subtract a from x
- multiply by b
- add 0.5
- cast to int
2. In both cases the floating point result was the same. Only the case to int
was different.
--
FA
Follie! Follie! Delirio vano è questo !
I've been chasing a bug for hours this
afternoon, and the conclusion
is that apparently g++, under some conditions, is not consistent
in the way it rounds floats to ints in a expression such as
float a, b, x;
int y;
y = (int)((x - a) * b + 0.5f);
I have this calculation twice, in the same source file. In one
case it's within a for loop, in the second case it's just a single
calculation. Both use exactly the same values for a, b, and x, yet
the result is different (by 1). The value before the cast its something
like 115.50424, and that gets rounded up in one case and down in the
other.
This is with -O3. Same with -O2, -O1, but OK without optimisation, and
also OK if I use -O3 -march=pentium4.
Is this to be expected, and should I use floorf() to avoid it, or is it
something that should not happen ?
It might not be a bug. You are not guaranteed of the same order of
evaluation of arithmetic expressions in C. If you want that you have
to use FORTRAN or assembler (maybe some other language has it also). 
7:57 p.m.
On 5/23/07, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Wed, May 23, 2007 at 10:33:12PM +0200, Karl Hammar
wrote:
I know less about this than you do, Fons. But, I always seem to end up
adding a rint() to statements like that. Not because I understand exactly
what is going on, but because otherwise GCC gives me warning messages
about casting float to int.
What happens, if you change those lines like this?...
y = (int) rint((x - a) * b + 0.5f);
Seems like that should give a consistent result (IIUC).
--
joq
On Wed, May 23, 2007 at 10:00:38PM +0200, Fons Adriaensen wrote:
1. There is absolutely no ambiguity in order of execution of the statement
above.
- subtract a from x
- multiply by b
- add 0.5
- cast to int
2. In both cases the floating point result was the same. Only the case to int
was different. I've been chasing a bug for hours this
afternoon, and the conclusion
is that apparently g++, under some conditions, is not consistent
in the way it rounds floats to ints in a expression such as
float a, b, x;
int y;
y = (int)((x - a) * b + 0.5f);
I have this calculation twice, in the same source file. In one
case it's within a for loop, in the second case it's just a single
calculation. Both use exactly the same values for a, b, and x, yet
the result is different (by 1). The value before the cast its something
like 115.50424, and that gets rounded up in one case and down in the
other.
This is with -O3. Same with -O2, -O1, but OK without optimisation, and
also OK if I use -O3 -march=pentium4.
Is this to be expected, and should I use floorf() to avoid it, or is it
something that should not happen ?
It might not be a bug. You are not guaranteed of the same order of
evaluation of arithmetic expressions in C. If you want that you have
to use FORTRAN or assembler (maybe some other language has it also).
8:42 p.m.
On Wed, May 23, 2007 at 04:57:08PM -0500, Jack O'Quin wrote:
I know less about this than you do, Fons. But, I
always seem to end up
adding a rint() to statements like that. Not because I understand exactly
what is going on, but because otherwise GCC gives me warning messages
about casting float to int.
What happens, if you change those lines like this?...
y = (int) rint((x - a) * b + 0.5f);
Tried both floorf (x + 0.5f) which is my standard way of rounding
floats, and rint (x). Same results - the problem remains.
What is even more scary is this: adding a extra printf() _after_ all
the calculations and _after_ a number of other printf() that I have
been using to see what is happening is enough to remove the error -
it modifies the values printed by the previous printf()...
I'm now pretty sure this is the optimiser having an identity
crisis...
--
FA
Follie! Follie! Delirio vano è questo !
9:46 p.m.
On Thu, 2007-05-24 at 00:48 +0200, Fons Adriaensen wrote:
On Wed, May 23, 2007 at 04:57:08PM -0500, Jack
O'Quin wrote:
fons, i am suprised that you have not run gcc -S and then diff on the
two asm files yet ....
I know less about this than you do, Fons. But, I
always seem to end up
adding a rint() to statements like that. Not because I understand exactly
what is going on, but because otherwise GCC gives me warning messages
about casting float to int.
What happens, if you change those lines like this?...
y = (int) rint((x - a) * b + 0.5f);
Tried both floorf (x + 0.5f) which is my standard way of rounding
floats, and rint (x). Same results - the problem remains.
What is even more scary is this: adding a extra printf() _after_ all
the calculations and _after_ a number of other printf() that I have
been using to see what is happening is enough to remove the error -
it modifies the values printed by the previous printf()...
I'm now pretty sure this is the optimiser having an identity
crisis...
24 May
24 May
6:41 a.m.
On Wed, May 23, 2007 at 07:46:21PM -0400, Paul Davis wrote:
fons, i am suprised that you have not run gcc -S and
then diff on the
two asm files yet ....
Will do this. But I expect the diff will produce two unrelated blocks
of asm code, not just a small difference.... When using optimisation
a tiny change in the source can completely re-arrange the code.
--
FA
Follie! Follie! Delirio vano è questo !
23 May
23 May
9:47 p.m.
On 5/23/07, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
On Wed, May 23, 2007 at 04:57:08PM -0500, Jack
O'Quin wrote:
Arrgh! Put it in a separate function to defeat the optimizer?
--
joq
I know less about this than you do, Fons. But, I
always seem to end up
adding a rint() to statements like that. Not because I understand exactly
what is going on, but because otherwise GCC gives me warning messages
about casting float to int.
What happens, if you change those lines like this?...
y = (int) rint((x - a) * b + 0.5f);
Tried both floorf (x + 0.5f) which is my standard way of rounding
floats, and rint (x). Same results - the problem remains.
What is even more scary is this: adding a extra printf() _after_ all
the calculations and _after_ a number of other printf() that I have
been using to see what is happening is enough to remove the error -
it modifies the values printed by the previous printf()...
I'm now pretty sure this is the optimiser having an identity
crisis...
24 May
24 May
10:42 a.m.
On Wed, May 23, 2007 at 06:46:45PM -0500, Jack O'Quin wrote:
Yes, that works, even if inlined.
Meanwhile I've found out what happened. The problem was not with
the float to int conversion, but with the FP calculation itself.
In one case, an intermediate value was stored to memory and
re-used from the stored value. In the second the register value
was used. A FP register has higher precision than a 32-bit FP in
memory, so storing it to memory requires rounding. And rounding
can change even the integer part in some rare cases.
Having both a register and a memory copy of the same variable
can produce very strange results, e.g.
float v;
v = // some calculation
printf ("v = %12.9lf %08x\n", v, *((int *)(&v)));
can print either
v = 29.990000000 41efeb85
or
v = 29.989999771 41efeb85
depending on the context.
In the second line printf() uses the register value for the first
field, in the first the one stored in the variable v. It just depends
on what the optimiser prefers. The hex format always uses the value
stored in v.
--
FA
Follie! Follie! Delirio vano è questo !
On 5/23/07, Fons Adriaensen
<fons(a)kokkinizita.net> wrote:
What is even
more scary is this: adding a extra printf() _after_ all
the calculations and _after_ a number of other printf() that I have
been using to see what is happening is enough to remove the error -
it modifies the values printed by the previous printf()...
I'm now pretty sure this is the optimiser having an identity
crisis...
Arrgh! Put it in a separate function to defeat the optimizer?
9:42 a.m.
fons(a)kokkinizita.net:
1. There is absolutely no ambiguity in order of execution of the statement
above.
- subtract a from x
- multiply by b
- add 0.5
- cast to int
No, but as others has discussed, you have used an optimiser.
Also, what are the values of x, a, b and f, or, what is the numerical
error of the sum? If it is greater than 0.004, you are basically
looking at noise. That is the reason it suggested using doubles.
On Wed, May 23, 2007 at 10:33:12PM +0200, Karl Hammar
wrote:
> On Wed, May 23, 2007 at 10:00:38PM +0200, Fons Adriaensen wrote:
...
float a, b, x;
int y;
y = (int)((x - a) * b + 0.5f);
I have this calculation twice, in the same source file. In one
case it's within a for loop, in the second case it's just a single
calculation. Both use exactly the same values for a, b, and x, yet
the result is different (by 1). The value before the cast its something
like 115.50424, and that gets rounded up in one case and down in the
other.
This is with -O3. Same with -O2, -O1, but OK without optimisation, and
also OK if I use -O3 -march=pentium4.
Is this to be expected, and should I use floorf() to avoid it, or is it
something that should not happen ?
It might not be a bug. You are not guaranteed of the same order of
evaluation of arithmetic expressions in C. If you want that you have
to use FORTRAN or assembler (maybe some other language has it also). 2. In both cases the floating point result was the
same. Only the case to int
was different.
Which cases?
Regards,
/Karl
-----------------------------------------------------------------------
Karl Hammar Aspö Data karl(a)aspodata.se
Lilla Aspö 2340 Networks
S-742 94 Östhammar +46 173 140 57 Computers
Sweden +46 70 511 97 84 Consulting
-----------------------------------------------------------------------
10:42 a.m.
On Wed, May 23, 2007 at 11:54:21PM +0200, Fons Adriaensen wrote:
1. There is absolutely no ambiguity in order of execution of the statement
above.
- subtract a from x
- multiply by b
- add 0.5
- cast to int
2. In both cases the floating point result was the same. Only the case to int
was different.
My guess is that you're running into an issue with floating-point
representations that differ by some value near to machine epsilson.
In these cases, results can get very unpredictable and either
1) Don't do that, or 2) If you must, use a wider floating point
representation. This especially hits in the case of loops because
you may be seeing the effects of accumulated error: 10^(-10) is very
small, but if you accumulate enough of them, they really can affect
your results, potentially enough to change the value of a cast.
Along those lines - is it possible that with -march=pentium4 that gcc
is generating 64- or 128-bit floats? This might be happening if it's
vectorizing your loop via SSE. Paul's -S diff s probably the way to
check this.
Could you provide sample values for a, b, and x along with the results
you are seeing? A source code snippet to compare with would be even
more fun ::-).
--
Ross Vandegrift
ross(a)kallisti.us
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
This is with -O3. Same with -O2, -O1, but OK without
optimisation, and
also OK if I use -O3 -march=pentium4.
Is this to be expected, and should I use floorf() to avoid it, or is it
something that should not happen ?
It might not be a bug. You are not guaranteed of the same order of
evaluation of arithmetic expressions in C. If you want that you have
to use FORTRAN or assembler (maybe some other language has it also). 
7:15 a.m.
Fons Adriaensen wrote:
On Wed, May 23, 2007 at 03:25:26PM -0400, Paul Davis
wrote:
Probably pointing out something obvious:
If you do -march=pentium4 the compiler uses a specific ASM opcode (I
forgot which one) to do the conversion, otherwise it generates some very
inefficient code. Actually specifying -march=pentium is already enough
for this.
The question is: is the behavior still within the spec? If so, there is
nothing wrong. Although it would be nice to have some predictability,
with floats that seems to be somewhat dubious. But I don't know the spec
details, so maybe I should shut up...
Pieter
I am very disappointed to hear that the Debian
package is using
SYSLIBS=1.
This gives me two occasions to show my ignorance instead of just
the one I was going to post :-)
1. What does SYSLIBS=1 imply ?
2. (Original reason for this post)
I've been chasing a bug for hours this afternoon, and the conclusion
is that apparently g++, under some conditions, is not consistent
in the way it rounds floats to ints in a expression such as
float a, b, x;
int y;
y = (int)((x - a) * b + 0.5f);
I have this calculation twice, in the same source file. In one
case it's within a for loop, in the second case it's just a single
calculation. Both use exactly the same values for a, b, and x, yet
the result is different (by 1). The value before the cast its something
like 115.50424, and that gets rounded up in one case and down in the
other.
This is with -O3. Same with -O2, -O1, but OK without optimisation, and
also OK if I use -O3 -march=pentium4. 
8:28 a.m.
Hi,
|--==> Paul Davis writes:
PD> On Wed, 2007-05-23 at 12:14 -0700, Ken Restivo wrote:
>That's what I had to do in order to get Ardour2
going, since the Debian package uses SYSLIBS=1 and thusly makes it non-functional on my
machine.
>
>I tried checkinstall too, but that had issues: apparently the Ardour2 scons target
tries to make symlinks for /usr/bin/gcc, and dpkg rightly refused to allow it to something
so dangerous.
PD> THIS IS NOT TRUE.
PD> its also the 2nd time that its been claimed. please either point to the
PD> line in our scons build system where this happens, or stop claiming that
PD> it does.
PD> I am very disappointed to hear that the Debian package is using
PD> SYSLIBS=1. This means that we will refuse to support any Debian users
PD> that have issues with Ardour. The Debian packager(s) have been told
PD> about this in the past, and we made the consequences of their choices
PD> clear.
I was not aware of the problem (I've stepped into Debian's ardour
maintenance only very recently). A bug was opened two days ago
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425507
I'm going to fix it today. Ciao!
Free
8:35 a.m.
Paul Davis wrote:
I am very disappointed to hear that the Debian package
is using
SYSLIBS=1. This means that we will refuse to support any Debian users
that have issues with Ardour. The Debian packager(s) have been told
about this in the past, and we made the consequences of their choices
clear.
Hmmm. being a long time debian user, this doesn't sound good to me.
Which distro would you recommend for pro audio work? How are studio64
doing in this area? How often is it released? Gentoo/proaudio overlay?
Slackware? I had rather disappointing experiences with rpm based systems
in the past, this might have improved, but I'd still rather avoid rpm
based systems...
--
peace, love & harmony
Atte
http://atte.dk | http://myspace.com/attejensen
http://anagrammer.dk | http://atte.dk/compositions
9:36 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, May 23, 2007 at 03:25:26PM -0400, Paul Davis wrote:
On Wed, 2007-05-23 at 12:14 -0700, Ken Restivo wrote:
No need to shout. I was claiming it because it was in fact happening. It may be a bug in
checkinstall though, and not in scons or in your build. But it's definitely there:
$ cd ardour-2.0.2
$ checkinstall
<answer prompts to build package>
$ dpkg-deb -c ../ardour_2.0.2-1_amd64.deb
- -rw-r--r-- root/root 114 2007-05-06 21:39 ./usr/share/doc/ardour/README
- -rw-r--r-- root/root 17992 2007-05-06 21:39 ./usr/share/doc/ardour/COPYING
- -rw-r--r-- root/root 546 2007-05-06 21:39 ./usr/share/doc/ardour/PACKAGER_README
drwxr-xr-x root/root 0 2007-05-19 17:09 ./usr/bin/
lrwxrwxrwx root/root 0 2007-05-19 17:09 ./usr/bin/gcc -> gcc-4.1
lrwxrwxrwx root/root 0 2007-05-19 17:09 ./usr/bin/g++ -> g++-4.1
Weird.
That's what I had to do in order to get
Ardour2 going, since the Debian package uses SYSLIBS=1 and thusly makes it non-functional
on my machine.
I tried checkinstall too, but that had issues: apparently the Ardour2 scons target tries
to make symlinks for /usr/bin/gcc, and dpkg rightly refused to allow it to something so
dangerous.
THIS IS NOT TRUE.
its also the 2nd time that its been claimed. please either point to the
line in our scons build system where this happens, or stop claiming that
it does.
I am very disappointed to hear that the Debian package is using
SYSLIBS=1. This means that we will refuse to support any Debian users
that have issues with Ardour. The Debian packager(s) have been told
about this in the past, and we made the consequences of their choices
clear.
It looks like the latest Sid package no longer uses SYSLIBS=1, so I guess you were heard.
I still think that The Right Thing would be to find and fix the problem with the system
libs, rather than just bypassing them. But if SYSLIBS=0 works, then that's probably
good enough. FYI, I'm pretty sure that the ardour 0.99 package used the system libs,
and worked fine.
- -ken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFGVh+We8HF+6xeOIcRAmEPAKCXK6rjk9tCQZGEjPMsY4B+BFNG1gCg6U8P
HWqsoJHFfcY7aqzC8OYktpM=
=NrxT
-----END PGP SIGNATURE-----
10:36 p.m.
On Thu, 2007-05-24 at 16:28 -0700, Ken Restivo wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, May 23, 2007 at 03:25:26PM -0400, Paul Davis wrote:
thats a bug in checkinstall. if you run scons install, that will not
happen.
On Wed, 2007-05-23 at 12:14 -0700, Ken Restivo
wrote:
No need to shout. I was claiming it because it was in fact happening. It may be a bug in
checkinstall though, and not in scons or in your build. But it's definitely there:
$ cd ardour-2.0.2
$ checkinstall
<answer prompts to build package>
$ dpkg-deb -c ../ardour_2.0.2-1_amd64.deb
- -rw-r--r-- root/root 114 2007-05-06 21:39 ./usr/share/doc/ardour/README
- -rw-r--r-- root/root 17992 2007-05-06 21:39 ./usr/share/doc/ardour/COPYING
- -rw-r--r-- root/root 546 2007-05-06 21:39 ./usr/share/doc/ardour/PACKAGER_README
drwxr-xr-x root/root 0 2007-05-19 17:09 ./usr/bin/
lrwxrwxrwx root/root 0 2007-05-19 17:09 ./usr/bin/gcc -> gcc-4.1
lrwxrwxrwx root/root 0 2007-05-19 17:09 ./usr/bin/g++ -> g++-4.1
Weird. That's what I had to do in order to get
Ardour2 going, since the Debian package uses SYSLIBS=1 and thusly makes it non-functional
on my machine.
I tried checkinstall too, but that had issues: apparently the Ardour2 scons target tries
to make symlinks for /usr/bin/gcc, and dpkg rightly refused to allow it to something so
dangerous.
THIS IS NOT TRUE.
its also the 2nd time that its been claimed. please either point to the
line in our scons build system where this happens, or stop claiming that
it does. I still think that The Right Thing would be to find
and fix the problem with the system libs, rather than just bypassing them. But if
SYSLIBS=0 works, then that's probably good enough. FYI, I'm pretty sure that the
ardour 0.99 package used the system libs, and worked fine.
its not a problem with the system libs. its a problem when some
unknowing user, for whatever reason, installs a new version of g++ and
rebuilds either ardour or the affected libraries, but not both. bizarre
behaviour ensues, we waste hours or days tracking it down, only to find
that its another problem with mismatching g++ issues. it doesn't even
need that - at least one distro built some of its c++ libraries so that
they didn't use exceptions, which then breaks other c++ code.
we dealt with this years ago by deciding to include every c++ library
that ardour uses in the source tree, except those that actually come
with the compiler.
we did not sanction the use of SYSLIBS=1 for ardour 0.99.3, and we will
not sanction it for any version in the future.
--p
25 May
25 May
4:47 p.m.
http://ubuntustudio.com/
Well, not exactly Debian, but close. :-)
--
Florin Andrei
http://florin.myip.org/
6445
days inactive
6447
days old
linux-audio-user@lists.linuxaudio.org
20 comments
12 participants
participants (12)
-
Atte André Jensen -
Florin Andrei -
Fons Adriaensen -
Free Ekanayaka -
Jack O'Quin -
James Stone -
Josh Lawrence -
karl＠aspodata.se -
Ken Restivo -
Paul Davis -
Pieter Palmers -
Ross Vandegrift