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

Re: [Autogen-users] 5.16.1 make check failure

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

Hi Dave,

You missed the point.  I do not want two functions:
  char const * fnc(char const * in)
as well as
  char * fnnc(char * in)
any more than libc wants two flavors of strstr(), for example.
So strstr() returns char * and it is up to the caller to be careful.
Perhaps the right thing is to pound the const-ness out of the
pointer inside the function instead of the wrapper, but that is
not the way I grew up all those years ago.

Instead, I'll cast it thus, beit in the function or macro:
   (char *)(uintptr_t)const_str_ptr

On Mon, Jun 18, 2012 at 11:39 AM, Dave Hart
<dav...@da...> wrote:
>  A void * cast would suffer the same warning.  If
> spn_ag_char_map_chars() accepts both const char * and char *
> arguments, the correct argument prototype is const char *.  It is safe
> to cast char * to const char *, but the reverse is not true

The returned result must be assignment compatible with the provided argument.
If the provided argument is not const, then the result is not const.

> I wish I understood why newer gcc isn't warning in the same situation
> -- but I believe it's wrong, as any stripping of const potentially
> violates the const contract (potentially because the consumers of
> de-consted pointers may not in fact write).

Then a convenient solution for the strstr class of functions needs to
be considered.
(Where the attribute of the result matches whatever was provided.)

Re: [Autogen-users] 5.16.1 make check failure

[Dave H. <dav...@da...>]

On Mon, Jun 18, 2012 at 6:22 PM, Bruce Korb <bru...@gm...> wrote:
> On 06/18/12 10:57, Dave Hart wrote:
>>
>> On Mon, Jun 18, 2012 at 5:38 PM, Bruce Korb<bru...@gm...>  wrote:
>>>
>>> On 06/17/12 23:26, Harlan Stenn wrote:
>>>>
>>>> On pogo, after fixing the zNotStr instance:
>
>
> I have not seen Harlan's message about zNotStr,
> so I don't know what the issue is.
>
>>> That does not build:
>
>
>>> But that message is completely bogus:
>>
>>
>> It doesn't seem bogus to me.  See below.
>>
>>>> #define SPN_WHITESPACE_CHARS(_s)      spn_ag_char_map_chars((char *)_s,
>>>> 11)
>>>> static inline char *
>>>> spn_ag_char_map_chars(char * p, unsigned int mask_ix)
>
>
>>>>         char const *  pzArgType;
>>>>         pzArgType = SPN_WHITESPACE_CHARS(pzArgType);
>>>
>>>
>>> the SPN_WHITESPACE_CHARS macro casts the pointer to "char *", stripping
>>> the qualifier.
>>
>>
>> Right, stripping the "const" qualifier triggers the warning.  No idea
>> why you didn't see it with gcc 4.5.2, but again what really broke the
>> build?  As Harlan mentioned he had to update a zNotStr reference to
>> the new identifier.
>
>
> When I build it for myself, I use -Wall -Werror and I do not see a failure,
> or even a warning.  Since spn_ag_char_map_chars does not care if the
> input is char const * or not, but the caller cares whether the result
> can be assigned to a char* pointer, I use the cast in the macro wrapper.
> I've been using this paradigm for decades and never seen a burp before.
> Why would gcc 4.5.2 be happy on psp-os1 and gcc 4.2 whack my knuckles on
> pogo?
> I suppose I can use a "void *" cast, but all I really want to do is
> strip the const-ness, not the underlying type.  A cudgel should not be
> required.

 A void * cast would suffer the same warning.  If
spn_ag_char_map_chars() accepts both const char * and char *
arguments, the correct argument prototype is const char *.  It is safe
to cast char * to const char *, but the reverse is not true--you are
breaking the contract with the compiler to not allow writes through
pointers to const declared as such.  My understanding is const char *
and char const * are equivalent, so spell it how you prefer.

It is quite feasible to honor const throughout AutoGen/AutoOpts, if
you so choose, but that means giving on up on the theory const is for
you to control your users but does not control you.  At worst, you'll
need to play dirty with const at the boundary to third party code that
gets it wrong.

I wish I understood why newer gcc isn't warning in the same situation
-- but I believe it's wrong, as any stripping of const potentially
violates the const contract (potentially because the consumers of
de-consted pointers may not in fact write).

Cheers,
Dave Hart

Re: [Autogen-users] 5.16.1 make check failure

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

On 06/18/12 10:57, Dave Hart wrote:
> On Mon, Jun 18, 2012 at 5:38 PM, Bruce Korb<bru...@gm...>  wrote:
>> On 06/17/12 23:26, Harlan Stenn wrote:
>>> On pogo, after fixing the zNotStr instance:

I have not seen Harlan's message about zNotStr,
so I don't know what the issue is.

