autogen-users — For software developers that use AutoGen in their projects

Re: [Autogen-users] 'make dist' failure?

[Dave H. <ha...@nt...>]

On Tue, Jan 24, 2012 at 20:43, Nikos Mavrogiannopoulos <nm...@gn...> wrote:
> On 01/24/2012 04:47 PM, Bruce Korb wrote:
>
>> Hi Simon,
>>
>> I won't be able to peek at this for a couple of days, but it *sounds* like
>> "libopts" may be missing in the SUBDIRS entry for the src/Makefile.am file.
>> I believe the NTP folks (Harlan) have done something like this.
>> http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ntp-dev-4.2.7p251.tar.gz
>> The sources are under Bit Keeper, so other than logging into ntp.org,
>> I don't know how to get them.
>> So if you haven't figured it out in a couple of days, I will then have time
>> to take a peek.
>
>
> Hi,
>  I checked the libopts.m4 and it seems to create the libopts/Makefile in
> a conditional. If I remove the AC_CONFIG_FILES outside it seems to work.

You might find that causes your bundled libopts to be built even when
the installed libopts is found acceptable.  Here's what NTP does (in
sntp/Makefile.am, as our libopts is in sntp/libopts):

if NEED_LIBOPTS
SUBDIRS += libopts
endif

DIST_SUBDIRS += libopts

So if configure determines the already-installed libopts is
acceptable, make never descends into sntp/libopts, but the libopts
directory is still distributed thanks to DIST_SUBDIRS unconditionally
including libopts.

Cheers,
Dave Hart

Re: [Autogen-users] 'make dist' failure?

[Dave H. <ha...@nt...>]

On Tue, Jan 24, 2012 at 20:43, Nikos Mavrogiannopoulos <nm...@gn...> wrote:
> On 01/24/2012 04:47 PM, Bruce Korb wrote:
>
>> Hi Simon,
>>
>> I won't be able to peek at this for a couple of days, but it *sounds* like
>> "libopts" may be missing in the SUBDIRS entry for the src/Makefile.am file.
>> I believe the NTP folks (Harlan) have done something like this.
>> http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ntp-dev-4.2.7p251.tar.gz
>> The sources are under Bit Keeper, so other than logging into ntp.org,
>> I don't know how to get them.
>> So if you haven't figured it out in a couple of days, I will then have time
>> to take a peek.
>
>
> Hi,
>  I checked the libopts.m4 and it seems to create the libopts/Makefile in
> a conditional. If I remove the AC_CONFIG_FILES outside it seems to work.

You might find that causes your bundled libopts to be built even when
the installed libopts is found acceptable.  Here's what NTP does (in
sntp/Makefile.am, as our libopts is in sntp/libopts):

if NEED_LIBOPTS
SUBDIRS += libopts
endif

DIST_SUBDIRS += libopts

So if configure determines the already-installed libopts is
acceptable, make never descends into sntp/libopts, but the libopts
directory is still distributed thanks to DIST_SUBDIRS unconditionally
including libopts.

Cheers,
Dave Hart

Re: [Autogen-users] 'make dist' failure?

[Nikos M. <nm...@gn...>]

On 01/24/2012 10:43 PM, Bruce Korb wrote:


> The intention was to make it conditional on whether or not it was
> found on the build system.  If it is there, use it and skip building
> the one glued in. If you always want it built, then you can also
> arrange to always have the condition be true.


Hi,
 As I understand Simon was referring to the 'make dist' time where each
directory in the source, being built or not, is traversed and the
Makefile is used to pack it. Since libopt doesn't have one (because
autogen is included in the development system) 'make dist' fails. Thus a
makefile in libopts/ might be needed even if it is not built. Disabling
its build on the other hand can be simply done by conditionally
including it in the SUBDIRS (as it is done now).

regards,
Nikos

Re: [Autogen-users] 'make dist' failure?

[Bruce K. <bru...@gm...>]

Hi Simon,

>> ... it *sounds* like "libopts" may be missing in the SUBDIRS entry for
>> the src/Makefile.am file.

> It is included in the top-level Makefile.am as per the libopts README.
> I think it would make more sense to have it in src/Makefile.am though,

The README also puts the libopts directory at the top level, parallel to "src".
I suppose it doesn't really matter, but consistency is nice.

> but that is not what the documentation says.  I think Nikos may have
> solved it though, although I don't understand the AM_COND_IF stuff -- it
> seems the intention was to really have a AC_CONFIG_FILES in a condition?

The intention was to make it conditional on whether or not it was found
on the build system.  If it is there, use it and skip building the one glued in.
If you always want it built, then you can also arrange to always have
the condition be true.

> That seems wrong, it seems it should always be present.

