Thread: [Audacity-devel] Eee compilation
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Martyn S. <mar...@go...> - 2008-09-25 21:59:12
|
Hi there After updating to latest CVS I can not longer get Audacity to compile on my Asus Eee. I'm certainly a newby to *nix so it may be me but I did ./configure --enable-debug -q make and I get a heap of entering / leaving messages followed by make[2]: Entering directory `/home/user/audacity/lib-src/portsmf' make[2]: *** No rule to make target `autotools/m4/ax_cflags_strict_prototypes.m4', needed by `Makefile.in'. Stop. followed by it backing out of the directories and stopping. Any ideas? Martyn |
From: Richard A. <ri...@au...> - 2008-09-26 18:37:00
|
On Thu, 2008-09-25 at 23:17 +0100, Martyn Shaw wrote: > After updating to latest CVS I can not longer get Audacity to compile > on my Asus Eee. I'm certainly a newby to *nix so it may be me but I > did > ./configure --enable-debug -q > make > and I get a heap of entering / leaving messages followed by > make[2]: Entering directory `/home/user/audacity/lib-src/portsmf' > make[2]: *** No rule to make target > `autotools/m4/ax_cflags_strict_prototypes.m4', needed by > `Makefile.in'. Stop. > followed by it backing out of the directories and stopping. cvs up -P -d Without the extra options, new directories don't get added to the source tree, nor do the files within them. Hence you haven't got the files in portsmf/autotools/m4/ which you should have, and are committed to CVS. Once the files exist make will decide that in fact there is nothing to worry about, and carry on with the build process (the files are needed to re-create the configure script, so the Makefile has rules which rebuild the configure script from them if they change. Handy for development, but means you do have to distribute the files). This got me for a long time until someone explained it to me. Richard |
From: Martyn S. <mar...@go...> - 2008-09-27 21:05:20
|
Thanks Richard, that got me a lot further and I'll try and remember it in the future. I am now getting an error g++: @PA_LIBS@: No such file or directory make[1]: ***[../audacity] Error 1 make: ***[audacity] Error 2 is this related? Martyn Richard Ash wrote: > On Thu, 2008-09-25 at 23:17 +0100, Martyn Shaw wrote: >> After updating to latest CVS I can not longer get Audacity to compile >> on my Asus Eee. I'm certainly a newby to *nix so it may be me but I >> did >> ./configure --enable-debug -q >> make >> and I get a heap of entering / leaving messages followed by >> make[2]: Entering directory `/home/user/audacity/lib-src/portsmf' >> make[2]: *** No rule to make target >> `autotools/m4/ax_cflags_strict_prototypes.m4', needed by >> `Makefile.in'. Stop. >> followed by it backing out of the directories and stopping. > > cvs up -P -d > > Without the extra options, new directories don't get added to the source > tree, nor do the files within them. Hence you haven't got the files in > portsmf/autotools/m4/ which you should have, and are committed to CVS. > Once the files exist make will decide that in fact there is nothing to > worry about, and carry on with the build process (the files are needed > to re-create the configure script, so the Makefile has rules which > rebuild the configure script from them if they change. Handy for > development, but means you do have to distribute the files). > > This got me for a long time until someone explained it to me. > > Richard > > |
From: Richard A. <ri...@au...> - 2008-09-28 20:44:27
|
On Sat, 2008-09-27 at 22:06 +0100, Martyn Shaw wrote: > Thanks Richard, that got me a lot further and I'll try and remember it > in the future. > > I am now getting an error > g++: @PA_LIBS@: No such file or directory > make[1]: ***[../audacity] Error 1 > make: ***[audacity] Error 2 > > is this related? > Martyn I don't know - any chance of some more context (the previous few lines of output)? I think the problem is basically that the sequence @PA_LIBS@ should have been replaced with some other text string at an earlier stage in the configure run, but it hasn't happened, hence the error. I would tend to suggest re-running configure, or if that doesn't work (as I think you've already done) make clean; make. Richard |
From: Martyn S. <mar...@go...> - 2008-09-27 23:29:04
|
I tried make clean ./configure --enable-debug -q make ./au* (which took about 31 minutes) and got Segmentation fault which doesn't give me much of a clue! I don't how to continue from here. Ideas? Thanks Martyn Martyn Shaw wrote: > Thanks Richard, that got me a lot further and I'll try and remember it > in the future. > > I am now getting an error > g++: @PA_LIBS@: No such file or directory > make[1]: ***[../audacity] Error 1 > make: ***[audacity] Error 2 > > is this related? > Martyn > > Richard Ash wrote: >> On Thu, 2008-09-25 at 23:17 +0100, Martyn Shaw wrote: >>> After updating to latest CVS I can not longer get Audacity to compile >>> on my Asus Eee. I'm certainly a newby to *nix so it may be me but I >>> did >>> ./configure --enable-debug -q >>> make >>> and I get a heap of entering / leaving messages followed by >>> make[2]: Entering directory `/home/user/audacity/lib-src/portsmf' >>> make[2]: *** No rule to make target >>> `autotools/m4/ax_cflags_strict_prototypes.m4', needed by >>> `Makefile.in'. Stop. >>> followed by it backing out of the directories and stopping. >> >> cvs up -P -d >> >> Without the extra options, new directories don't get added to the source >> tree, nor do the files within them. Hence you haven't got the files in >> portsmf/autotools/m4/ which you should have, and are committed to CVS. >> Once the files exist make will decide that in fact there is nothing to >> worry about, and carry on with the build process (the files are needed >> to re-create the configure script, so the Makefile has rules which >> rebuild the configure script from them if they change. Handy for >> development, but means you do have to distribute the files). >> >> This got me for a long time until someone explained it to me. >> >> Richard >> >> > |
From: Richard A. <ri...@au...> - 2008-09-28 21:03:48
|
On Sun, 2008-09-28 at 00:30 +0100, Martyn Shaw wrote: > I tried > make clean > ./configure --enable-debug -q > make > ./au* > > (which took about 31 minutes) and got > Segmentation fault > > which doesn't give me much of a clue! I don't how to continue from > here. Ideas? You might want to drop the -q option to configure so you get some more descriptive output from configure (I've never actually used it). The segfault is the same thing as windows out of bounds memory access message - it means that the program has tried to access a part of the machine's address space which it doesn't have access to, and so the program has been terminated. So the response is much as it would be in any environment - run the program in a debugger, and find out where the program is when the offending access occurs, so you can poke around and try to see what went wrong. On Linux the core debugger is GDB: http://www.gnu.org/software/gdb/ For which there are many tutorials, my preferred one is http://www.dirac.org/linux/gdb/ Anyhow, basically, to start audacity in a debugging environment, run it as gdb ./audacity That will start up, load the debugging symbols which link the executable to the source code line numbers etc. You will then get the GDB command prompt. Audacity isn't yet running, but it has been loaded into memory. At the gdb prompt, type "run" and press enter. Audacity will now start to execute and run through it's startup code. At some point, it will reach the crash point, and you now get a message on the GDB console which tells you that your process received signal SIGSEGV, and the GDB prompt returns. Audacity is now in memory, stopped just before the instruction that caused the error. You have a number of options at this point, but the most useful is to get the call stack, i.e. list of where the program is in terms of line numbers in each function that is currently executing. To get this, type "bt" and press enter (you may get it in several screen fulls if the crash is in a very deep function call). This quite often gives you and idea where to look, but the other key thing is reading the values of variables. Basically, you do this by typing "print <variable-name>". The slight complication is that you can only access variables that are in scope for the function you are currently in. However you can jump to any other function in the backtrace by typing "frame n", where n is the number of the function in the backtrace output, which start from 1 at the point of the stoppage, and count up the further back (towards main()) you go. The tutorial expands on all this far better than I can do. Richard |
From: Martyn S. <mar...@go...> - 2008-09-28 23:44:28
|
Hi Richard Excellent! Thanks for that, a lot to digest but proving useful already, and excellent support for a win devel who is new to *nix - should be on the wiki! I'll try and get there and add your tips (but not from this mini-keyboard).. . This Eee had a trip to Leeds today, and proved it's worth in being so light I nearly forgot I'd got it, until it gave us games to play on the way back. And afterward it did not do the seg fault (although it's probably more likely that the reboot helped (doh!), but I was told that you 'never need to reboot under *nix??' ). Anyway, up and running again and I now feel like I can use some debugging tools on the Eee. We shall see how that goes! Thanks again Martyn 2008/9/28 Richard Ash <ri...@au...>: > On Sun, 2008-09-28 at 00:30 +0100, Martyn Shaw wrote: >> I tried >> make clean >> ./configure --enable-debug -q >> make >> ./au* >> >> (which took about 31 minutes) and got >> Segmentation fault >> >> which doesn't give me much of a clue! I don't how to continue from >> here. Ideas? > > You might want to drop the -q option to configure so you get some more > descriptive output from configure (I've never actually used it). > > The segfault is the same thing as windows out of bounds memory access > message - it means that the program has tried to access a part of the > machine's address space which it doesn't have access to, and so the > program has been terminated. > > So the response is much as it would be in any environment - run the > program in a debugger, and find out where the program is when the > offending access occurs, so you can poke around and try to see what went > wrong. > > On Linux the core debugger is GDB: > http://www.gnu.org/software/gdb/ > For which there are many tutorials, my preferred one is > http://www.dirac.org/linux/gdb/ > > Anyhow, basically, to start audacity in a debugging environment, run it > as > gdb ./audacity > > That will start up, load the debugging symbols which link the executable > to the source code line numbers etc. You will then get the GDB command > prompt. Audacity isn't yet running, but it has been loaded into memory. > At the gdb prompt, type "run" and press enter. Audacity will now start > to execute and run through it's startup code. > > At some point, it will reach the crash point, and you now get a message > on the GDB console which tells you that your process received signal > SIGSEGV, and the GDB prompt returns. > > Audacity is now in memory, stopped just before the instruction that > caused the error. You have a number of options at this point, but the > most useful is to get the call stack, i.e. list of where the program is > in terms of line numbers in each function that is currently executing. > To get this, type "bt" and press enter (you may get it in several screen > fulls if the crash is in a very deep function call). > > This quite often gives you and idea where to look, but the other key > thing is reading the values of variables. Basically, you do this by > typing "print <variable-name>". The slight complication is that you can > only access variables that are in scope for the function you are > currently in. However you can jump to any other function in the > backtrace by typing "frame n", where n is the number of the function in > the backtrace output, which start from 1 at the point of the stoppage, > and count up the further back (towards main()) you go. > > The tutorial expands on all this far better than I can do. > > Richard > > |