>> That does not build:

>> But that message is completely bogus:
>
> It doesn't seem bogus to me.  See below.
>
>>> #define SPN_WHITESPACE_CHARS(_s)      spn_ag_char_map_chars((char *)_s, 11)
>>> static inline char *
>>> spn_ag_char_map_chars(char * p, unsigned int mask_ix)

>>>          char const *  pzArgType;
>>>          pzArgType = SPN_WHITESPACE_CHARS(pzArgType);
>>
>> the SPN_WHITESPACE_CHARS macro casts the pointer to "char *", stripping the qualifier.
>
> Right, stripping the "const" qualifier triggers the warning.  No idea
> why you didn't see it with gcc 4.5.2, but again what really broke the
> build?  As Harlan mentioned he had to update a zNotStr reference to
> the new identifier.

When I build it for myself, I use -Wall -Werror and I do not see a failure,
or even a warning.  Since spn_ag_char_map_chars does not care if the
input is char const * or not, but the caller cares whether the result
can be assigned to a char* pointer, I use the cast in the macro wrapper.
I've been using this paradigm for decades and never seen a burp before.
Why would gcc 4.5.2 be happy on psp-os1 and gcc 4.2 whack my knuckles on pogo?
I suppose I can use a "void *" cast, but all I really want to do is
strip the const-ness, not the underlying type.  A cudgel should not be required.

On psp-os1:

gcc -std=gnu99 -DHAVE_CONFIG_H -I. \
  -I/home/bkorb/autogen-5.16.1pre7/agen5 -I.. \
  -I.. -I/home/bkorb/autogen-5.16.1pre7 \
  -I../autoopts -I/home/bkorb/autogen-5.16.1pre7/autoopts \
  -I/usr/local/include  -D_REENTRANT -pthreads -g -O2 \
  -MT autogen-ag.o -MD -MP -MF .deps/autogen-ag.Tpo \
  -c -o autogen-ag.o ag.c

I wonder what the re-entrant pthreads are about.
Anyway, versus pogo:

gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../agen5 -I.. \
  -I.. -I../.. -I../autoopts -I../../autoopts   \
  -I/usr/local/gnu/include -g -O2 -MT autogen-ag.o \
  -MD -MP -MF .deps/autogen-ag.Tpo -c -o autogen-ag.o ag.c

Re: [Autogen-users] 5.16.1 make check failure

[Dave H. <dav...@gm...>]

On Mon, Jun 18, 2012 at 5:38 PM, Bruce Korb <bru...@gm...> wrote:
> On 06/17/12 23:26, Harlan Stenn wrote:
>> On pogo, after fixing the zNotStr instance:
>>
>> ...
>> PASS: loop.test
>> PATH is
>> /usr/local/gnu/bin:/usa/stenn/bin:/usr/local/bin:/usr/local/gnu/bin:/opt/SUNWrtvc/bin:/opt/SUNWspro/bin:/opt/netbeans-5.5.1/bin:/usr/X11R6/bin:/usr/bin/X11:/usr/openwin/bin:/bin:/usr/bin:/usr/ccs/bin:/usr/ucb:/usr/local/etc:/etc:/usr/local/sbin:/sbin:/usr/sbin:.
>> creating make.tpl
>> creating make.out in
>> /pogo/dist/gnu/autogen/autogen-5.16.1/A.pogo/agen5/test/testdir
>> FAILURE: 7,13d6
>> <
>> <  == converts to:
>> <
>> <        foo=`pwd`&&  ls -l $$foo ; \
>> <        bar=$$foo continue=command \
>> <        make macros: $(MAKE) $* $@ $<  $% $? ; \
>> <        shell vars:  $${MAKE} $$# $$F $${?} $${*} $$$$
>> FAIL: make.test
>> ...
>>
>
> on PSP-OS1:
>
>> ------------------------------------------------------------------------
>> Configuration:
>>
>>   Source code location:   /home/bkorb/autogen-5.16.1pre7
>>   Compiler:               gcc -std=gnu99
>>   Compiler flags:         -g -O2
>>   Host System Type:       i386-pc-solaris2.11
>>   Install path:           /home/bkorb/build/os1
>>
>>   See config.h for further configuration information.
>> ------------------------------------------------------------------------
>> $ make > ~/build/os1/build.log 2> ~/build/os1/errors.log
>> $ make check >> ~/build/os1/build.log 2>> ~/build/os1/errors.log
>> gmake install >> ~/build/os1/build.log 2>> ~/build/os1/errors.log
>> $ gmake install >> ~/build/os1/build.log 2>> ~/build/os1/errors.log
>> $ find ~/build/os1/
>> bin/        build.log   errors.log  include/    lib/        share/
>> /var/tmp/bkorb-AFaOY0/ag
>> $ find ~/build/os1/bin -type f
>> /home/bkorb/build/os1/bin/xml2ag
>> /home/bkorb/build/os1/bin/autogen
>> /home/bkorb/build/os1/bin/autoopts-config
>> /home/bkorb/build/os1/bin/columns
>> $ fgrep ' tests ' ~/build/os1/build.log
>> All 24 tests passed
>> All 41 tests passed
>> All 4 tests passed
>> $ gcc --version
>> gcc-4.5 (GCC) 4.5.2
>
> On POGO.UDEL.EDU:
>
>> ------------------------------------------------------------------------
>> Configuration:
>>
>>   Source code location:   ..
>>   Compiler:               gcc -std=gnu99
>>   Compiler flags:         -g -O2
>>   Host System Type:       sparc-sun-solaris2.10
>>   Install path:           /usa/bkorb/autogen-5.16.1/_i
>>
>>   See config.h for further configuration information.
>> ------------------------------------------------------------------------
>> ~/autogen-5.16.1/_b
>> $ ( exec > build.log 2> err.log
>>> set -e
>>> gmake
>>> gmake check
>>> gmake install
>>> ) &
>
> That does not build:
>
>> $ cat err.log
>> ../../autoopts/usage.c: In function 'prt_extd_usage':
>> ../../autoopts/usage.c:469: warning: passing argument 1 of 'spn_ag_char_map_chars' discards qualifiers from pointer target type

Why would that warning break the build?  I didn't see -Werr being used.

> But that message is completely bogus:

It doesn't seem bogus to me.  See below.

>> #define SPN_WHITESPACE_CHARS(_s)      spn_ag_char_map_chars((char *)_s, 11)
>> static inline char *
>> spn_ag_char_map_chars(char * p, unsigned int mask_ix)
>> {
>>     unsigned char const * v = ag_char_map_spanners[mask_ix];
>>     if (v == NULL)
>>         v = calc_ag_char_map_spanners(mask_ix);
>>     while (v[(unsigned)*p])  p++;
>>     return p;
>> }
>>
>>         char const *  pzArgType;
>>         pzArgType = SPN_WHITESPACE_CHARS(pzArgType);
>
> the SPN_WHITESPACE_CHARS macro casts the pointer to "char *", stripping the qualifier.

Right, stripping the "const" qualifier triggers the warning.  No idea
why you didn't see it with gcc 4.5.2, but again what really broke the
build?  As Harlan mentioned he had to update a zNotStr reference to
the new identifier.

>  > $ gcc --version
>  > gcc (GCC) 4.2.0

Cheers,
Dave Hart

Re: [Autogen-users] 5.16.1 make check failure

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

On 06/17/12 23:26, Harlan Stenn wrote:
> On pogo, after fixing the zNotStr instance:
>
> ...
> PASS: loop.test
> PATH is
> /usr/local/gnu/bin:/usa/stenn/bin:/usr/local/bin:/usr/local/gnu/bin:/opt/SUNWrtvc/bin:/opt/SUNWspro/bin:/opt/netbeans-5.5.1/bin:/usr/X11R6/bin:/usr/bin/X11:/usr/openwin/bin:/bin:/usr/bin:/usr/ccs/bin:/usr/ucb:/usr/local/etc:/etc:/usr/local/sbin:/sbin:/usr/sbin:.
> creating make.tpl
> creating make.out in
> /pogo/dist/gnu/autogen/autogen-5.16.1/A.pogo/agen5/test/testdir
> FAILURE: 7,13d6
> <
> <  == converts to:
> <
> <        foo=`pwd`&&  ls -l $$foo ; \
> <        bar=$$foo continue=command \
> <        make macros: $(MAKE) $* $@ $<  $% $? ; \
> <        shell vars:  $${MAKE} $$# $$F $${?} $${*} $$$$
> FAIL: make.test
> ...
>

on PSP-OS1:

> ------------------------------------------------------------------------
> Configuration:
>
>   Source code location:   /home/bkorb/autogen-5.16.1pre7
>   Compiler:               gcc -std=gnu99
>   Compiler flags:         -g -O2
>   Host System Type:       i386-pc-solaris2.11
>   Install path:           /home/bkorb/build/os1
>
>   See config.h for further configuration information.
> ------------------------------------------------------------------------
> $ make > ~/build/os1/build.log 2> ~/build/os1/errors.log
> $ make check >> ~/build/os1/build.log 2>> ~/build/os1/errors.log
> gmake install >> ~/build/os1/build.log 2>> ~/build/os1/errors.log
> $ gmake install >> ~/build/os1/build.log 2>> ~/build/os1/errors.log
> $ find ~/build/os1/
> bin/        build.log   errors.log  include/    lib/        share/
> /var/tmp/bkorb-AFaOY0/ag
> $ find ~/build/os1/bin -type f
> /home/bkorb/build/os1/bin/xml2ag
> /home/bkorb/build/os1/bin/autogen
> /home/bkorb/build/os1/bin/autoopts-config
> /home/bkorb/build/os1/bin/columns
> $ fgrep ' tests ' ~/build/os1/build.log
> All 24 tests passed
> All 41 tests passed
> All 4 tests passed
> $ gcc --version
> gcc-4.5 (GCC) 4.5.2

