irmp3 fails in configure
wipwap19 at hotmail.com
Wed Apr 5 09:18:57 PDT 2006
Yess!, I have finally found the culprit. Just letting you know, so
perhaps someone, someday, will be benefitted by this. <tongue in cheek>
The configure script first failed at line 7550. When I 'fixed' that, the
warnings went lower and lower, untill the script reached the end, after
which the warnings went back up into the script. The syntax error
warnings were just ridiculous.
I decided to run it at another system again, where it worked. I then
tried to find out whether the syntax errors were really only below the
mentioned line nr 7550, so I cut the script in two, based on the screen
output that I got on the HLFS system. (which was around line 7200 or so)
I ran the front part of the configure script, and that failed! On a new
linenr, namely 6861, where I found this line:
message=`eval echo It'll be very difficult to use mod_browser without
mod_lcdproc. It is strongly recommended that you enable mod_lcdproc.`
The ' in It'll was the reason the whole thing blew.
Well, I don't know about you, but I learned something new. :-)
Thanks for your attention.
Warren Wilder wrote:
>I have been hurting myself with this for a while now and I kind of need a
>helping hand to stop the bleeding.
>I want to install the old package irmp3 on my system. For some reason, when
>I run the configure script, bash complains about wrong syntax. (version
>0.5.7pre1 and 0.5.7.pre2 both fail)
>So I opted for the older 0.5.6 version, which already has a Makefile and
>can be built sucessfully. Unfortunately, the lirc module isn't added and
>mpg123 support doesn't work correctly. So I need one of the 5.7 versions.
>Better lirc detection and such, so I hear.
>Lately, I've been trying to correct the 'bad syntax' in the configure
>script of 5.7pre2, although I'm sure it isn't incorrect. I felt happy
>because the errors about wrong syntax were steadily progressing towards the
>end of the script. Unfortunately, when I reached the end, the linenumbers
>with syntax errors went back up. Changing the configure script is a no-go
>But I ran the reconf script after that and tried all over again. Silly me.
>So far, no irmp3.
>I don't know much/anything about the gnu autotools and how they make a
>package compile, but I'm sure there is something I can/should do with these
>tools to 'crack' the configure script into shape.
>Aclocal complains about these underquoted definitions;
>/usr/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
> run info '(automake)Extending aclocal'
> or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
>/usr/share/aclocal/glib.m4:8: warning: underquoted definition of
>/usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of
>Since the syntax errors in configure are all about quotes, I feel
>something's up with this.
>Perhaps having these directories is a bad thing?
>Declan Moriarty schreef:
>>Recently, Somebody Somewhere wrote these words
>>>>Recently, Somebody Somewhere wrote these words
>>>>>I am trying to install irmp3 on my HLFS system.
>>>>>The same source package installs fine on a Knoppix 3.8 system,
>>>>>but I can't get it past the configure step on the HLFS system.
>>>>>Syntax errors in the configure prevent it from completing, or so
>>>>>it says. Since it works on the Knoppix system and Google tells
>>>>Does Perl run on backticks? I certainly thought scripts didn't.
>>>>sed 's/`/'/g' -i configure ?? You can always untar it again :-).
>>>I tried that command but it needed something to escape the '
>>>character that needs to replace the ` ones. I read around a bit
>>>but couldn't find an example about this particular sed
>>>replacement. Adding the normal escapecharacter didn't help. So
>>>I started taking it from a different route, I tried to create a
>>>new configure script and read a bit about the GNU auto tools.
>>>(automake, autoconf, autoscan, aclocal, autoheader)
>>>This is what I did: untar the package (irmp3-0.5.7-pre1.tar.gz)
>>>cd irmp3 remove configure* autoscan ( creates configure.scan
>>>with a warning about a non-existent configure.ac) cp
>>>configure.scan configure.ac aclocal ( recreates
>>>aclocal.m4, about twenty warnings about underquoted definitions
>>>) autoconf ( reads configure.ac and creates configure without
>>>any warnings) ./configure make ( ends with a
>>>'Makefile:154: *** missing separator. Stop.'.) vi 154 Makefile
>>>It seems to be working out for the better, because running
>>>configure actually works, but that leaves me with a Makefile
>>>which make promptly refuses to run. I tried automake, but it
>>>shows a big bunch of errors:
>>>and it doesn't recreate Makefile.in, so I guess these messages
>>>Just for the record, I have no idea what I am doing here ( well,
>>>kind of :-) ) but I find it interesting none the less, so anyone
>>>willing to take the time to guide me along, please do. I'm sure
>>>the stuff I am learning here is going to come of use a lot more
>>>often, later in life.
>>>Right now, I have three questions: 1) Am I getting anywhere with
>>Not yet. You went up a cul-de-sac, imho. The surroundings are totally
>>familiar - scores of errors. You jumped the first hurdle, but landed on
>>your backside :-)
>>>2) how come ./configure can create a Makefile which is not
>>>acceptable by make?
>>Automake needs a reasonably tuned autogen.sh. Also, there is xmkmf
>>which throws together based on the config sorted by your X
>>install. That wants an Imakefile.
>>>3) do I even need automake in this case? I have a Makefile.in,
>>>but I'm sure it is way old/deprecated.
>>Untar afresh, and examine the line of the configure script that
>>failed. Take salient terms from that and grep other config scripts
>>for them. I tried that here. Here's the stuff from SDL-1.2.8
>>(built ok under hlfs here)
>>1361: case `(ac_space='"'"' '"'"'; set | grep ac_space) 2>&1` in
>>1362: *ac_space=\ *)
>>31583: case `(ac_space=' '; set | grep ac_space) 2>&1` in
>>31584: *ac_space=\ *)
>>That's awfully like your line, isn't it? Feel free to copy & paste
>>- it saves thinking :-D.
>>I would also try a plain 'make' if you have a Makefile in there.
>>Some busy/lazy maintainers hack the Makefile and go, neglecting to
>>check if the thing will reconfigure.
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
More information about the hlfs-dev