Cheers - Bruce

Re: [Autogen-users] 'make dist' failure?

[Simon J. <si...@jo...>]

Bruce Korb <bru...@gm...> writes:

> Hi Simon,
>
> I won't be able to peek at this for a couple of days, but it *sounds* like
> "libopts" may be missing in the SUBDIRS entry for the src/Makefile.am
> file.

Hi Bruce,

It is included in the top-level Makefile.am as per the libopts README.
I think it would make more sense to have it in src/Makefile.am though,
but that is not what the documentation says.  I think Nikos may have
solved it though, although I don't understand the AM_COND_IF stuff -- it
seems the intention was to really have a AC_CONFIG_FILES in a condition?
That seems wrong, it seems it should always be present.

/Simon

Re: [Autogen-users] 'make dist' failure?

[Nikos M. <nm...@gn...>]

On 01/24/2012 04:47 PM, Bruce Korb wrote:

> Hi Simon,
> 
> I won't be able to peek at this for a couple of days, but it *sounds* like
> "libopts" may be missing in the SUBDIRS entry for the src/Makefile.am file.
> I believe the NTP folks (Harlan) have done something like this.
> http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ntp-dev-4.2.7p251.tar.gz
> The sources are under Bit Keeper, so other than logging into ntp.org,
> I don't know how to get them.
> So if you haven't figured it out in a couple of days, I will then have time
> to take a peek.


Hi,
 I checked the libopts.m4 and it seems to create the libopts/Makefile in
a conditional. If I remove the AC_CONFIG_FILES outside it seems to work.

regards,
Nikos

Re: [Autogen-users] 'make dist' failure?

[Bruce K. <bru...@gm...>]

Hi Simon,

I won't be able to peek at this for a couple of days, but it *sounds* like
"libopts" may be missing in the SUBDIRS entry for the src/Makefile.am file.
I believe the NTP folks (Harlan) have done something like this.
http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ntp-dev-4.2.7p251.tar.gz
The sources are under Bit Keeper, so other than logging into ntp.org,
I don't know how to get them.

So if you haven't figured it out in a couple of days, I will then have time
to take a peek.

Regards, Bruce

On Tue, Jan 24, 2012 at 6:52 AM, Simon Josefsson <si...@jo...> wrote:
> Hello,
>
> Thanks to Nikos, GnuTLS now uses AutoGen for command line handling in
> git master.  I'm trying to get 'make dist' to work.  It works fine if I
> use --enable-local-libopts to make sure the local libopts copy is built,
> but if I don't use that, 'make dist' fails like this:
>
> make[1]: Leaving directory `/home/jas/src/gnutls/po'
>  (cd src/libopts && make  top_distdir=../../gnutls-3.0.12 distdir=../../gnutls-3.0.12/src/libopts \
>     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
> make[1]: Entering directory `/home/jas/src/gnutls/src/libopts'
> make[1]: *** No rule to make target `distdir'.  Stop.
>
> Indeed there is no src/libopts/Makefile:
>
> jas@latte:~/src/gnutls master$ ls -la src/libopts/Makefile*
> -rw-r--r-- 1 jas jas  1490 23 jan 21.26 src/libopts/Makefile.am
> -rw-r--r-- 1 jas jas 61695 24 jan 15.16 src/libopts/Makefile.in
> jas@latte:~/src/gnutls master$
>
> I see there is a call to AC_CONFIG_FILES in LIBOPTS_CHECK for the
> src/libopts/Makefile, however it doesn't seem to work?  Config.log does
> not contain any 'creating src/libopts/Makefile' statement and the file
> is not generated.
>
> If I add src/libopts/Makefile manually to AC_CONFIG_FILES, I get an
> error from autoconf:
>
> configure.ac:433: error: `src/libopts/Makefile' is already registered with AC_CONFIG_FILES.
>
> Any ideas?  You may browse the git repo here:
>
> http://git.savannah.gnu.org/cgit/gnutls.git/tree/
>
> /Simon

[Autogen-users] 'make dist' failure?

[Simon J. <si...@jo...>]

Hello,

Thanks to Nikos, GnuTLS now uses AutoGen for command line handling in
git master.  I'm trying to get 'make dist' to work.  It works fine if I
use --enable-local-libopts to make sure the local libopts copy is built,
but if I don't use that, 'make dist' fails like this:

make[1]: Leaving directory `/home/jas/src/gnutls/po'
 (cd src/libopts && make  top_distdir=../../gnutls-3.0.12 distdir=../../gnutls-3.0.12/src/libopts \
     am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
make[1]: Entering directory `/home/jas/src/gnutls/src/libopts'
make[1]: *** No rule to make target `distdir'.  Stop.

Indeed there is no src/libopts/Makefile:

jas@latte:~/src/gnutls master$ ls -la src/libopts/Makefile*
-rw-r--r-- 1 jas jas  1490 23 jan 21.26 src/libopts/Makefile.am
-rw-r--r-- 1 jas jas 61695 24 jan 15.16 src/libopts/Makefile.in
jas@latte:~/src/gnutls master$ 

I see there is a call to AC_CONFIG_FILES in LIBOPTS_CHECK for the
src/libopts/Makefile, however it doesn't seem to work?  Config.log does
not contain any 'creating src/libopts/Makefile' statement and the file
is not generated.

If I add src/libopts/Makefile manually to AC_CONFIG_FILES, I get an
error from autoconf:

configure.ac:433: error: `src/libopts/Makefile' is already registered with AC_CONFIG_FILES.

Any ideas?  You may browse the git repo here:

http://git.savannah.gnu.org/cgit/gnutls.git/tree/

/Simon

[Autogen-users] Autogen 5.13 autoopts still broken for me

[Leo D. <ld...@sp...>]

Hello,

I downloaded and built the RPM from source at 
<ftp://ftp.gnu.org/gnu/autogen/rel5.13/>.
All the 'make check' tests passed and it built me an RPM which I then 
installed on my openSUSE 12.1 x86_64 box.

I then attempted to run the new AutoOpts on the attached test-opt.def:

 > autogen --version
autogen (GNU AutoGen) 5.13
 > autoopts-config --version
  36:0:11
 > autogen test-opt.def
which: no CLexe in 
(...:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games)
/bin/sh: line 143: -v: command not found
which: no in in 
(...:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games)
/bin/sh: line 143: -v: command not found
which: no CLexe in 
(...:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games)
/bin/sh: line 143: -v: command not found
which: no in in 
(...:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games)
/bin/sh: line 143: -v: command not found
In file included from test.h:32:0,
                  from test.c:33:
/usr/src/packages/BUILD/autogen-5.13/autoopts/autoopts/options.h:354:5: 
error: unknown type name 'uintptr_t'
/usr/src/packages/BUILD/autogen-5.13/autoopts/autoopts/options.h:355:5: 
error: unknown type name 'uintptr_t'
/usr/src/packages/BUILD/autogen-5.13/autoopts/autoopts/options.h:1022:1: 
error: unknown type name 'uintptr_t'
Killing AutoGen 24345:  cannot compile
AutoGen aborting on signal 2 (Interrupt) in state EMITTING
processing template /usr/share/autogen/usage.tlib
             on line 182
        for function EXPR (12)
Aborted

Hmmm.... I did get test-opt.c and test-opt.h files, but test-opt.c looks 
truncated.
even:

 > CC='gcc' CFLAGS='-std=gnu9x' autogen test-opt.def

aborts in the manner described above.

I then tried:

 > autogen -T getopt.tpl test-opt.def
which: no CLexe in 
(...:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games)
/bin/sh: line 143: -v: command not found
which: no in in 
(...:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games)
/bin/sh: line 143: -v: command not found

The getopt-test.[ch] files generated look otherwise OK.

Leo

Re: [Autogen-users] GNU AutoGen Version 5.13/AutoOpts Version 36.0

[Richard S. <rm...@gn...>]

Congratulations on the new release.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: [Autogen-users] autogen 'make check' failure

[Bruce K. <bru...@gm...>]

On Mon, Nov 28, 2011 at 3:45 PM, Leo Davis <ld...@sp...> wrote:
> Bruce,
>
> I pulled down the latest string.test from gitweb and made a patch for
> autogen-5.12. For some reason the patch below wouldn't apply. The 'make
> check' pass when building with your RPM .spec file for autogen-5.12
> passed without a problem.
>
> Did the Guile team really decide to break backward compatibility (wrt
> removing the high order bit of characters) like that or is it just a bug
> with Guile 2.0.2?

They claim it was a bug that they originally allowed it.

I saw "string" as an array of non-NUL bytes, just like C and sure
enough it worked that way.
They knew I was using it that way from the code fragments that I sent
from time to time
over the last decade, but it didn't connect that I was using their
string stuff in ways that
didn't fit their (undocumented) model about how they thought it was used.
So, they claim I was using a bug and I claim they changed the interface.
It depends upon perspective.  In any event, it is now broken and I am
required to
implement my own array-of-bytes code.  Not today or any time soon.  :(

I'll try to make the official release in the next couple of days.  Thank you!!

Re: [Autogen-users] autogen 'make check' failure

[Leo D. <ld...@sp...>]

Bruce,

I pulled down the latest string.test from gitweb and made a patch for 
autogen-5.12. For some reason the patch below wouldn't apply. The 'make 
check' pass when building with your RPM .spec file for autogen-5.12 
passed without a problem.

Did the Guile team really decide to break backward compatibility (wrt 
removing the high order bit of characters) like that or is it just a bug 
with Guile 2.0.2?

Leo

On 11/24/2011 10:18 AM, Bruce Korb wrote:
> Hi Leo,
>
> Thank you for the report.  I do my development on openSuSE 11.4, not having
> upgraded yet.  I'll upgrade in a week or two.  Meanwhile,
>
> On Wed, Nov 23, 2011 at 2:08 PM, Leo Davis<ld...@sp...>  wrote:
>> Hello,
>>
>> I'm getting a failure on string.test with autogen-5.13.0pre4, autogen-5.12,
>> and autogen-5.11.9 on openSUSE 12.1 x86_64.  I'm using the source RPM files
>> to build the released versions, BTW.  I've attached the entire contents of
>> the FAILURES directory for autogen-5.13.0pre4.
> I dug into this.  It seems your version of Guile presumes that it is okay to
> silently remove the high-order bit from a string of characters because
> everybody knows that valid characters are in the range of 0x0a through 0x7E.
> Guile is being "helpful".  When I started there was no notion of an
> array of bytes,
> now I must change all my string references to the array-of-bytes interfaces.
>
> *sigh*.
>
> Please apply the following patch to the agen5/test/string.test script.
> If this also fails, then replace the "177" with "176" (the '~' character).
> That *must* work.
>
> Your result means that it is no longer possible to reliably generate arbitrary
> arrays of bytes with autogen.  Not until I figure out how to use the Guile
> array-of-bytes stuff anyway....
>
> Regards, Bruce
>
>
>
> diff --git a/agen5/test/string.test b/agen5/test/string.test
> index 0439e6c..438dbd3 100755
> --- a/agen5/test/string.test
> +++ b/agen5/test/string.test
> @@ -82,7 +82,8 @@ CASE (suffix)  =][=
>   =]
>   _EOF_
>
> -test -z "$LINENO"&&  LINENO=85
> +test -z "$LINENO"&&  LINENO=`
> +    grep -n FIND-THIS-LINE-NUMBER $0 | sed 's/:.*//'` # close enough
>   printf '\nchar zTestFile[] = "%s";\n#line %s\n' \
>       ${testname}.raw `expr $LINENO + 4`>&4
>
> @@ -94,13 +95,14 @@ char zExpect[] = "'\f\r\b\v\t\a\n\n"
>          "\"Wow!\"  This'll be \\hard\\'\n"
>          "#endif /* .\n"
>          "and it'll be a \"hassle\"."
> -       "\001\002\003\377\n'";
> +       "\001\002\003\177\n'";
>   #define expectSize ((int)(sizeof(zExpect) - 1))
>   int checkStr( char* pz, char const* pzWhat );
>   int checkStr( char* pz, char const* pzWhat )
>   {
>       static char const zNotMatch[] =
>           "%s generated string mismatches at offset %d of %d\n"
> +        "Expected char: 0x%02X  saw char: 0x%02X\n"
>           "Expected string:\n==>%s<==\n\n"
>           "Generated string:\n-->%s<--\n\n";
>
> @@ -116,8 +118,8 @@ int checkStr( char* pz, char const* pzWhat )
>
>       for (ix = 0; ix<  expectSize; ix++) {
>           if (*(pzE++) != *(pzR++)) {
> -            fprintf( stderr, zNotMatch, pzWhat, ix, expectSize,
> -                     zExpect, pz );
> +            fprintf(stderr, zNotMatch, pzWhat, ix, expectSize,
> +                    (unsigned char)pzE[-1], (unsigned char)pzR[-1],
> zExpect, pz);
>               return 1;
>           }
>       }
> @@ -217,7 +219,7 @@ string =
>   \#endif /* .
>   '
>       "and it'll be a \"hassle\"."
> -    "\001\x02\X03\377\n'";
> +    "\001\x02\X03\177\n'";
>
>   _EOF_

Re: [Autogen-users] autogen 'make check' failure

[Leo D. <ld...@sp...>]

Bruce,

Thanks for the patch. I'm away from my openSUSE 12.1 box at until Monday. 

The upgrade to openSUSE 12.1 is what prompted this bug report. The autogen autoopts that ships with openSUSE (5.11.8 IIRC) is broken:

https://bugzilla.novell.com/show_bug.cgi?id=731523

I tried patching that version of autogen to install 'usage.tlib', but ran into another 'make check' failure. So I decided to punt and try a more updated autogen.

Thanks again for the patch.

Leo

On Nov 24, 2011, at 10:26 AM, "Bruce Korb" <bru...@gm...> wrote:

> Hi Leo,
> 
> Thank you for the report.  I do my development on openSuSE 11.4, not having
> upgraded yet.  I'll upgrade in a week or two.  Meanwhile,
> 
> On Wed, Nov 23, 2011 at 2:08 PM, Leo Davis <ld...@sp...> wrote:
>> Hello,
>> 
>> I'm getting a failure on string.test with autogen-5.13.0pre4, autogen-5.12,
>> and autogen-5.11.9 on openSUSE 12.1 x86_64.  I'm using the source RPM files
>> to build the released versions, BTW.  I've attached the entire contents of
>> the FAILURES directory for autogen-5.13.0pre4.
> 
> I dug into this.  It seems your version of Guile presumes that it is okay to
> silently remove the high-order bit from a string of characters because
> everybody knows that valid characters are in the range of 0x0a through 0x7E.
> Guile is being "helpful".  When I started there was no notion of an
> array of bytes,
> now I must change all my string references to the array-of-bytes interfaces.
> 
> *sigh*.
> 
> Please apply the following patch to the agen5/test/string.test script.
> If this also fails, then replace the "177" with "176" (the '~' character).
> That *must* work.
> 
> Your result means that it is no longer possible to reliably generate arbitrary
> arrays of bytes with autogen.  Not until I figure out how to use the Guile
> array-of-bytes stuff anyway....
> 
> Regards, Bruce
> 
> 
> 
> diff --git a/agen5/test/string.test b/agen5/test/string.test
> index 0439e6c..438dbd3 100755
> --- a/agen5/test/string.test
> +++ b/agen5/test/string.test
> @@ -82,7 +82,8 @@ CASE (suffix)  =][=
> =]
> _EOF_
> 
> -test -z "$LINENO" && LINENO=85
> +test -z "$LINENO" && LINENO=`
> +    grep -n FIND-THIS-LINE-NUMBER $0 | sed 's/:.*//'` # close enough
> printf '\nchar zTestFile[] = "%s";\n#line %s\n' \
>    ${testname}.raw `expr $LINENO + 4` >&4
> 
> @@ -94,13 +95,14 @@ char zExpect[] = "'\f\r\b\v\t\a\n\n"
>       "\"Wow!\"  This'll be \\hard\\'\n"
>       "#endif /* .\n"
>       "and it'll be a \"hassle\"."
> -       "\001\002\003\377\n'";
> +       "\001\002\003\177\n'";
> #define expectSize ((int)(sizeof(zExpect) - 1))
> int checkStr( char* pz, char const* pzWhat );
> int checkStr( char* pz, char const* pzWhat )
> {
>    static char const zNotMatch[] =
>        "%s generated string mismatches at offset %d of %d\n"
> +        "Expected char: 0x%02X  saw char: 0x%02X\n"
>        "Expected string:\n==>%s<==\n\n"
>        "Generated string:\n-->%s<--\n\n";
> 
> @@ -116,8 +118,8 @@ int checkStr( char* pz, char const* pzWhat )
> 
>    for (ix = 0; ix < expectSize; ix++) {
>        if (*(pzE++) != *(pzR++)) {
> -            fprintf( stderr, zNotMatch, pzWhat, ix, expectSize,
> -                     zExpect, pz );
> +            fprintf(stderr, zNotMatch, pzWhat, ix, expectSize,
> +                    (unsigned char)pzE[-1], (unsigned char)pzR[-1],
> zExpect, pz);
>            return 1;
>        }
>    }
> @@ -217,7 +219,7 @@ string =
> \#endif /* .
> '
>    "and it'll be a \"hassle\"."
> -    "\001\x02\X03\377\n'";
> +    "\001\x02\X03\177\n'";
> 
> _EOF_

Re: [Autogen-users] autogen 'make check' failure

[Bruce K. <bru...@gm...>]

Hi Leo,

Thank you for the report.  I do my development on openSuSE 11.4, not having
upgraded yet.  I'll upgrade in a week or two.  Meanwhile,

On Wed, Nov 23, 2011 at 2:08 PM, Leo Davis <ld...@sp...> wrote:
> Hello,
>
> I'm getting a failure on string.test with autogen-5.13.0pre4, autogen-5.12,
> and autogen-5.11.9 on openSUSE 12.1 x86_64.  I'm using the source RPM files
> to build the released versions, BTW.  I've attached the entire contents of
> the FAILURES directory for autogen-5.13.0pre4.

I dug into this.  It seems your version of Guile presumes that it is okay to
silently remove the high-order bit from a string of characters because
everybody knows that valid characters are in the range of 0x0a through 0x7E.
Guile is being "helpful".  When I started there was no notion of an
array of bytes,
now I must change all my string references to the array-of-bytes interfaces.

*sigh*.

Please apply the following patch to the agen5/test/string.test script.
If this also fails, then replace the "177" with "176" (the '~' character).
That *must* work.

Your result means that it is no longer possible to reliably generate arbitrary
arrays of bytes with autogen.  Not until I figure out how to use the Guile
array-of-bytes stuff anyway....

Regards, Bruce



diff --git a/agen5/test/string.test b/agen5/test/string.test
index 0439e6c..438dbd3 100755
--- a/agen5/test/string.test
+++ b/agen5/test/string.test
@@ -82,7 +82,8 @@ CASE (suffix)  =][=
 =]
 _EOF_

-test -z "$LINENO" && LINENO=85
+test -z "$LINENO" && LINENO=`
+    grep -n FIND-THIS-LINE-NUMBER $0 | sed 's/:.*//'` # close enough
 printf '\nchar zTestFile[] = "%s";\n#line %s\n' \
     ${testname}.raw `expr $LINENO + 4` >&4

@@ -94,13 +95,14 @@ char zExpect[] = "'\f\r\b\v\t\a\n\n"
        "\"Wow!\"  This'll be \\hard\\'\n"
        "#endif /* .\n"
        "and it'll be a \"hassle\"."
-       "\001\002\003\377\n'";
+       "\001\002\003\177\n'";
 #define expectSize ((int)(sizeof(zExpect) - 1))
 int checkStr( char* pz, char const* pzWhat );
 int checkStr( char* pz, char const* pzWhat )
 {
     static char const zNotMatch[] =
         "%s generated string mismatches at offset %d of %d\n"
+        "Expected char: 0x%02X  saw char: 0x%02X\n"
         "Expected string:\n==>%s<==\n\n"
         "Generated string:\n-->%s<--\n\n";

@@ -116,8 +118,8 @@ int checkStr( char* pz, char const* pzWhat )

     for (ix = 0; ix < expectSize; ix++) {
         if (*(pzE++) != *(pzR++)) {
-            fprintf( stderr, zNotMatch, pzWhat, ix, expectSize,
-                     zExpect, pz );
+            fprintf(stderr, zNotMatch, pzWhat, ix, expectSize,
+                    (unsigned char)pzE[-1], (unsigned char)pzR[-1],
zExpect, pz);
             return 1;
         }
     }
@@ -217,7 +219,7 @@ string =
 \#endif /* .
 '
     "and it'll be a \"hassle\"."
-    "\001\x02\X03\377\n'";
+    "\001\x02\X03\177\n'";

 _EOF_

[Autogen-users] autogen 'make check' failure

[Leo D. <ld...@sp...>]

Hello,

I'm getting a failure on string.test with autogen-5.13.0pre4, 
autogen-5.12, and autogen-5.11.9 on openSUSE 12.1 x86_64.  I'm using the 
source RPM files to build the released versions, BTW.  I've attached the 
entire contents of the FAILURES directory for autogen-5.13.0pre4.

Thanks,

Leo

Re: [Autogen-users] 5.12 'make check' failure

[Bruce K. <bru...@gm...>]

I checked it out.  "fmt(1)" is buggy on bsd, or they are using a non-POSIX spec.
I am stripping out that reformatted text from the comparison for next release.
Until I put up another "pre", add the following line:

> sedcmd='/Note that.*is only useful/,/will be regenerated/d'

before the line that reads:

> compile "-?"

Given that I've run this many, many times on psp-fb1, I am surprised,
but oh, well.....

On Fri, Aug 19, 2011 at 5:34 PM, Harlan Stenn <st...@nt...> wrote:
> Bruce,
>
> I saw this on psp-fb2:
>
> ...
> creating shell.hlp
> FAILURE: script generator help output mismatch: *** shell.hlp   Sat Aug
> 20 00:22:21 2011
> --- shell.help  Sat Aug 20 00:22:21 2011
> ***************
> *** 13,24 ****
>  hyphen and the flag character.
>
>  Note that ``shell'' is only useful if the output file does not already
> ! exist.  If it does, then the shell name and optional first argument will
> ! be extracted from the script file.
>
>  If the script file already exists and contains Automated Option Processing
>  text, the second line of the file through the ending tag will be replaced
> ! by the newly generated text.  The first ``#!''  line will be regenerated.

[Autogen-users] 5.12 'make check' failure

[Harlan S. <st...@nt...>]

Bruce,

I saw this on psp-fb2:

...
creating shell.hlp
FAILURE: script generator help output mismatch: *** shell.hlp   Sat Aug
20 00:22:21 2011
--- shell.help  Sat Aug 20 00:22:21 2011
***************
*** 13,24 ****
  hyphen and the flag character.
  
  Note that ``shell'' is only useful if the output file does not already
! exist.  If it does, then the shell name and optional first argument will
! be extracted from the script file.
  
  If the script file already exists and contains Automated Option Processing
  text, the second line of the file through the ending tag will be replaced
! by the newly generated text.  The first ``#!''  line will be regenerated.
  
  = = = = = = = =
  
--- 13,24 ----
  hyphen and the flag character.
  
  Note that ``shell'' is only useful if the output file does not already
! exist.  If it does, then the shell name and optional first argument will be
! extracted from the script file.
  
  If the script file already exists and contains Automated Option Processing
  text, the second line of the file through the ending tag will be replaced
! by the newly generated text.  The first ``#!'' line will be regenerated.
  
  = = = = = = = =
  
FAIL: shell.test
PASS: stdopts.test
PASS: time.test
PASS: usage.test
PASS: vers.test
====================================================
1 of 22 tests failed
Please report to aut...@li...
====================================================

-- 
Harlan Stenn <st...@nt...>
http://ntpforum.isc.org  - be a member!

[Autogen-users] Install autogen

[김민준 <goo...@gm...>]

I can't install grub because of autogen is missing.
So I get autogen-5.11.8.tar.gz and do ./configure
But error is happened. The error is:

checking whether with-libguile was specified... no
checking whether with-libguile-cflags was specified... no
checking whether with-libguile-libs was specified... no
checking whether libguile can be linked with... no
configure: error: Cannot find libguile.  libguile is required.

Please help me.

Re: [Autogen-users] OS/X config error: autogen 5.11.9 - guile in nonstandard dir

[Harlan S. <st...@nt...>]

Bruce wrote:
> It seems I had considered a -I pointing at one tree and -L to another:
> Use --with-libguile-cflags=xxx --with-libguile-ldflags=yyy
> 
> But why would you do that?  --with-libguile is used to provide both
> with one option.

This is clearly more flexible (and clearly a PITA), and I had to do this
with openssl for NTP for some platforms where, for reason I no longer
remember, the "prefix" was *not* the same for lib and include.

These days I am happy to look for pkg-config files first, and if they
fail either recommend that somebody create the .pc file or fall back to
the old style (which is either --foo-lives-in=... or --foo-incs=... and
--foo-libs=...).

H

Re: [Autogen-users] OS/X config error: autogen 5.11.9 - guile in nonstandard dir

[Bruce K. <bk...@gn...>]

On 06/13/11 16:42, Bruce Korb wrote:
> ``-L/Users/grahamreitz/Development/root/usr/local'' or
> ``-L/Users/grahamreitz/Development/root/usr/local/lib'' ??
>
> The presumption for the past decade is that you pass the *prefix* of
> the installation so that the "include" and "lib" directories can *both*
> be derived from it. So, the name ought to have been --with-libguile-prefix.
> It isn't. Sorry. I'll try to clarify.

It seems I had considered a -I pointing at one tree and -L to another:
Use --with-libguile-cflags=xxx --with-libguile-ldflags=yyy

But why would you do that?  --with-libguile is used to provide both
with one option.

[Autogen-users] OS/X config error: autogen 5.11.9 - guile in nonstandard dir

[Bruce K. <bk...@gn...>]

On 06/12/11 10:15, Graham Reitz wrote:
> I'm confused why the configure --with-libguile=[DIR] switch isn't working.
> The same configure error occurs with autogen 5.11.8

The macros haven't changed.

> $ /Users/grahamreitz/Development/source-dir/gnu/autogen/autogen-5.11.9/configure \
>   --prefix=/Users/grahamreitz/Development/root/usr/local CFLAGS=-O3 -pedantic \
>   -mtune=native CXXFLAGS=-O3 -pedantic -mtune=native \
>   --with-libguile=/Users/grahamreitz/Development/root/usr/local

> configure:14049: gcc -std=gnu99 -o conftest -O3 -pedantic -mtune=native \
>   -I/Users/grahamreitz/Development/root/usr/local/include  conftest.c \
>   -ldl  -L/Users/grahamreitz/Development/root/usr/local/lib -lguile >&5
> conftest.c:125:22: error: libguile.h: No such file or directory
> conftest.c: In function 'main':
> conftest.c:130: error: 'SCM' undeclared (first use in this function)

``-L/Users/grahamreitz/Development/root/usr/local'' or
``-L/Users/grahamreitz/Development/root/usr/local/lib'' ??

The presumption for the past decade is that you pass the *prefix* of
the installation so that the "include" and "lib" directories can *both*
be derived from it.  So, the name ought to have been --with-libguile-prefix.
It isn't.  Sorry.  I'll try to clarify.

Re: [Autogen-users] FW: problem with auto-opts definition element . . .

[Geof S. <Geo...@ut...>]

Bruce, thank you so much!

________________________________________
From: Bruce Korb [bru...@gm...]
Sent: Thursday, March 24, 2011 11:57 PM
To: Geof Sawaya
Cc: dav...@da...; aut...@li...
Subject: Re: [Autogen-users] FW: problem with auto-opts definition element . . .

On Thu, Mar 24, 2011 at 10:30 PM, Geof Sawaya <Geo...@ut...> wrote:
> Bruce, thanks for your response.
>
>>The stuff is *SUPPOSED* to be linked with -Wl,-R/usr/local/lib and that is
>>*SUPPOSED* to force ldd to show /usr/local/lib/libopts.so.33 ahead of
>>anything else in the /etc/ld.so.conf file.  It has never been effective enough
>
> Bruce, I'm not seeing libopts.so.33 anywhere -- just 25.

Transcription problem.  Dunno where I got "33" :)

> Also, in my 'make' output, there isn't any '-Wl,-R/usr/local/lib' . . .
>
> (this is autogen 5.11.6)

Now I remember:  It is what *I* think libtool should do, but there must be
problems because libtoolers don't want to:
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag <<<<=====
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
so the /etc/ld.so.conf fiddling is required.  (Don't forget to run ldconfig.)

Re: [Autogen-users] FW: problem with auto-opts definition element . . .

[Bruce K. <bru...@gm...>]

On Thu, Mar 24, 2011 at 10:30 PM, Geof Sawaya <Geo...@ut...> wrote:
> Bruce, thanks for your response.
>
>>The stuff is *SUPPOSED* to be linked with -Wl,-R/usr/local/lib and that is
>>*SUPPOSED* to force ldd to show /usr/local/lib/libopts.so.33 ahead of
>>anything else in the /etc/ld.so.conf file.  It has never been effective enough
>
> Bruce, I'm not seeing libopts.so.33 anywhere -- just 25.

Transcription problem.  Dunno where I got "33" :)

> Also, in my 'make' output, there isn't any '-Wl,-R/usr/local/lib' . . .
>
> (this is autogen 5.11.6)

Now I remember:  It is what *I* think libtool should do, but there must be
problems because libtoolers don't want to:
----------------------------------------------------------------------
Libraries have been installed in:
   /usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,-rpath -Wl,LIBDIR' linker flag <<<<=====
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
so the /etc/ld.so.conf fiddling is required.  (Don't forget to run ldconfig.)

Re: [Autogen-users] problem with auto-opts definition element . . .

[Bruce K. <bru...@gm...>]

On 03/24/11 18:12, Geof Sawaya wrote:
> Hi Bruce,
>
> I hope you've found a job.

Nope, still looking.  Thank you.

> Anyway, I have a problem with an auto-opts .def file.  I set a flag like this:
>
> flag = {
>      name = bound;
>      value = B;
>      descrip = "Enable bounded mixing";
>      //ifdef = CONFIG_BOUNDED_MIXING;
>      arg-type = number;
> };
>
> If I use the 'ifdef' clause of the flag definition I get the following problem when compiling:
>
> sched-opt.c:375: error: expected unqualified-id before ‘__null’
>
> The code that corresponds to that message is:
>
>
> #ifdef CONFIG_BOUNDED_MIXING
>    extern tOptProc optionNumericVal;
> #else /* not CONFIG_BOUNDED_MIXING */
> # define optionNumericVal NULL
> #endif /* def/not CONFIG_BOUNDED_MIXING */
> extern tOptProc
>      optionBooleanVal,   optionNumericVal,   optionPagedUsage,    *******LINE 375
>      optionPrintVersion;
>
> Is this a bug in auto-opts/autogen?

Yep.  As of December's release, I make sure I don't try to declare
optionNumericVal in the generated code.  It gets declared in
autoopts/options.h.  Oops.

Re: [Autogen-users] FW: problem with auto-opts definition element . . .

[Geof S. <Geo...@ut...>]

Bruce, thanks for your response.

>The stuff is *SUPPOSED* to be linked with -Wl,-R/usr/local/lib and that is
>*SUPPOSED* to force ldd to show /usr/local/lib/libopts.so.33 ahead of
>anything else in the /etc/ld.so.conf file.  It has never been effective enough

Bruce, I'm not seeing libopts.so.33 anywhere -- just 25.

Also, in my 'make' output, there isn't any '-Wl,-R/usr/local/lib' . . .  

(this is autogen 5.11.6)

Cheers,

Geof