On POGO.UDEL.EDU:

> ------------------------------------------------------------------------
> Configuration:
>
>   Source code location:   ..
>   Compiler:               gcc -std=gnu99
>   Compiler flags:         -g -O2
>   Host System Type:       sparc-sun-solaris2.10
>   Install path:           /usa/bkorb/autogen-5.16.1/_i
>
>   See config.h for further configuration information.
> ------------------------------------------------------------------------
> ~/autogen-5.16.1/_b
> $ ( exec > build.log 2> err.log
>> set -e
>> gmake
>> gmake check
>> gmake install
>> ) &

That does not build:

> $ cat err.log
> ../../autoopts/usage.c: In function 'prt_extd_usage':
> ../../autoopts/usage.c:469: warning: passing argument 1 of 'spn_ag_char_map_chars' discards qualifiers from pointer target type

But that message is completely bogus:

> #define SPN_WHITESPACE_CHARS(_s)      spn_ag_char_map_chars((char *)_s, 11)
> static inline char *
> spn_ag_char_map_chars(char * p, unsigned int mask_ix)
> {
>     unsigned char const * v = ag_char_map_spanners[mask_ix];
>     if (v == NULL)
>         v = calc_ag_char_map_spanners(mask_ix);
>     while (v[(unsigned)*p])  p++;
>     return p;
> }
>
>         char const *  pzArgType;
>         pzArgType = SPN_WHITESPACE_CHARS(pzArgType);

the SPN_WHITESPACE_CHARS macro casts the pointer to "char *", stripping the qualifier.

 > $ gcc --version
 > gcc (GCC) 4.2.0

[Autogen-users] 5.16.1 make check failure

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

On pogo, after fixing the zNotStr instance:

...
PASS: loop.test
PATH is
/usr/local/gnu/bin:/usa/stenn/bin:/usr/local/bin:/usr/local/gnu/bin:/opt/SUNWrtvc/bin:/opt/SUNWspro/bin:/opt/netbeans-5.5.1/bin:/usr/X11R6/bin:/usr/bin/X11:/usr/openwin/bin:/bin:/usr/bin:/usr/ccs/bin:/usr/ucb:/usr/local/etc:/etc:/usr/local/sbin:/sbin:/usr/sbin:.
creating make.tpl
creating make.out in
/pogo/dist/gnu/autogen/autogen-5.16.1/A.pogo/agen5/test/testdir
FAILURE: 7,13d6
< 
< == converts to:
< 
<       foo=`pwd` && ls -l $$foo ; \
<       bar=$$foo continue=command \
<       make macros: $(MAKE) $* $@ $< $% $? ; \
<       shell vars:  $${MAKE} $$# $$F $${?} $${*} $$$$
FAIL: make.test
...

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

Re: [Autogen-users] Fwd: m4 error

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

On 06/02/12 05:02, Dave Hart wrote:
> dnl AG_PATH_AUTOOPTS([MIN-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]])
>
> The [] above are not intended to be correct m4 quoting, but rather
> simply show that all the arguments are optional.  Try:
>
> AG_PATH_AUTOOPTS([5.12], [], [AC_MSG_ERROR([Autoopts not found])])
>
> or possibly
>
> AG_PATH_AUTOOPTS([5.12], [], AC_MSG_ERROR([Autoopts not found]))
>
> My hunch is the first one will work, my head thinks the second one
> makes more sense.  So much for understanding m4 :)

Yep.  Dave understands it correctly.  I write syntax with pseudo-BNF
and the autoconf m4 quote characters conflict with that usage.
NOTE:  These are autoconf choices, not m4.  By default, m4 uses
the accent (backquote or "`" character) and the apostrophe ("'")
as open and close quotes.  Anyway, I wrote that probably a decade
ago and, in retrospect, it should be cleaned up.  Thank you.

Re: [Autogen-users] m4 error

[Dave H. <dav...@da...>]

On Sat, Jun 2, 2012 at 11:58 AM, illusionoflife
<ill...@gm...> wrote:
> On Saturday, June 02, 2012 11:40:53 you wrote:
>> AG_PATH_AUTOOPTS([5.12], [], [AC_MSG_ERROR([Autoopts not found])])
>> AG_PATH_AUTOOPTS([5.12], [], AC_MSG_ERROR([Autoopts not found]))
>>
>> My hunch is the first one will work, my head thinks the second one
>> makes more sense.  So much for understanding m4 :)
>
> Unfortuately, neither works. Same error.

I don't use that macro, but I'm guessing autoopts.m4 needs work to get
along with the latest autoconf and automake.  In paritcular,
AC_TRY_RUN and AC_TRY_LINK invocations need to add AC_LANG_PROGRAM or
AC_LANG_SOURCE wrapping the C source code.  If I were maintaining it,
I'd use [] quotes around a lot more macro arguments than autoopts.m4
does currently.

Cheers,
Dave Hart

Re: [Autogen-users] m4 error

[illusionoflife <ill...@gm...>]

On Saturday, June 02, 2012 11:40:53 you wrote:
> AG_PATH_AUTOOPTS([5.12], [], [AC_MSG_ERROR([Autoopts not found])])
> AG_PATH_AUTOOPTS([5.12], [], AC_MSG_ERROR([Autoopts not found]))
> 
> My hunch is the first one will work, my head thinks the second one
> makes more sense.  So much for understanding m4 :)

Unfortuately, neither works. Same error.

Re: [Autogen-users] m4 error

[Dave H. <dav...@gm...>]

On Sat, Jun 2, 2012 at 9:37 AM, illusionoflife
<ill...@gm...> wrote:
> Hello. I am trying to use autoopts,
> so I call
> AG_PATH_AUTOOPTS([5.12,[ ,[AC_MSG_ERROR([Autogen not found])]]])
>
> in configure.ac
> But I get following error. I suspect, that my version of autotools is too new.
> But what have I to do?

I can see how you might make this mistake, based on the documentation
in the source of AG_PATH_AUTOOPTS:

dnl AG_PATH_AUTOOPTS([MIN-VERSION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]]])

The [] above are not intended to be correct m4 quoting, but rather
simply show that all the arguments are optional.  Try:

AG_PATH_AUTOOPTS([5.12], [], [AC_MSG_ERROR([Autoopts not found])])

or possibly

AG_PATH_AUTOOPTS([5.12], [], AC_MSG_ERROR([Autoopts not found]))

My hunch is the first one will work, my head thinks the second one
makes more sense.  So much for understanding m4 :)

Cheers,
Dave Hart

[Autogen-users] m4 error

[illusionoflife <ill...@gm...>]

Hello. I am trying to use autoopts,
so I call
AG_PATH_AUTOOPTS([5.12,[ ,[AC_MSG_ERROR([Autogen not found])]]])

in configure.ac
But I get following error. I suspect, that my version of autotools is too new.
But what have I to do?

configure.ac:6: error: m4_defn: undefined macro: _AC_LANG
../../lib/autoconf/lang.m4:107: AC_LANG_POP is expanded from...
../../lib/autoconf/lang.m4:134: AC_LANG_RESTORE is expanded from...
/usr/share/aclocal/autoopts.m4:36: AG_PATH_AUTOOPTS is expanded from...
configure.ac:6: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: error: /usr/bin/autom4te failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

-- 
Best regards, illusionoflife
Contact me on ill...@gm... 
or sip:ill...@ek...
Please, read rfc1855, if did not already.
	

Re: [Autogen-users] autogen 5.16 does not build anymore with LDFLAGS="-Wl, -z, relro -Wl, --as-needed"

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

Hi Andreas,

Thank you for looking into it so deeply.  This has been broken for at
least 8 years.
My recent change brought it to the fore.  That ldflags computation
looks like something
someone else suggested, for use in autoopts-config.

On Sat, May 12, 2012 at 6:14 AM, Andreas Metzler
<ame...@do...> wrote:
> AG_LDFLAGS is set to "-Wl,-R" by AG_TEST_LDFLAGS. This is not new,
> however autoopts/test/defs.in has changed, it previously overwrote the
> value of AG_LDFLAGS as passed by ./configure/automake but uses the
> value now.

The correct thing for defs.in is to use it, but the value must be correct.
AG_TEST_LDFLAGS will now emit '-Wl,-R${libdir}' as its result, when
'-Wl,-R' should be used at all.  My config.status now has this line:

> S["AG_LDFLAGS"]="-Wl,-R${libdir}"

Thank you for the bug report.

Regards, Bruce

http://autogen.sourceforge.net/data/autogen-5.16.1pre2.tar.xz

Re: [Autogen-users] autogen 5.16 does not build anymore with LDFLAGS="-Wl, -z, relro -Wl, --as-needed"

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

Hi Andreas,

On Sat, May 12, 2012 at 6:56 AM, Andreas Metzler
<ame...@do...> wrote:
> The reason for this is the addition of the option -Wl,-R to the command.
>
> AG_LDFLAGS is set to "-Wl,-R" by AG_TEST_LDFLAGS. ...
>
> Afaiui the linker's -R option requires a filename as argument,
> therefore having -Wl,-R without argument in the linker line is a bug.

