|
From: Benjamin Drung <bdrung@ub...> - 2010-09-19 14:10:54
Attachments:
application/pgp-signature
|
Hi,
audacity trunk fails to build on Ubuntu:
g++ -c -g -O2 -I../lib-src/portmixer/include
-I../lib-src/portaudio-v19/include -g -O2 -Wall
-I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8
-D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread
-I../lib-src/FileDialog -g -O2 -Wall -I/build/buildd/audacity-1.3.12
+svn201009190112+r6386/lib-src/lib-widget-extra
-I../lib-src/sbsms/include -I/usr/include/soundtouch
-I../lib-src/libnyquist -g -O2 -Wall
-I/build/buildd/audacity-1.3.12+svn201009190112+r6386/lib-src/portsmf
-fno-strict-aliasing -I./include -I. -DLIBDIR=\"/usr/lib\"
-D__STDC_CONSTANT_MACROS -Wall -pthread -D_REENTRANT
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12
DirManager.cpp -o DirManager.o
In file included from blockfile/../ondemand/../Project.h:27,
from blockfile/../ondemand/ODTask.h:28,
from blockfile/../ondemand/ODDecodeTask.h:32,
from blockfile/ODDecodeBlockFile.h:34,
from DirManager.cpp:81:
blockfile/../ondemand/../AudioIO.h:22:22: error: portmidi.h: No such file or directory
blockfile/../ondemand/../AudioIO.h:23:22: error: porttime.h: No such file or directory
g++ -c -g -O2 -I../lib-src/portmixer/include -I../lib-src/portaudio-v19/include -g -O2 -Wall -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../lib-src/FileDialog -g -O2 -Wall -I/build/buildd/audacity-1.3.12+svn201009190112+r6386/lib-src/lib-widget-extra -I../lib-src/sbsms/include -I/usr/include/soundtouch -I../lib-src/libnyquist -g -O2 -Wall -I/build/buildd/audacity-1.3.12+svn201009190112+r6386/lib-src/portsmf -fno-strict-aliasing -I./include -I. -DLIBDIR=\"/usr/lib\" -D__STDC_CONSTANT_MACROS -Wall -pthread -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 FileFormats.cpp -o FileFormats.o
In file included from blockfile/../ondemand/../AudioIO.h:25,
from blockfile/../ondemand/../Project.h:27,
from blockfile/../ondemand/ODTask.h:28,
from blockfile/../ondemand/ODDecodeTask.h:32,
from blockfile/ODDecodeBlockFile.h:34,
from DirManager.cpp:81:
/build/buildd/audacity-1.3.12+svn201009190112+r6386/lib-src/portsmf/allegro.h: In constructor 'Alg_parameter::Alg_parameter()':
/build/buildd/audacity-1.3.12+svn201009190112+r6386/lib-src/portsmf/allegro.h:121: warning: deprecated conversion from string constant to 'char*'
In file included from blockfile/../ondemand/../Project.h:27,
from blockfile/../ondemand/ODTask.h:28,
from blockfile/../ondemand/ODDecodeTask.h:32,
from blockfile/ODDecodeBlockFile.h:34,
from DirManager.cpp:81:
blockfile/../ondemand/../AudioIO.h: At global scope:
blockfile/../ondemand/../AudioIO.h:144: error: 'PmTimestamp' does not name a type
blockfile/../ondemand/../AudioIO.h:402: error: ISO C++ forbids declaration of 'PmStream' with no type
blockfile/../ondemand/../AudioIO.h:402: error: expected ';' before '*' token
blockfile/../ondemand/../AudioIO.h:403: error: 'PmError' does not name a type
Full build log: http://launchpadlibrarian.net/55934723/buildlog_ubuntu-lucid-amd64.audacity_1.3.12%2Bsvn201009190112%2Br6386-0~lucid1_FAILEDTOBUILD.txt.gz
--
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)
|
|
From: Benjamin Drung <bdrung@ub...> - 2010-10-05 10:56:00
Attachments:
application/pgp-signature
|
Hi, audacity trunks fails to build on Ubuntu. The last known building revision was 10703 and the first known failing one was 10714. The ending of the build failure (but probably not the cause): ar cru libnyquist.a extern.o xldmem.o xlbfun.o xlcont.o xldbug.o xleval.o xlfio.o xlftab.o xlglob.o xlimage.o xlinit.o xlio.o xlisp.o xljump.o xllist.o xlmath.o xlobj.o xlpp.o xlprin.o xlread.o xlstr.o xlsubr.o xlsym.o xlsys.o path.o abs.o allpoles.o alpass.o alpasscv.o alpassvv.o amosc.o areson.o aresonvc.o aresoncv.o aresonvv.o atone.o atonev.o biquadfilt.o buzz.o chase.o clip.o congen.o const.o coterm.o delaycc.o delaycv.o eqbandvvv.o exp.o follow.o fmosc.o fromobject.o fromarraystream.o gate.o ifft.o instrclar.o instrclarall.o instrclarfreq.o instrsax.o instrsaxall.o instrsaxfreq.o integrate.o log.o lpreson.o maxv.o offset.o oneshot.o osc.o partial.o pluck.o prod.o pwl.o quantize.o recip.o reson.o resonvc.o resoncv.o resonvv.o sampler.o scale.o shape.o sine.o siosc.o slope.o sqrt.o tapf.o tapv.o tone.o tonev.o upsample.o white.o stkrev.o stkpitshift.o stkchorus.o instrbow.o instrbowedfreq.o instrbanded.o instrmandolin.o instrsitar.o instrmodalbar.o instrflute.o instrflutefreq.o instrfluteall.o fmfb.o fmfbv.o cext.o cleanup.o cmdline.o cmtcmd.o moxc.o mem.o midifile.o midifns.o record.o seq.o seqmread.o seqmwrite.o seqread.o seqwrite.o tempomap.o timebase.o userio.o debug.o falloc.o local.o handlers.o multiread.o seqext.o seqinterf.o stats.o ffilterkit.o sliders.o sound.o add.o avg.o compose.o convolve.o downsample.o fft.o inverse.o multiseq.o resamp.o resampv.o samples.o sndmax.o sndread.o sndseq.o sndwritepa.o yin.o trigger.o lpanal.o Generator.o SineWave.o Function.o FileRead.o FileWvIn.o Effect.o Clarinet.o Delay.o DelayL.o Envelope.o Filter.o Instrmnt.o Noise.o OneZero.o ReedTable.o Saxofony.o Stk.o WaveLoop.o WvIn.o NRev.o JCRev.o PRCRev.o PitShift.o Chorus.o Bowed.o BowTable.o ADSR.o OnePole.o BiQuad.o BandedWG.o DelayA.o Mandolin.o PluckTwo.o Sitar.o ModalBar.o Modal.o Flute.o JetTable.o PoleZero.o stkinit.o instr.o stkint.o fftext.o fftlib.o matlib.o sndfnint.o seqfnint.o nyx.o ranlib libnyquist.a make[3]: Leaving directory `/build/buildd/audacity-1.3.12 +svn201010040012+r6412/lib-src/libnyquist' make[2]: Leaving directory `/build/buildd/audacity-1.3.12 +svn201010040012+r6412/lib-src' make[1]: *** [audacity] Error 2 make[1]: Leaving directory `/build/buildd/audacity-1.3.12 +svn201010040012+r6412' Here's the full build log: http://launchpadlibrarian.net/57059422/buildlog_ubuntu-maverick-amd64.audacity_1.3.12%2Bsvn201010040012%2Br6412-0~maverick1_FAILEDTOBUILD.txt.gz -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) |
|
From: Richard Ash <richard@au...> - 2010-10-05 21:18:00
|
On Tue, 2010-10-05 at 12:55 +0200, Benjamin Drung wrote: > audacity trunks fails to build on Ubuntu. The last known building > revision was 10703 and the first known failing one was 10714. > > The ending of the build failure (but probably not the cause): Definitely not the cause. What goes wrong is that the portaudio-v19 build fails with a libtool-related build error just before 50% down the log file. I don't know yet what causes this - my amd64 build works fine ... What libtool version does your build host have? Richard |
|
From: Benjamin Drung <bdrung@ub...> - 2010-10-05 21:23:11
Attachments:
application/pgp-signature
|
Am Dienstag, den 05.10.2010, 22:17 +0100 schrieb Richard Ash: > On Tue, 2010-10-05 at 12:55 +0200, Benjamin Drung wrote: > > audacity trunks fails to build on Ubuntu. The last known building > > revision was 10703 and the first known failing one was 10714. > > > > The ending of the build failure (but probably not the cause): > > Definitely not the cause. What goes wrong is that the portaudio-v19 > build fails with a libtool-related build error just before 50% down the > log file. > > I don't know yet what causes this - my amd64 build works fine ... What > libtool version does your build host have? libtool 2.2.6a and 2.2.6b [1]. The build failed on i386 and amd64 on Ubuntu 9.10 till 10.10 (karmic till maverick) [2]. [1] http://packages.ubuntu.com/search?keywords=libtool&searchon=names&exact=1 [2] https://launchpad.net/~audacity-team/+archive/daily -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) |
|
From: Ashton Alan Kemerling <ashtonkemerling@gm...> - 2010-10-14 19:40:24
|
I'm still getting the exact same error for r10730 on Ubuntu 10.10 64 bit, libtool 2.2.6b --Ashton On Tue, 2010-10-05 at 23:23 +0200, Benjamin Drung wrote: > Am Dienstag, den 05.10.2010, 22:17 +0100 schrieb Richard Ash: > > On Tue, 2010-10-05 at 12:55 +0200, Benjamin Drung wrote: > > > audacity trunks fails to build on Ubuntu. The last known building > > > revision was 10703 and the first known failing one was 10714. > > > > > > The ending of the build failure (but probably not the cause): > > > > Definitely not the cause. What goes wrong is that the portaudio-v19 > > build fails with a libtool-related build error just before 50% down the > > log file. > > > > I don't know yet what causes this - my amd64 build works fine ... What > > libtool version does your build host have? > > libtool 2.2.6a and 2.2.6b [1]. The build failed on i386 and amd64 on > Ubuntu 9.10 till 10.10 (karmic till maverick) [2]. > > [1] > http://packages.ubuntu.com/search?keywords=libtool&searchon=names&exact=1 > [2] https://launchpad.net/~audacity-team/+archive/daily > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ audacity-devel mailing list audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|
From: Gale Andrews <gale@au...> - 2010-10-15 14:51:14
|
| From Ashton Alan Kemerling <ashtonkemerling@...> | Thu, 14 Oct 2010 14:40:01 -0500 | Subject: [Audacity-devel] audacity trunk fails to build on Ubuntu > I'm still getting the exact same error for r10730 on Ubuntu 10.10 64 > bit, libtool 2.2.6b I tried doing some searching on "eval: 1: libtool_args+=: not found" and came up with this: http://www.mail-archive.com/bacula-devel@.../msg04127.html which states "freshly installed ubuntus link /bin/sh to /bin/dash. Seems that some scripts use bashisms." But it doesn't help me. I actually tried their suggestion: rm /bin/sh && ln -s /bin/bash /bin/sh which wrecked Ubuntu 10.04 - even sudo didn't give me permission to create the symlink. Anyway if just typing "bash" at the command prompt changes the shell, it doesn't help me on Ubuntu 10.10 - I still get the "eval: 1: libtool_args+=: not found", then "syntax error in VERSION script". Sorry for ignorance. Gale > On Tue, 2010-10-05 at 23:23 +0200, Benjamin Drung wrote: > > Am Dienstag, den 05.10.2010, 22:17 +0100 schrieb Richard Ash: > > > On Tue, 2010-10-05 at 12:55 +0200, Benjamin Drung wrote: > > > > audacity trunks fails to build on Ubuntu. The last known building > > > > revision was 10703 and the first known failing one was 10714. > > > > > > > > The ending of the build failure (but probably not the cause): > > > > > > Definitely not the cause. What goes wrong is that the portaudio-v19 > > > build fails with a libtool-related build error just before 50% down the > > > log file. > > > > > > I don't know yet what causes this - my amd64 build works fine ... What > > > libtool version does your build host have? > > > > libtool 2.2.6a and 2.2.6b [1]. The build failed on i386 and amd64 on > > Ubuntu 9.10 till 10.10 (karmic till maverick) [2]. > > > > [1] > > http://packages.ubuntu.com/search?keywords=libtool&searchon=names&exact=1 > > [2] https://launchpad.net/~audacity-team/+archive/daily |
|
From: Brian McKenna <brian@br...> - 2010-10-16 00:02:36
|
Thanks for the info. I was able to compile by changing into the lib-src/portaudio-v19 directory and running line 3936 of the posted buildlog with /bin/bash instead of /bin/sh Hopefully that will help. Thanks, Brian McKenna On 16 October 2010 00:51, Gale Andrews <gale@...> wrote: > > | From Ashton Alan Kemerling <ashtonkemerling@...> > | Thu, 14 Oct 2010 14:40:01 -0500 > | Subject: [Audacity-devel] audacity trunk fails to build on Ubuntu >> I'm still getting the exact same error for r10730 on Ubuntu 10.10 64 >> bit, libtool 2.2.6b > > I tried doing some searching on "eval: 1: libtool_args+=: not found" > and came up with this: > http://www.mail-archive.com/bacula-devel@.../msg04127.html > > which states > > "freshly installed ubuntus link /bin/sh to /bin/dash. Seems that some > scripts use bashisms." > > But it doesn't help me. I actually tried their suggestion: > > rm /bin/sh && ln -s /bin/bash /bin/sh > > which wrecked Ubuntu 10.04 - even sudo didn't give me permission > to create the symlink. > > Anyway if just typing "bash" at the command prompt changes the shell, it > doesn't help me on Ubuntu 10.10 - I still get the > "eval: 1: libtool_args+=: not found", then "syntax error in VERSION script". > > Sorry for ignorance. > > > > > > Gale |
|
From: Richard Ash <richard@au...> - 2010-10-16 17:11:28
|
On Fri, 2010-10-15 at 15:51 +0100, Gale Andrews wrote: > | From Ashton Alan Kemerling <ashtonkemerling@...> > | Thu, 14 Oct 2010 14:40:01 -0500 > | Subject: [Audacity-devel] audacity trunk fails to build on Ubuntu > > I'm still getting the exact same error for r10730 on Ubuntu 10.10 64 > > bit, libtool 2.2.6b > > I tried doing some searching on "eval: 1: libtool_args+=: not found" > and came up with this: > http://www.mail-archive.com/bacula-devel@.../msg04127.html > > which states > > "freshly installed ubuntus link /bin/sh to /bin/dash. Seems that some > scripts use bashisms." > > But it doesn't help me. It does help me replicate the problem however because I can now get the error to happen here (after installing dash and linking it to /bin/sh). This explains why it was looking increasingly like an Ubuntu-only problem, and saves me trying to install Ubuntu to work out why. > Anyway if just typing "bash" at the command prompt changes the shell, it > doesn't help me on Ubuntu 10.10 - I still get the > "eval: 1: libtool_args+=: not found", then "syntax error in VERSION script". It doesn't. The problem is really a hack in autoconf / configure which is setting a variable into libtool which it shouldn't. By forcing configure to use a specific shell the auto-detection is disabled and things start working. So CONFIG_SHELL=/bin/dash ./configure ; make will work and let you build Audacity. More generally (for any distribution where /bin/sh != /bin/bash) you can use CONFIG_SHELL=/bin/sh ./configure ; make which ensures that the shell which runs configure is also /bin/sh (via the obvious mechanism). This only works provided that /bin/sh is smart enough to run configure, but that includes most likely shells. The bigger question is what about portaudio in particular makes it so sensitive to what shell is used. Just running configure in the upstream portaudio sources seems to work fine with /bin/sh == /bin/dash (as it does with /bin/sh == /bin/bash) so at first glance it seems to be a problem with something that Audacity is doing differently, or a local patch we are carrying. The problem in the linked bug report seems to be a "clever" hack in the specific project concerned, and there is nothing like that in portaudio's configure. Copying the command line from the Audacity configure script (i.e. the way that portaudio-v19's configure is called) works fine, which suggests that the problem is not with the arguments given (this also explicitly runs the configure script with /bin/sh, which ought to stop the problem happening). The problem seems to be closely related however, because in portaudio's makefile (in the Audacity source tree) I find LIBTOOL = $(SHELL) $(top_builddir)/libtool yet at the top of portaudio's libtool (same tree) #! /bin/bash If I amend the makefile to read LIBTOOL = $(top_builddir)/libtool then I can build fine (because libtool is allowed to choose it's own shell). However the same mismatch exists in the upstream portaudio, and that builds correctly. This is also not a permanent solution because Makefile is generated from Makefile.in, where it just says LIBTOOL = @LIBTOOL@ so the value of the libtool substitution seems to be entirely in the hands of config.status when it processes Makefile.in This seems to be leading somewhere: portaudio in upstream is still using old libtool 1.5, which for all it's other weaknesses is (apparently) immune to this bug, where as Audacity has upgraded to use libtool 2.2.x everywhere (largely because things didn't work on OS X with the old libtool), where this bug does happen. If I fully upgrade portaudio sources to libtool 2.2.10 (that is, remove the libtool script, remove all aclocal.m4 files, run libtoolize --copy --force, run aclocal, run autoconf) then I can reproduce the Audacity problem. Failure to do all of the above will just cause libtool version mis-matches as portaudio doesn't carry the libtool .m4 files in it's source tree, but does seem to carry aclocal.m4 files (which is considered a bad idea at the very least). So we have a problem which is definitely present with autoconf-2.65 and libtool-2.2.10 (on the system which updates the sources, i.e. mine) when configured on a system with /bin/sh != /bin/bash. It's not yet clear if this is general (i.e. if I re-do another libtool-based library will I break it?) or not. I will try and delve further when I get the time, as google doesn't seem to have anything directly relevant. Richard |
|
From: Richard Ash <richard@au...> - 2010-10-20 19:52:23
|
On Sat, 2010-10-16 at 17:08 +0100, Richard Ash wrote: > So we have a problem which is definitely present with autoconf-2.65 and > libtool-2.2.10 (on the system which updates the sources, i.e. mine) when > configured on a system with /bin/sh != /bin/bash. It's not yet clear if > this is general (i.e. if I re-do another libtool-based library will I > break it?) or not. The answer turned out to be no. This then gave me a reference situation where one package (libvorbis) worked and the other (portaudio-v19) didn't. Fairly quickly it became apparent that in libvorbis's Makefile LIBTOOL = $(SHELL) $(top_builddir)/libtool worked, where as in portaudio-v19's LIBTOOL = $(SHELL) $(top_builddir)/libtool didn't. This fairly severely limited the possible causes of the problem, and lead to checking the value of $(SHELL) when libtool is run, which confirmed that in portaudio's case it was /bin/sh but in libvorbis's case it was /bin/bash. At this point the world seems to be spinning - why is $(SHELL) different for different people? http://www.gnu.org/software/hello/manual/autoconf/The-Make-Macro-SHELL.html explains - although $SHELL is a GNU make built-in variable (and so always set), it's considerably special, so it doesn't take the value of the external environment variable SHELL (which would be normal), nor is it set to the parent shell ... The reason this affects portaudio and not libvorbis is because portaudio (for what no doubt seemed like good ideas at the time) uses libtool and autoconf but not automake. libvorbis is more reasonable and uses all three. As a result, portaudio's Makefile.in ('maintained' by hand) doesn't set $SHELL where as the Makefile.in for libvorbis (created by autoconf) does set $SHELL to whatever configure (the creator of libtool) thinks it is. Hence a breakage in one case and not the other. The solution is of course simple - substitute $SHELL in portaudio's Makefile.in, and all is well again. This is the sort of hand-holding that Automake is designed to avoid doing ... Patch is now in audacity SVN and I will submit it upstream. Richard |
|
From: Benjamin Drung <bdrung@ub...> - 2010-10-20 20:24:35
Attachments:
application/pgp-signature
|
Am Mittwoch, den 20.10.2010, 20:51 +0100 schrieb Richard Ash: > On Sat, 2010-10-16 at 17:08 +0100, Richard Ash wrote: > > So we have a problem which is definitely present with autoconf-2.65 and > > libtool-2.2.10 (on the system which updates the sources, i.e. mine) when > > configured on a system with /bin/sh != /bin/bash. It's not yet clear if > > this is general (i.e. if I re-do another libtool-based library will I > > break it?) or not. > The answer turned out to be no. This then gave me a reference situation > where one package (libvorbis) worked and the other (portaudio-v19) > didn't. Fairly quickly it became apparent that in libvorbis's Makefile > > LIBTOOL = $(SHELL) $(top_builddir)/libtool > > worked, where as in portaudio-v19's > > LIBTOOL = $(SHELL) $(top_builddir)/libtool > > didn't. This fairly severely limited the possible causes of the problem, > and lead to checking the value of $(SHELL) when libtool is run, which > confirmed that in portaudio's case it was /bin/sh but in libvorbis's > case it was /bin/bash. > > At this point the world seems to be spinning - why is $(SHELL) different > for different people? > http://www.gnu.org/software/hello/manual/autoconf/The-Make-Macro-SHELL.html > explains - although $SHELL is a GNU make built-in variable (and so > always set), it's considerably special, so it doesn't take the value of > the external environment variable SHELL (which would be normal), nor is > it set to the parent shell ... > > The reason this affects portaudio and not libvorbis is because portaudio > (for what no doubt seemed like good ideas at the time) uses libtool and > autoconf but not automake. libvorbis is more reasonable and uses all > three. As a result, portaudio's Makefile.in ('maintained' by hand) > doesn't set $SHELL where as the Makefile.in for libvorbis (created by > autoconf) does set $SHELL to whatever configure (the creator of libtool) > thinks it is. > > Hence a breakage in one case and not the other. The solution is of > course simple - substitute $SHELL in portaudio's Makefile.in, and all is > well again. This is the sort of hand-holding that Automake is designed > to avoid doing ... > > Patch is now in audacity SVN and I will submit it upstream. Thanks for digging through autotools. trunk builds again on Ubuntu. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) |
|
From: Martyn Shaw <martynshaw99@gm...> - 2010-10-21 00:09:36
|
Wow Richard! That's some sleuthing! TTFN Martyn On 20/10/2010 20:51, Richard Ash wrote: > On Sat, 2010-10-16 at 17:08 +0100, Richard Ash wrote: >> So we have a problem which is definitely present with autoconf-2.65 and >> libtool-2.2.10 (on the system which updates the sources, i.e. mine) when >> configured on a system with /bin/sh != /bin/bash. It's not yet clear if >> this is general (i.e. if I re-do another libtool-based library will I >> break it?) or not. > The answer turned out to be no. This then gave me a reference situation > where one package (libvorbis) worked and the other (portaudio-v19) > didn't. Fairly quickly it became apparent that in libvorbis's Makefile > > LIBTOOL = $(SHELL) $(top_builddir)/libtool > > worked, where as in portaudio-v19's > > LIBTOOL = $(SHELL) $(top_builddir)/libtool > > didn't. This fairly severely limited the possible causes of the problem, > and lead to checking the value of $(SHELL) when libtool is run, which > confirmed that in portaudio's case it was /bin/sh but in libvorbis's > case it was /bin/bash. > > At this point the world seems to be spinning - why is $(SHELL) different > for different people? > http://www.gnu.org/software/hello/manual/autoconf/The-Make-Macro-SHELL.html > explains - although $SHELL is a GNU make built-in variable (and so > always set), it's considerably special, so it doesn't take the value of > the external environment variable SHELL (which would be normal), nor is > it set to the parent shell ... > > The reason this affects portaudio and not libvorbis is because portaudio > (for what no doubt seemed like good ideas at the time) uses libtool and > autoconf but not automake. libvorbis is more reasonable and uses all > three. As a result, portaudio's Makefile.in ('maintained' by hand) > doesn't set $SHELL where as the Makefile.in for libvorbis (created by > autoconf) does set $SHELL to whatever configure (the creator of libtool) > thinks it is. > > Hence a breakage in one case and not the other. The solution is of > course simple - substitute $SHELL in portaudio's Makefile.in, and all is > well again. This is the sort of hand-holding that Automake is designed > to avoid doing ... > > Patch is now in audacity SVN and I will submit it upstream. > > Richard > > > > ------------------------------------------------------------------------------ > Nokia and AT&T present the 2010 Calling All Innovators-North America contest > Create new apps& games for the Nokia N8 for consumers in U.S. and Canada > $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store > http://p.sf.net/sfu/nokia-dev2dev > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
|
From: Steve the Fiddle <stevethefiddle@gm...> - 2010-10-16 16:25:01
|
Thanks Brian, Finally managed to get the current svn version to build using line 3936 of the posted build-log with /bin/bash instead of /bin/sh Audacity runs, but the first things I notice are: Audacity cannot use the standard distribution version of FFmpeg (no problem with the distro installation of Audacity 1.3.12) The Sync-lock button looks out of place with a white clock face (all other icons are in shades of grey) The sliders on the mixer toolbar are the wrong colour. Steve On Sat, Oct 16, 2010 at 1:02 AM, Brian McKenna <brian@...> wrote: > Thanks for the info. I was able to compile by changing into the > lib-src/portaudio-v19 directory and running line 3936 of the posted > buildlog with /bin/bash instead of /bin/sh > > Hopefully that will help. > > Thanks, > Brian McKenna > > On 16 October 2010 00:51, Gale Andrews <gale@...> wrote: >> >> | From Ashton Alan Kemerling <ashtonkemerling@...> >> | Thu, 14 Oct 2010 14:40:01 -0500 >> | Subject: [Audacity-devel] audacity trunk fails to build on Ubuntu >>> I'm still getting the exact same error for r10730 on Ubuntu 10.10 64 >>> bit, libtool 2.2.6b >> >> I tried doing some searching on "eval: 1: libtool_args+=: not found" >> and came up with this: >> http://www.mail-archive.com/bacula-devel@.../msg04127.html >> >> which states >> >> "freshly installed ubuntus link /bin/sh to /bin/dash. Seems that some >> scripts use bashisms." >> >> But it doesn't help me. I actually tried their suggestion: >> >> rm /bin/sh && ln -s /bin/bash /bin/sh >> >> which wrecked Ubuntu 10.04 - even sudo didn't give me permission >> to create the symlink. >> >> Anyway if just typing "bash" at the command prompt changes the shell, it >> doesn't help me on Ubuntu 10.10 - I still get the >> "eval: 1: libtool_args+=: not found", then "syntax error in VERSION script". >> >> Sorry for ignorance. >> >> >> >> >> >> Gale > |
|
From: Alexandre Prokoudine <alexandre.prokoudine@gm...> - 2010-10-17 00:13:07
|
On 10/16/10, Steve the Fiddle wrote: > The sliders on the mixer toolbar are the wrong colour. There have been something wrong with color of Audacity's UI since forever. It simply uses wrong color from GTK+ theme. I wonder if I'm the only one who thinks it's a disgrace. Alexandre Prokoudine http://libregraphicsworld.org |
|
From: Benjamin Drung <bdrung@ub...> - 2010-10-18 11:28:12
Attachments:
application/pgp-signature
|
Am Samstag, den 16.10.2010, 17:24 +0100 schrieb Steve the Fiddle: > Audacity runs, but the first things I notice are: > Audacity cannot use the standard distribution version of FFmpeg (no > problem with the distro installation of Audacity 1.3.12) That's the ffmpeg-av-match-ext.patch [1]. > The Sync-lock button looks out of place with a white clock face (all > other icons are in shades of grey) > The sliders on the mixer toolbar are the wrong colour. That's fix-slider-background-color.patch, which improves the situation, but doesn't fix the color issue completely. [1] http://git.debian.org/?p=pkg-multimedia/audacity.git;a=tree;f=debian/patches;hb=refs/heads/experimental -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) |
|
From: Richard Ash <richard@au...> - 2010-10-16 16:30:55
|
On Sat, 2010-10-16 at 17:24 +0100, Steve the Fiddle wrote: > Audacity cannot use the standard distribution version of FFmpeg (no > problem with the distro installation of Audacity 1.3.12) "standard distribution version of FFmpeg" being what version? Richard |
|
From: Steve the Fiddle <stevethefiddle@gm...> - 2010-10-16 16:42:52
|
ffmpeg is listed in Synaptic as: 4:0.6-2ubuntu6 The name of the shared library is libavformat.so.52.64.2 Audacity 1.3.12 (Ubuntu build) reports: FFmpeg Library Version: F(52.64.2),C(52.72.2),U(50.15.1) Steve On Sat, Oct 16, 2010 at 5:30 PM, Richard Ash <richard@...> wrote: > On Sat, 2010-10-16 at 17:24 +0100, Steve the Fiddle wrote: >> Audacity cannot use the standard distribution version of FFmpeg (no >> problem with the distro installation of Audacity 1.3.12) > "standard distribution version of FFmpeg" being what version? > > Richard > > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
|
From: Gale Andrews <gale@au...> - 2010-10-16 18:05:11
|
| From Steve the Fiddle <stevethefiddle@...> | Sat, 16 Oct 2010 17:42:46 +0100 | Subject: [Audacity-devel] [Audacity-quality] audacity trunk fails to build on Ubuntu > ffmpeg is listed in Synaptic as: 4:0.6-2ubuntu6 > The name of the shared library is libavformat.so.52.64.2 > Audacity 1.3.12 (Ubuntu build) reports: FFmpeg Library Version: > F(52.64.2),C(52.72.2),U(50.15.1) That's recent. Audacity can't use FFmpeg beyond end of 2009: http://bugzilla.audacityteam.org/show_bug.cgi?id=176 Since 1.3.12 packaged with Ubuntu 10.10 recognises such a recent FFmpeg, Ubuntu must have modified it do so. Gale > On Sat, Oct 16, 2010 at 5:30 PM, Richard Ash <richard@...> wrote: > > On Sat, 2010-10-16 at 17:24 +0100, Steve the Fiddle wrote: > >> Audacity cannot use the standard distribution version of FFmpeg (no > >> problem with the distro installation of Audacity 1.3.12) > > "standard distribution version of FFmpeg" being what version? > > > > Richard |
|
From: Vaughan Johnson <vaughan@au...> - 2010-10-17 00:30:48
|
On 10/16/2010 5:13 PM, Alexandre Prokoudine wrote: > On 10/16/10, Steve the Fiddle wrote: > >> The sliders on the mixer toolbar are the wrong colour. > > There have been something wrong with color of Audacity's UI since > forever. It simply uses wrong color from GTK+ theme. I wonder if I'm > the only one who thinks it's a disgrace. > I agree, now that I know about it. Can you tell me what color to use? I think we're getting all those from wxSystemSettings::GetColour() so it might be a bug in wxWidgets on GTK+. - Vaughan |
|
From: Steve the Fiddle <stevethefiddle@gm...> - 2010-10-17 09:03:50
|
It may be worth looking at what Ubuntu have done. In the Ubuntu build the sliders are the same colour as the rest of the background. Steve On Sun, Oct 17, 2010 at 1:31 AM, Vaughan Johnson <vaughan@...> wrote: > On 10/16/2010 5:13 PM, Alexandre Prokoudine wrote: >> On 10/16/10, Steve the Fiddle wrote: >> >>> The sliders on the mixer toolbar are the wrong colour. >> >> There have been something wrong with color of Audacity's UI since >> forever. It simply uses wrong color from GTK+ theme. I wonder if I'm >> the only one who thinks it's a disgrace. >> > > I agree, now that I know about it. Can you tell me what color to use? I > think we're getting all those from wxSystemSettings::GetColour() so it > might be a bug in wxWidgets on GTK+. > > - Vaughan > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
|
From: Steve the Fiddle <stevethefiddle@gm...> - 2010-10-17 10:24:54
Attachments:
fix-slider-background-color.patch
|
This is the patch that Ubuntu use to fix the slider colour (attached) Steve On Sun, Oct 17, 2010 at 10:03 AM, Steve the Fiddle <stevethefiddle@...> wrote: > It may be worth looking at what Ubuntu have done. In the Ubuntu build > the sliders are the same colour as the rest of the background. > > Steve > > On Sun, Oct 17, 2010 at 1:31 AM, Vaughan Johnson > <vaughan@...> wrote: >> On 10/16/2010 5:13 PM, Alexandre Prokoudine wrote: >>> On 10/16/10, Steve the Fiddle wrote: >>> >>>> The sliders on the mixer toolbar are the wrong colour. >>> >>> There have been something wrong with color of Audacity's UI since >>> forever. It simply uses wrong color from GTK+ theme. I wonder if I'm >>> the only one who thinks it's a disgrace. >>> >> >> I agree, now that I know about it. Can you tell me what color to use? I >> think we're getting all those from wxSystemSettings::GetColour() so it >> might be a bug in wxWidgets on GTK+. >> >> - Vaughan >> >> ------------------------------------------------------------------------------ >> Download new Adobe(R) Flash(R) Builder(TM) 4 >> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly >> Flex(R) Builder(TM)) enable the development of rich applications that run >> across multiple browsers and platforms. Download your free trials today! >> http://p.sf.net/sfu/adobe-dev2dev >> _______________________________________________ >> audacity-devel mailing list >> audacity-devel@... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> > |
|
From: Alexandre Prokoudine <alexandre.prokoudine@gm...> - 2010-10-21 05:52:25
Attachments:
audacity.png
|
On 10/17/10, Vaughan Johnson wrote: >>> The sliders on the mixer toolbar are the wrong colour. >> >> There have been something wrong with color of Audacity's UI since >> forever. It simply uses wrong color from GTK+ theme. I wonder if I'm >> the only one who thinks it's a disgrace. > > I agree, now that I know about it. Can you tell me what color to use? I > think we're getting all those from wxSystemSettings::GetColour() so it > might be a bug in wxWidgets on GTK+. I'm afraid I'm the wrong person to ask a technical question about that :) Attached is a screenshot of Audacity before you guys "fixed" the slider's background. This is default GTK+ theme on Ubuntu 10.04. As you can easily see, the "wrong" color of sliders was actually the right one, contrary to most of UI. Alexandre Prokoudine http://libregraphicsworld.org |
|
From: Benjamin Drung <bdrung@ub...> - 2010-10-21 08:28:51
Attachments:
application/pgp-signature
|
Am Donnerstag, den 21.10.2010, 09:52 +0400 schrieb Alexandre Prokoudine: > On 10/17/10, Vaughan Johnson wrote: > > >>> The sliders on the mixer toolbar are the wrong colour. > >> > >> There have been something wrong with color of Audacity's UI since > >> forever. It simply uses wrong color from GTK+ theme. I wonder if I'm > >> the only one who thinks it's a disgrace. > > > > I agree, now that I know about it. Can you tell me what color to use? I > > think we're getting all those from wxSystemSettings::GetColour() so it > > might be a bug in wxWidgets on GTK+. > > I'm afraid I'm the wrong person to ask a technical question about that :) > > Attached is a screenshot of Audacity before you guys "fixed" the > slider's background. This is default GTK+ theme on Ubuntu 10.04. As > you can easily see, the "wrong" color of sliders was actually the > right one, contrary to most of UI. Which revision did you take? Al committed improved my patch in r10744. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) |
|
From: Alexandre Prokoudine <alexandre.prokoudine@gm...> - 2010-10-21 09:15:55
|
On Thu, Oct 21, 2010 at 12:28 PM, Benjamin Drung wrote: >> >> There have been something wrong with color of Audacity's UI since >> >> forever. It simply uses wrong color from GTK+ theme. I wonder if I'm >> >> the only one who thinks it's a disgrace. >> > >> > I agree, now that I know about it. Can you tell me what color to use? I >> > think we're getting all those from wxSystemSettings::GetColour() so it >> > might be a bug in wxWidgets on GTK+. >> >> I'm afraid I'm the wrong person to ask a technical question about that :) >> >> Attached is a screenshot of Audacity before you guys "fixed" the >> slider's background. This is default GTK+ theme on Ubuntu 10.04. As >> you can easily see, the "wrong" color of sliders was actually the >> right one, contrary to most of UI. > > Which revision did you take? Al committed improved my patch in r10744. Like I said it was before the patch went it. That very screenshot was made from rev10520 or so. A checkout from around July, in other words. With current revision everything is brownish (except status bar). Alexandre Prokoudine http://libregraphicsworld.org |
|
From: Gale Andrews <gale@au...> - 2010-10-06 12:45:42
|
| From Richard Ash <richard@...> | Tue, 05 Oct 2010 22:17:50 +0100 | Subject: [Audacity-devel] audacity trunk fails to build on Ubuntu > On Tue, 2010-10-05 at 12:55 +0200, Benjamin Drung wrote: > > audacity trunks fails to build on Ubuntu. The last known building > > revision was 10703 and the first known failing one was 10714. > > > > The ending of the build failure (but probably not the cause): > > Definitely not the cause. What goes wrong is that the portaudio-v19 > build fails with a libtool-related build error just before 50% down the > log file. > > I don't know yet what causes this - my amd64 build works fine ... What > libtool version does your build host have? > > Richard I have the same problem (default ./configure) on Ubuntu 10.04 (AMD Duron i386) - syntax error in VERSION script after similar looking eval: 1: args+=: not found lines. Libtool is 2.2.6b-2ubuntu1. I made a make.log (but not a configure log) before reading this, but in case it shows anything different in the detail: http://www.gaclrecords.org.uk/make.log Gale |
|
From: Steve the Fiddle <stevethefiddle@gm...> - 2010-10-06 22:57:57
|
Same problem on Ubuntu 9.04, libtool 2.2.6a, libtool: link: echo "local: *; };" >> lib/.libs/libportaudio.ver libtool: link: gcc -shared -Wl,-rpath -Wl,/usr//lib -Wl,-rpath -Wl,/usr//lib /usr/lib/libasound.so -L/usr//lib /usr//lib/libjack.so -L/usr/lib -ldl /usr/lib/libsamplerate.so -lrt -lm -lpthread -Wl,-soname -Wl,libportaudio.so.2 -Wl,-version-script -Wl,lib/.libs/libportaudio.ver -o lib/.libs/libportaudio.so.2.0.0 /usr/bin/ld:lib/.libs/libportaudio.ver:2: syntax error in VERSION script collect2: ld returned 1 exit status make[2]: *** [lib/libportaudio.la] Error 1 make[2]: Leaving directory `/home/steve/audacity-copy/lib-src/portaudio-v19' make[1]: *** [portaudio-v19-recursive] Error 2 make[1]: Leaving directory `/home/steve/audacity-copy/lib-src' make: *** [audacity] Error 2 Steve On Wed, Oct 6, 2010 at 1:45 PM, Gale Andrews <gale@...> wrote: > > | From Richard Ash <richard@...> > | Tue, 05 Oct 2010 22:17:50 +0100 > | Subject: [Audacity-devel] audacity trunk fails to build on Ubuntu >> On Tue, 2010-10-05 at 12:55 +0200, Benjamin Drung wrote: >> > audacity trunks fails to build on Ubuntu. The last known building >> > revision was 10703 and the first known failing one was 10714. >> > >> > The ending of the build failure (but probably not the cause): >> >> Definitely not the cause. What goes wrong is that the portaudio-v19 >> build fails with a libtool-related build error just before 50% down the >> log file. >> >> I don't know yet what causes this - my amd64 build works fine ... What >> libtool version does your build host have? >> >> Richard > > I have the same problem (default ./configure) on Ubuntu 10.04 > (AMD Duron i386) - syntax error in VERSION script after similar > looking eval: 1: args+=: not found lines. Libtool is 2.2.6b-2ubuntu1. > > I made a make.log (but not a configure log) before reading this, but > in case it shows anything different in the detail: > http://www.gaclrecords.org.uk/make.log > > > > > > Gale > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |