irmp3 fails in configure

Warren Wilder wipwap19 at
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;
>- aclocal.
>/usr/share/aclocal/gtk.m4:7: warning: underquoted definition of AM_PATH_GTK
>  run info '(automake)Extending aclocal'
>  or see
>/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 cp
>>>configure.scan aclocal       ( recreates
>>>aclocal.m4, about twenty warnings about underquoted definitions
>>>) autoconf   ( reads and creates configure without
>>>any warnings) ./configure make         ( ends with a
>>>'Makefile:154: *** missing separator. Stop.'.) vi  154 Makefile
>>>=> @SET_MAKE@
>>>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, so I guess these messages
>>>are fatal.
>>>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
>>>this? :-)
>>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 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,
>>>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!

More information about the hlfs-dev mailing list