I wonder why I never stumbled before now.  Must not be used in
building the project.
Thank you for digging into it so deeply.

Regards, Bruce

[Autogen-users] autogen 5.16 does not build anymore with LDFLAGS="-Wl, -z, relro -Wl, --as-needed"

[Andreas M. <ame...@do...>]

Hello,
5.16 will not build (actually a testsuite failure) if
LDFLAGS="-Wl,-z,relro -Wl,--as-needed" is set.

------------------------------------
make[4]: Entering directory `/tmp/AUTOGEN/autogen-5.16/autoopts/test'
FAIL: alias.test
[...]
/usr/bin/ld: cannot find relro: No such file or directory
[...]
>rc-> cc_cmd=i486-linux-gnu-gcc -std=gnu99 -I/tmp/AUTOGEN/autogen-5.16 -I/tmp/AUTOGEN/autogen-5.16/autoopts -DHAVE_CONFIG_H -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat  -Wall -DTEST_TEST_RC_OPTS -I/tmp/AUTOGEN/autogen-5.16 -I/tmp/AUTOGEN/autogen-5.16/agen5 -I/tmp/AUTOGEN/autogen-5.16/autoopts -D_FORTIFY_SOURCE=2 -o rc rc.c /tmp/AUTOGEN/autogen-5.16/autoopts/.libs/libopts_la-libopts.o -Wl,-R -Wl,-z,relro -Wl,--as-needed    -lguile -lltdl -lgmp -lcrypt -lm -lltdl
------------------------------------

The reason for this is the addition of the option -Wl,-R to the command.

AG_LDFLAGS is set to "-Wl,-R" by AG_TEST_LDFLAGS. This is not new,
however autoopts/test/defs.in has changed, it previously overwrote the
value of AG_LDFLAGS as passed by ./configure/automake but uses the
value now.

Afaiui the linker's -R option requires a filename as argument,
therefore having -Wl,-R without argument in the linker line is a bug.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[Autogen-users] autogen 5.16 does not build anymore with LDFLAGS="-Wl, -z, relro -Wl, --as-needed"

[Andreas M. <ame...@do...>]

Hello,
5.16 will not build (actually a testsuite failure) if
LDFLAGS="-Wl,-z,relro -Wl,--as-needed" is set.

------------------------------------
make[4]: Entering directory `/tmp/AUTOGEN/autogen-5.16/autoopts/test'
FAIL: alias.test
[...]
/usr/bin/ld: cannot find relro: No such file or directory
[...]
>rc-> cc_cmd=i486-linux-gnu-gcc -std=gnu99 -I/tmp/AUTOGEN/autogen-5.16 -I/tmp/AUTOGEN/autogen-5.16/autoopts -DHAVE_CONFIG_H -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat  -Wall -DTEST_TEST_RC_OPTS -I/tmp/AUTOGEN/autogen-5.16 -I/tmp/AUTOGEN/autogen-5.16/agen5 -I/tmp/AUTOGEN/autogen-5.16/autoopts -D_FORTIFY_SOURCE=2 -o rc rc.c /tmp/AUTOGEN/autogen-5.16/autoopts/.libs/libopts_la-libopts.o -Wl,-R -Wl,-z,relro -Wl,--as-needed    -lguile -lltdl -lgmp -lcrypt -lm -lltdl
------------------------------------

The reason for this is the addition of the option -Wl,-R to the command.

AG_LDFLAGS is set to "-Wl,-R" by AG_TEST_LDFLAGS. This is not new,
however autoopts/test/defs.in has changed, it previously overwrote the
value of AG_LDFLAGS as passed by ./configure/automake but uses the
value now.

Afaiui the linker's -R option requires a filename as argument,
therefore having -Wl,-R without argument in the linker line is a bug.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: [Autogen-users] GNU AutoGen Version 5.16/AutoOpts Version 36.4

[John G. <gn...@to...>]

> NOTE: sometime "pretty soon", tar.gz files will not be distributed.
> .tar.gz:         ftp://ftp.gnu.org/gnu/autogen/rel5.16/autogen-5.16.tar.gz (deprecated)
> .tar.xz:         ftp://ftp.gnu.org/gnu/autogen/rel5.16/autogen-5.16.tar.xz

Please don't deprecate gz.  xz decompression has terrible memory size
implications.  Old or cheap machines (e.g. with megabytes rather than
gigabytes of DRAM) can't necessarily decompress an arbitrary xz file.
Check the man page.

Yes, I have several such machines around here -- including OLPCs,
cellphones, and old desktop computers.

