libgpg-error is bombing early in the compile step, apparently due to a malformed
awk script which is leaving mkerrcodes.h in a mess. Both Apple's awk and GNU
awk have been tried with equal results.
A log of the build, along with mkerrcodes.h, is attached.
This is a splitting failure. The awk script should split a string like "9
GPG_ERR_EBADF" between the number and the string. To proceed, I need to see the
file _mkerrcodes.h after it is processed by CPP:
$(AWK) -f $(srcdir)/mkerrcodes1.awk $(srcdir)/errnos.in > _mkerrcodes.h
$(CPP) _mkerrcodes.h > file-for-marcus
Please send me the output "file-for-marcus", or attach it to this bug report.
CPP should be the preprocessor of the host platform, ie the one you are
compiling for (this is only relevant if you are cross compiling).
I have also committed a README file in libgpg-error/src/ that explains the
mkerrcodes mess, in case you are interested to have a look yourself.
Thanks,
Marcus
Now this is getting interesting, and curious. I can not reproduce the problem
here, "grep GPG_ERR_ file-for-marcus | gawk -f mkerrcodes.awk" works fine and
produces a syntactically correct mkerrcodes.h
Can you try to run the same command on the command line to see if that works better?
Seriously, the awk script is quite innocent and simple, and there is no
indication that the failing lines in the output are any different in the input
than all the other lines. It's a puzzle to me. If this is consistently
reproducible, we are in for some fun debugging! Is there any chance I could get
remote access to such a box?
Unfortunately, the command-line version does the exact same thing. :(
Remote access to this box is possible, but perhaps a bit difficult. It's a
MacBook Pro laptop, which means I'd have to plug it into a static IP port and
leave it there while you do your work. I'm willing to do this, but I need to
know from you what time would work best. I can leave it up for a day or so, but
not much more than that--I have too much work to do. If this would be helpful,
please drop me an email and let's arrange things. (Key 0xFEAF8109; given we're
talking about remote access to my box, encrypted traffic would be much preferred.)
This bug is not reproducible on Mac/PowerPC. I'm going to talk to another
friend of mine with a MacBook and see if he can recreate it as well. If he can,
then that will be evidence this is a Mactel problem, not just a problem with my
specific OS X installation.