I remember when EMACS stood for Eight Megs (of main memory) And
(despite that huge memory) Continuously Swapping (anyway).  If your
source code release file can't be decompressed on an 8-megabyte
machine, then don't release it that way.  (I just measured gzip and
it's doing fine in 2mb virtual, 508kb resident.)

	John Gilmore

[Autogen-users] pre-release for version 5.16

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

Hi folks,

There are some appreciable changes in the pipe line, the most visible of which
are the various documentation outputs (texi, man page, and mdoc).  There is
a new test for these (autoopts/test/doc.test) that does a basic job.
If it does not cover your favorite documentation feature, now would be a
good time to tweak that test to ensure the feature doesn't wiggle over time.
So just add the feature trigger that you need to the option definition section
of that file, generate the diffs for the result sections, and mail them to me
as a patch.  If you need to test stuff that requires conflicting settings in
the definitions file, please email me so we can set it up without multiplying
the size of the test :).  Thanks!!

http://autogen.sourceforge.net/data/autogen-5.16pre17.tar.xz

Thank you for your help!!

Regards, Bruce

[Autogen-users] strings.test failure on powerpc-darwin8

[David F. <fa...@cs...>]

Hi autogen-ers,
 	I'm seeing a single test failure on powerpc-darwin8:

http://paste.lisp.org/display/128456#1
Any idea what went wrong?

PATH is 
/Volumes/Mercedes2/sw/src/fink.build/autogen-5.15-1/autogen-5.15/build/columns:/Volumes/Mercedes2/sw/src/fink.build/autogen-5.15-1/autogen-5.15/build/getdefs:/Volumes/Mercedes2/sw/src/fink.build/autogen-5.15-1/autogen-5.15/build/agen5:/sw/bin:/sw/var/lib/fink/path-prefix-g++-4.0:/sw/lib/perl5/ExtUtils:/sw/bin:/sw/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin
/Volumes/Mercedes2/sw/src/fink.build/autogen-5.15-1/autogen-5.15/build/columns/columns
/Volumes/Mercedes2/sw/src/fink.build/autogen-5.15-1/autogen-5.15/build/agen5/autogen
creating string.tpl
creating string.def
>string-> ./string ''\''



\f\r\b\v\t\a\n
"Wow!"  This'\''ll be \hard\'\''
#endif /* .
and it'\''ll be a "hassle".
'\''' ''\''



\f\r\b\v\t\a\n
"Wow!"  This'\''ll be \hard\'\''
#endif /* .
and it'\''ll be a "hassle".
'\'''
Cooked shell is 92 bytes, not 93
Cooked shell generated string mismatches at offset 90 of 93
Expected char: 0x7F  saw char: 0x0A
Expected string:
==>'



\f\r\b\v\t\a\n
"Wow!"  This'll be \hard\'
#endif /* .
and it'll be a "hassle".
'<==

Generated string:
-->'



\f\r\b\v\t\a\n
"Wow!"  This'll be \hard\'
#endif /* .
and it'll be a "hassle".
'<--

>string-> res=1
>string-> cmp string.out string.raw
>string-> '[' 0 -ne 0 ']'
>string-> '[' 1 -eq 0 ']'
>string-> echo There were 1 string test failures
There were 1 string test failures
>string-> exit 1
FAILURE: strings do not match
FAIL: string.test




Fang

-- 
David Fang
http://www.csl.cornell.edu/~fang/

[Autogen-users] GNU AutoGen Version 5.15/AutoOpts Version 36.3

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

GNU AutoGen/AutoOpts is a two-part project that serves two separate
purposes.  The two parts are combined because they are inextricably
intertwined:

AutoGen is a tool designed to simplify the creation and maintenance of
programs that contain large amounts of repetitious text.  It is
especially valuable in programs that have several blocks of text that
must be kept synchronized.

AutoOpts is both an example of that and a project in its own right.
It is a very powerful configuration file, environment variable and
command line option documentation and management tool consisting of a
set of AutoGen templates and a run time library that nearly eliminates
the hassle of managing, parsing and documenting program options.

The self-referential example:
http://www.gnu.org/software/autogen/man1-autogen.html

NOTE: sometime "pretty soon", tar.gz files will not be distributed.

New in 5.15 - February, 2012
NEWS entries since the last release:


* aliasing options was only partially implemented.  Finished now.

* Generated texi documentation missed the new doc-section stanzas.

* compile issue on non-mmap platforms was fixed

* bug in usage error display was fixed

AutoGen home:    http://www.gnu.org/software/autogen/
primary ftp:     ftp://ftp.gnu.org/gnu/autogen/rel5.15/
.tar.gz:         ftp://ftp.gnu.org/gnu/autogen/rel5.15/autogen-5.15.tar.gz (deprecated)
.tar.xz:         ftp://ftp.gnu.org/gnu/autogen/rel5.15/autogen-5.15.tar.xz
bug reports:     autogen-users at the lists dot SourceForge net domain
bug archive:     http://sourceforge.net/mailarchive/forum.php?forum_id=7034
maintainer:      Bruce Korb - bkorb at the usual GNU domain

Re: [Autogen-users] building from git repository

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

>From SCM, autogen must be bootstrapped.
Its bootstrap was written long before gnulib's bootstrap and it is a little
out of hand.  Someday, I'll fix it, but I have a life outside of this and I'm
daunted.  Anyway, WRT configured files, the list is not nearly as dynamic
as it was a decade ago, so I could probably drop all that fanciness and just
list them.  That ought to be easy.

Bottom line:  either run config/bootstrap or extract the shar archive
in noag-boot.sh.
(BTW, source forge's GIT is more recent than GNU.  A habit I probably ought to
start changing.....)

On Sat, Feb 25, 2012 at 11:35 AM, Nikos Mavrogiannopoulos
<nm...@gn...> wrote:
> Hello,
>  I tried to build autogen from the git repository, but I cannot generate
> configure. If I run autoconf (2.68) I get errors on the use of AC_INIT.
> automake (1.11) also complains with an error:
>
> automake: no `Makefile.am' found for any configure output
> automake: Did you forget AC_CONFIG_FILES([Makefile]) in configure.ac?
>
> I attach a fix for the autoconf error, but it seems I might be missing
> something. Is configure.ac auto-generated somehow?

[Autogen-users] building from git repository

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

Hello,
 I tried to build autogen from the git repository, but I cannot generate
configure. If I run autoconf (2.68) I get errors on the use of AC_INIT.
automake (1.11) also complains with an error:

automake: no `Makefile.am' found for any configure output
automake: Did you forget AC_CONFIG_FILES([Makefile]) in configure.ac?

I attach a fix for the autoconf error, but it seems I might be missing
something. Is configure.ac auto-generated somehow?

regards,
Nikos

Re: [Autogen-users] autogen-5.15pre14

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

On 02/18/12 15:35, Harlan Stenn wrote:
> Bruce,
>
> I just downloaded 15pre14 and will be checking it out.
>
> Just to ask, what are folks doing to produce internationalized
> documentation when using autogen as the "source" for those docs?

I really do think the most straight forward approach is to just
translate the entire document.  When source change that change
the document, then the translator sees the change in the context
of the entire document.  Trying to generate the doc in a different
language seems like it induces more problems than it will solve.
But, hey, give it a shot.  If it saves effort, great!!

Re: [Autogen-users] autogen-5.15pre14

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

Bruce,

I just downloaded 15pre14 and will be checking it out.

Just to ask, what are folks doing to produce internationalized
documentation when using autogen as the "source" for those docs?

H

[Autogen-users] autogen-5.15pre14

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

http://autogen.sourceforge.net/data/autogen-5.15pre14.tar.xz
http://autogen.sourceforge.net/announce.html

(When Source Forge gets back up)

With a couple of new heavy users using the option stuff in ways
not used before, there has been some code churn.  I hope to
get 5.15 out in a week or two or so, but validation against
your code bases would be really nice, too.

Thanks for your help!   Regards, Bruce

2012-02-18  Bruce Korb  <bk...@gn...>

	* autoopts/test/alias.test: fully test "aliases" attribute.
	* autoopts/tpl/opt*.t*: allow empty homerc value to enable
	command line options witout automatically looking up config files.
	Also, add Doxygen comments to much of the generated code.
	* autoopts/tpl/strings.tpl: allow the specification of leader and
	trailer code for the emitted header.
	* config/misc.def: remove some antiquated testing

2012-02-12  Bruce Korb  <bk...@gn...>

	* autoopts/tpl/agtexi-cmd.tpl: cleanups
	* autoopts/tpl/man2texi.sh: convert \fI to @i and \fB to @var
	* compat/compat.h: sys/wait.h may not exist.  likewise u_int.
	* config/libopts.def: test for u_int type
	* doc/auto-opts.tpl: improve debuggability
	* everywhere: remove all residual "u_int" types.

2012-01-28  Bruce Korb  <bk...@gn...>

	* everywhere: redate copyrights
	* everywhere: use static char const tables where feasible.
	* autoopts/nested.c (optionLoadNested): deallocate empty result and
	return NULL when no entries have been found.  Set errno to ENOMSG.
	* add-on/char-mapper: clean up way for defining static scope
	* autoopts/autogen.map: use defined method for static scoping.
	(set-separator): new character class
	* autoopts/ao-strs.def: new file for autoopts strings
	* ChangeLog.10: give it a hunk of this file
	* autoopts/tpl/agtexi-cmd.tpl: emit the doc-section text, too.

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