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

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

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

Hi,

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.

On Thu, Mar 24, 2011 at 9:55 PM, Geof Sawaya <Geo...@ut...> wrote:
> Figure out where autogen installed libopts.so.33 (I'm guessing
> /usr/local/lib but I'm also x64-naive).  Try providing symlinks from
> places your distro likes better:
>
> ln -s /usr/local/lib/libopts.so.33 /usr/local/lib64
> ln -s /usr/local/lib/libopts.so.33 /usr/local/lib64/libopts.so

The name of the 64 bit library directory under /usr/local in a hybrid
environment is the subject of disagreement.  I think /usr/lib64
implies /usr/local/lib64, but I am not a distro maintainer.  You'd
have to devise a scheme for deciding that all distros would agree on.
Good luck.  Meanwhile, my ld.so.conf contains:

> /usr/X11R6/lib64
> /usr/X11R6/lib
> /usr/local/lib64
> /usr/local/lib
> /usr/x86_64-suse-linux/lib
> /opt/kde3/lib
> /lib64
> /lib
> /usr/lib64
> /usr/lib
> /opt/kde3/lib64
> include /etc/ld.so.conf.d/*.conf

so "lib64" is always looked at before plain "lib" and
both /usr/local directories are searched before /lib* and /usr/lib*.
That works for me.  Well, as long as I don't have a privately built
library that gets upgraded to be more recent in /usr/lib64.
At that point, I got to choose whether to break gcc or break my
pre-release autogen.  I chose obliterating /usr/local and starting
over. :)  Sorry it isn't any easier.

> More generically, this is a question to pose to other users of Ubuntu:
>  how do I configure and install tool overrides in /usr/local/* ?  I
> can tell you I believe you will find you suffer from opposing strong
> wills :)  Your distro may feel strongly that 64-bit libs belong in
> .../lib64, while autotools believes default-built shared libs go in
> /usr/local/lib, not /usr/local/lib64.

Exactly right.  Unless and until there is a way to select lib directory
names based on architecture for multi-architecture environments.

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

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

Thanks, Dave.  I ended up having to add a link in /usr/lib to /usr/local/lib/libopts.so.25.

Appreciate your effort in helping me out!

Best,
Geof

________________________________________
From: Dave Hart [dav...@gm...]
Sent: Thursday, March 24, 2011 9:05 PM
To: Geof Sawaya
Cc: aut...@li...
Subject: Re: [Autogen-users] FW: problem with auto-opts definition element . . .

On Fri, Mar 25, 2011 at 02:35 UTC, Geof Sawaya <Geo...@ut...> wrote:
> However, I can't get autogen to run -- I'm wondering if you might have a quick fix.  (BTW, using Ubuntu 10.10 x64)
>
> Check this output:
>
> sawaya@ubuntu:~/installations/autogen/autogen-5.11.6$ which autogen
> /usr/local/bin/autogen
> sawaya@ubuntu:~/installations/autogen/autogen-5.11.6$ autogen
> bash: /usr/bin/autogen: No such file or directory
> sawaya@ubuntu:~/installations/autogen/autogen-5.11.6$ echo $PATH
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> sawaya@ubuntu:~/installations/autogen/autogen-5.11.6$ /usr/local/bin/autogen
> /usr/local/bin/autogen: symbol lookup error: /usr/local/bin/autogen: undefined symbol: option_char_category

My hunch is your ld or ld.so isn't looking in /usr/local/lib or
/usr/local/lib64 or wherever libopts.so.* was installed.  Try:

$ ldd /usr/local/bin/autogen
/usr/local/bin/autogen:
        libopts.so.33 => /usr/local/lib/libopts.so.33 (0x28099000)
[...]

You probably have a "not found" or so after =>.  I'm not an expert on
shared libraries, I'm more familiar with how Windows DLLs are handled.
 But after flailing around a bit, I can throw some cheap hack ideas
out there anyway while we await more informed wisdom.

Figure out where autogen installed libopts.so.33 (I'm guessing
/usr/local/lib but I'm also x64-naive).  Try providing symlinks from
places your distro likes better:

ln -s /usr/local/lib/libopts.so.33 /usr/local/lib64
ln -s /usr/local/lib/libopts.so.33 /usr/local/lib64/libopts.so

then rebuild your autogen binary and reinstall it, and try running it
and/or using ldd to examine its shared library dependencies.  If that
doesn't work, you could try similar but dirtier (and sure to be broken
by installing packaged autogen):

ln -s /usr/local/lib/libopts.so.33 /usr/lib64
ln -s /usr/local/lib/libopts.so.33 /usr/lib64/libopts.so

Note the lib64 instead of lib is a guess on my part, you should be
able to determine which to use based on the other libraries you see
referenced in ldd output.

More generically, this is a question to pose to other users of Ubuntu:
 how do I configure and install tool overrides in /usr/local/* ?  I
can tell you I believe you will find you suffer from opposing strong
wills :)  Your distro may feel strongly that 64-bit libs belong in
.../lib64, while autotools believes default-built shared libs go in
/usr/local/lib, not /usr/local/lib64.

Good luck,
Dave Hart

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

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

On Fri, Mar 25, 2011 at 02:35 UTC, Geof Sawaya <Geo...@ut...> wrote:
> However, I can't get autogen to run -- I'm wondering if you might have a quick fix.  (BTW, using Ubuntu 10.10 x64)
>
> Check this output:
>
> sawaya@ubuntu:~/installations/autogen/autogen-5.11.6$ which autogen
> /usr/local/bin/autogen
> sawaya@ubuntu:~/installations/autogen/autogen-5.11.6$ autogen
> bash: /usr/bin/autogen: No such file or directory
> sawaya@ubuntu:~/installations/autogen/autogen-5.11.6$ echo $PATH
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> sawaya@ubuntu:~/installations/autogen/autogen-5.11.6$ /usr/local/bin/autogen
> /usr/local/bin/autogen: symbol lookup error: /usr/local/bin/autogen: undefined symbol: option_char_category

My hunch is your ld or ld.so isn't looking in /usr/local/lib or
/usr/local/lib64 or wherever libopts.so.* was installed.  Try:

$ ldd /usr/local/bin/autogen
/usr/local/bin/autogen:
        libopts.so.33 => /usr/local/lib/libopts.so.33 (0x28099000)
[...]

You probably have a "not found" or so after =>.  I'm not an expert on
shared libraries, I'm more familiar with how Windows DLLs are handled.
 But after flailing around a bit, I can throw some cheap hack ideas
out there anyway while we await more informed wisdom.

Figure out where autogen installed libopts.so.33 (I'm guessing
/usr/local/lib but I'm also x64-naive).  Try providing symlinks from
places your distro likes better:

ln -s /usr/local/lib/libopts.so.33 /usr/local/lib64
ln -s /usr/local/lib/libopts.so.33 /usr/local/lib64/libopts.so

then rebuild your autogen binary and reinstall it, and try running it
and/or using ldd to examine its shared library dependencies.  If that
doesn't work, you could try similar but dirtier (and sure to be broken
by installing packaged autogen):

ln -s /usr/local/lib/libopts.so.33 /usr/lib64
ln -s /usr/local/lib/libopts.so.33 /usr/lib64/libopts.so

Note the lib64 instead of lib is a guess on my part, you should be
able to determine which to use based on the other libraries you see
referenced in ldd output.

More generically, this is a question to pose to other users of Ubuntu:
 how do I configure and install tool overrides in /usr/local/* ?  I
can tell you I believe you will find you suffer from opposing strong
wills :)  Your distro may feel strongly that 64-bit libs belong in
.../lib64, while autotools believes default-built shared libs go in
/usr/local/lib, not /usr/local/lib64.

Good luck,
Dave Hart

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

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

________________________________________
From: Geof Sawaya
Sent: Thursday, March 24, 2011 7:59 PM
To: dav...@da...
Subject: RE: [Autogen-users] problem with auto-opts definition element . . .

Hi Dave,

OK, so I just installed 5.11.6.

However, I can't get autogen to run -- I'm wondering if you might have a quick fix.  (BTW, using Ubuntu 10.10 x64)

Check this output:

sawaya@ubuntu:~/installations/autogen/autogen-5.11.6$ which autogen
/usr/local/bin/autogen
sawaya@ubuntu:~/installations/autogen/autogen-5.11.6$ autogen
bash: /usr/bin/autogen: No such file or directory
sawaya@ubuntu:~/installations/autogen/autogen-5.11.6$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
sawaya@ubuntu:~/installations/autogen/autogen-5.11.6$ /usr/local/bin/autogen
/usr/local/bin/autogen: symbol lookup error: /usr/local/bin/autogen: undefined symbol: option_char_category

??

Thanks for your help.

Geof


________________________________________
From: Dave Hart [dav...@gm...]
Sent: Thursday, March 24, 2011 7:31 PM
To: Geof Sawaya
Cc: aut...@li...
Subject: Re: [Autogen-users] problem with auto-opts definition element . . .

On Fri, Mar 25, 2011 at 1:12 AM, Geof Sawaya <Geo...@ut...> wrote:
> 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’

I think this has already been fixed in the latest Autogen.  Note I
have a twisted pespective as I am accustomed to using bleeding-edge
autogen, often prerelease.  Which version do you see the problem with?
 I'm using 5.11.6.

Cheers,
Dave Hart

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

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

On Fri, Mar 25, 2011 at 1:12 AM, Geof Sawaya <Geo...@ut...> wrote:
> 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’

I think this has already been fixed in the latest Autogen.  Note I
have a twisted pespective as I am accustomed to using bleeding-edge
autogen, often prerelease.  Which version do you see the problem with?
 I'm using 5.11.6.

Cheers,
Dave Hart

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

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

Hi Bruce,

I hope you've found a job.

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?


Thanks for your work,


Geof

Re: [Autogen-users] "stanza" processing, i18n, ...

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

On 12/29/10 15:51, Harlan Stenn wrote:
>> Remember, this stuff is still in flux.  I am rewriting it
>> as "doc-sections" and each section describes its format:
>>
>> doc-section = {
>>   ds-type   = "SEE ALSO"; // etc.
>>   ds-format = man; // "texi", "mdoc", etc.
>>   ds-text   = <<- _EOF_
>>       whatever, including .man formatting tags
>>       _EOF_;
>> };
> 
> I think I really like that idea, and it would be OK to have the same
> ds-type in a different stanza with a different ds-format, right?  I
> mention this because there may still be times when the "source"
> ds-format does not translate to a "target" format the way we want, and
> the easy fix for that would be to also provide the stanza that is
> already in the desired format.

Hmmmm.  What you are asking for is multiple "doc-section"s that
have a "ds-type" of "SEE ALSO" (for example) and having some way
to distinguish them, depending upon output format. Sort-of a
"bypass output pattern" type of thing:

   ds-ignore = pod, mdoc;

Of course that can be done, but:

> Do you have a guess at the timeline for this?  I'm ready to start
> testing and using it...

My priority right now is finding employment.  Sorry.
You can find the beginnings of it by searching for
"doc-section" in the autoopts/tpl directory of the "pre"
releases.

>> The preferred input is going to be that which has sufficient
>> range of expressiveness to be able to be translated into the
>> other forms.
> 
> That would be nice, but I know I cannot force that on at least some of
> my users.  In this case, reality will bite me.

It is a trade off between maintaining multiple copies of
the same basic text vs. the hassle of figuring out a canonical
form that can be directly converted into all the desired
output forms.  If someone prefers maintaining multiple copies
then that means they prefer maintaining multiple copies.

>> I think that means texi and certainly would not
>> be plain text.  mdoc and man seem too limited and I am not familiar
>> with "pod", though these may be sufficient given the limited
>> expressiveness needed for usage documentation.
> 
> I pretty much (and possibly completely) agree.  I do believe that mdoc
> may be rich enough.  Kapila may know more about this.
> 
> But again, I am "forced" to let certain users dictacte the tag format
> they want to use, and I must allow them that.  If this user decides to
> cut/paste their text using html tags, that's their choice.  What I will
> do, after the fact, is take that stanza and add in another copy that
> will be in .mdoc or .texi (most likely, it depends) and then we'll all
> be happy.

Make an edict:
   All documentation shall be in mdoc format.

   If you are not familiar with mdoc format,
   that is fine.  We'll take your initial documentation
   and convert it to canonical form and then emit the
   needed documentation. The official source shall be mdoc.

> Where this is coming from on my end is the "detail" stanza, as I'm
> hoping that we can get things like boldface and underlining working
> there, but to do that easily means translating from "some tag format" to
> "plain text".

Ah, yes, the extra blurb at the end of the usage text output.
It does need some markup capabilities and the markup needs to
get stripped for usage output and it must not require markup.
I am open to suggestions from anyone.  :)

Re: [Autogen-users] "stanza" processing, i18n, ...

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

Hi Bruce,

Bruce wrote:
> On 12/27/10 14:26, Harlan Stenn wrote:
> > The following ramble is not fully thought-out.
> > 
> > I was thinking about how I'd like to be able to support i18n of our
> > docs, specifically looking toward the stanzas in a .def file.
> 
> I've gone to some trouble to try to get the libopts messages
> into a translatable form.  However, I don't think any attempt
> has been made to translate long option names, etc. so I confess
> to believing that there are many unresolved problems with it....

Makes perfect sense, and we're on the same page.  I just wanted to
mention it to be sure we were aware of it as we forged ahead.

> > While doing this, I also was again reminded that with Kapila's recent
> > work we can now expect to see things like 'prog-man-descrip' or
> > 'prog-mdoc-descrip'.
> 
> Remember, this stuff is still in flux.  I am rewriting it
> as "doc-sections" and each section describes its format:
> 
> doc-section = {
>   ds-type   = "SEE ALSO"; // etc.
>   ds-format = man; // "texi", "mdoc", etc.
>   ds-text   = <<- _EOF_
>       whatever, including .man formatting tags
>       _EOF_;
> };

I think I really like that idea, and it would be OK to have the same
ds-type in a different stanza with a different ds-format, right?  I
mention this because there may still be times when the "source"
ds-format does not translate to a "target" format the way we want, and
the easy fix for that would be to also provide the stanza that is
already in the desired format.

Do you have a guess at the timeline for this?  I'm ready to start
testing and using it...

> > Given that there are a number of templates that "share" stanzas, and
> > that we "need" and now "have" the ability to translate tags from one
> > format to another, I'm thinking that it would be Swell if there were
> > some internal autogen functions and variables that would "help out"
> > template writers, such as:
> > 
> > - a list of the preferred tag types, defaulting to, say:
> > 
> > 	texi mdoc pod man html text
> 
> The preferred input is going to be that which has sufficient
> range of expressiveness to be able to be translated into the
> other forms.

That would be nice, but I know I cannot force that on at least some of
my users.  In this case, reality will bite me.

> I think that means texi and certainly would not
> be plain text.  mdoc and man seem too limited and I am not familiar
> with "pod", though these may be sufficient given the limited
> expressiveness needed for usage documentation.

I pretty much (and possibly completely) agree.  I do believe that mdoc
may be rich enough.  Kapila may know more about this.

But again, I am "forced" to let certain users dictacte the tag format
they want to use, and I must allow them that.  If this user decides to
cut/paste their text using html tags, that's their choice.  What I will
do, after the fact, is take that stanza and add in another copy that
will be in .mdoc or .texi (most likely, it depends) and then we'll all
be happy.

> > - a function a la: expandStanza("stanzaName", "tagtype")
> > 
> > that would mean something like:
> 
> That is just a Scheme function away from being done.
> All you need to do is write the transform as a Scheme function.
> If it is generally useful, it can be incorporated into the
> added-on templates.  Something a bit more polished than this:
> 
>    (shellf "%s <<_EOF_\n%s\n_EOF_"
>       (find-file (string-append (get "ds-format") "2man"))
>       (get "ds-text"))
> 
> but that conveys the general idea:  look up a translator script
> based on the input format and the output format and have it filter
> the related text.  For extra credit, you can put the program
> name into the environment and have such a script look for magic
> markers:
> 
>    (shellf "export prog_name='%s'" (get "prog-name"))
> 
> and then replace markers like "@@PROG-NAME:italics@@"
> What I am sure I don't want to do is get into defining a new
> syntax for substituting values within values.  I think that
> there would lie madness.  Sorry.

I almost understand :)

Where this is coming from on my end is the "detail" stanza, as I'm
hoping that we can get things like boldface and underlining working
there, but to do that easily means translating from "some tag format" to
"plain text".

H

Re: [Autogen-users] "stanza" processing, i18n, ...

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

Hi Harlan,

On 12/27/10 14:26, Harlan Stenn wrote:
> The following ramble is not fully thought-out.
> 
> I was thinking about how I'd like to be able to support i18n of our
> docs, specifically looking toward the stanzas in a .def file.

I've gone to some trouble to try to get the libopts messages
into a translatable form.  However, I don't think any attempt
has been made to translate long option names, etc. so I confess
to believing that there are many unresolved problems with it....

> While doing this, I also was again reminded that with Kapila's recent
> work we can now expect to see things like 'prog-man-descrip' or
> 'prog-mdoc-descrip'.

Remember, this stuff is still in flux.  I am rewriting it
as "doc-sections" and each section describes its format:

doc-section = {
  ds-type   = "SEE ALSO"; // etc.
  ds-format = man; // "texi", "mdoc", etc.
  ds-text   = <<- _EOF_
      whatever
      _EOF_;
};

> Given that there are a number of templates that "share" stanzas, and
> that we "need" and now "have" the ability to translate tags from one
> format to another, I'm thinking that it would be Swell if there were
> some internal autogen functions and variables that would "help out"
> template writers, such as:
> 
> - a list of the preferred tag types, defaulting to, say:
> 
> 	texi mdoc pod man html text

The preferred input is going to be that which has sufficient
range of expressiveness to be able to be translated into the
other forms.  I think that means texi and certainly would not
be plain text.  mdoc and man seem too limited and I am not familiar
with "pod", though these may be sufficient given the limited
expressiveness needed for usage documentation.

> - a function a la: expandStanza("stanzaName", "tagtype")
> 
> that would mean something like:

That is just a Scheme function away from being done.
All you need to do is write the transform as a Scheme function.
If it is generally useful, it can be incorporated into the
added-on templates.  Something a bit more polished than this:

   (shellf "%s <<_EOF_\n%s\n_EOF_"
      (find-file (string-append (get "ds-format") "2man"))
      (get "ds-text"))

but that conveys the general idea:  look up a translator script
based on the input format and the output format and have it filter
the related text.  For extra credit, you can put the program
name into the environment and have such a script look for magic
markers:

   (shellf "export prog_name='%s'" (get "prog-name"))

and then replace markers like "@@PROG-NAME:italics@@"
What I am sure I don't want to do is get into defining a new
syntax for substituting values within values.  I think that
there would lie madness.  Sorry.

[Autogen-users] "stanza" processing, i18n, ...

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

The following ramble is not fully thought-out.

I was thinking about how I'd like to be able to support i18n of our
docs, specifically looking toward the stanzas in a .def file.

While doing this, I also was again reminded that with Kapila's recent
work we can now expect to see things like 'prog-man-descrip' or
'prog-mdoc-descrip'.

I was noting that I'd like the 'detail' stanza to have certain tags get
expanded (things like the program name, etc).

Right now, the detail stanza is "plain inhaled text" and it is not
post-processed.

Given that there are a number of templates that "share" stanzas, and
that we "need" and now "have" the ability to translate tags from one
format to another, I'm thinking that it would be Swell if there were
some internal autogen functions and variables that would "help out"
template writers, such as:

- a list of the preferred tag types, defaulting to, say:

	texi mdoc pod man html text

- a function a la: expandStanza("stanzaName", "tagtype")

that would mean something like:

 Scan the symbol table looking for 'stanzaName-tagtype'.
 If it is there, give it to me unmodified.
 If it is not there, start searching first for stanzaName-texi, then
 stanzaName-mdoc, ... (per the preferred tag type list mentioned above)
 and as soon as you find the first one use the translation stuff
 Kapila wrote to convert it to the desired "tagtype".

The other reason I like this is that it makes it much easier to support
new tag types and have them become automatically supported in existing
.tpl files.

I'm suggesting this because I do not want to have to maintain multiple
instances of a given stanza (for different output formats) unless I
absolutely have to.

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

Re: [Autogen-users] --select-suffix (kind of) breaks header-file macro

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

On 12/13/10 06:55, Dennis Wassel wrote:
> Hi Bruce, hi list,
> 
> FYI a small gotcha I stumbled over today:
> 
> Suppose I have a template file that produces both foo.c and foo.h, and says
> 
>   #include "[+ (. header-file) +]"
> 
> somewhere. This will nicely expand to
>   #include "foo.h"
> in the usual cases. If I issue --select-suffix=c though, because I do
> not want to regenerate foo.h right now, it expands to
>   #include "/dev/null"
> which is pretty irritating (and betrays the option's implementation :)

Don't do that.  ;-)  I confess, when writing the option templates
I only really considered --select-suffix=h.  But you are correct.
It is a template bug to have the "c" suffix code presume that the
"h" suffix code has run and left behind a scheme variable for it
to use.

> A workaround is to use
> 
>   #include "[+ (string-substitute (out-name) ".c" ".h") +]"

#include "[= (base-name) =].h"

since the option templates append the suffixes to the base name.
Each template needs to solve the problem for itself.

> instead.
> I am not saying this is a bug that needs fixing, but IMO it does
> somewhat violate the "least-surprise" principle.

Only ever use --select-suffix=h like I expected you to.  :-D

Regards, Bruce

P.S. I held my email while looking through the use of the "header-file"
scheme variable.  I've concluded that it is a difficult implementation
problem to say that these options are viable for all templates.
Templates are, by their nature, highly state-ful.  The template author
is, therefore, required to say whether or not a particular suffix
is optional or required.  In the case of a template that emits
  #include "/dev/null"
into a .c file in the absence of emitting the .h file, then emitting
the .h is required for emitting the .c.  As noted, though, fixing
this one is quite simple.  That is *not* the case with the options
template.  I construct a number of hash tables during the header
generation that are required to be there for the code generation.
So, I consider this an RFE for annotating the pseudo macro with
something that says, "this suffix is optional" and suffixes are required
by default.  Someday.  Not today. :)

Syntax suggestion: append a '?' character to the end of the suffix.
The character gets stripped and the suffix gets marked as "optional".

[Autogen-users] --select-suffix (kind of) breaks header-file macro

[Dennis W. <dw...@ma...>]

Hi Bruce, hi list,

FYI a small gotcha I stumbled over today:

Suppose I have a template file that produces both foo.c and foo.h, and says

  #include "[+ (. header-file) +]"

somewhere. This will nicely expand to
  #include "foo.h"
in the usual cases. If I issue --select-suffix=c though, because I do
not want to regenerate foo.h right now, it expands to
  #include "/dev/null"
which is pretty irritating (and betrays the option's implementation :)

A workaround is to use

  #include "[+ (string-substitute (out-name) ".c" ".h") +]"

instead.
I am not saying this is a bug that needs fixing, but IMO it does
somewhat violate the "least-surprise" principle.

Cheers,
Dennis

Re: [Autogen-users] make install problem w/ 5.11.4

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

On 12/09/10 19:25, Bruce Korb wrote:
>> ?

I now agree with that sentiment.

> $ egrep -v '^#' stamp-man
> AUTOGEN_stamp_man_TList = \
>         autogen.1
> 
> AUTOGEN_stamp_man_SList = \
>         ./opts.def \
>         ../autoopts/tpl/agman1.tpl \
>         ../autoopts/tpl/agman-lib.tpl
> 
> stamp-man : $(AUTOGEN_stamp_man_SList)
> 
> $(AUTOGEN_stamp_man_TList) : stamp-man
>         @:
> $ ls --full-time -tgor autogen.1 opts.def ../autoopts/tpl/agman1.tpl ../autoopts/tpl/agman-lib.tpl stamp-man autogen
> -rw-r--r-- 2  2452 2010-12-09 16:13:33.000000000 -0800 ../autoopts/tpl/agman-lib.tpl
> -rw-r--r-- 1 28403 2010-12-09 19:39:42.000000000 -0800 opts.def
> -rw-r--r-- 1 16250 2010-12-09 19:40:34.000000000 -0800 ../autoopts/tpl/agman1.tpl
> -rwxr-xr-x 1  4154 2010-12-09 19:40:40.000000000 -0800 autogen
> -rw-r--r-- 1   528 2010-12-09 19:43:27.000000000 -0800 stamp-man
> -r--r--r-- 1 19141 2010-12-09 19:43:28.000000000 -0800 autogen.1
> $ make stamp-man
> Re-building stamp-man
> /old-home/bkorb/ag/ag/agen5/autogen -L/old-home/bkorb/ag/ag/autoopts/tpl -L/old-home/bkorb/ag/ag/autoopts/tpl -MFstamp-man -Tagman1 -bautogen ./opts.def
> /old-home/bkorb/ag/ag/agen5/autogen -L/old-home/bkorb/ag/ag/autoopts/tpl -L/old-home/bkorb/ag/ag/autoopts/tpl -MFstamp-fmem fmemopen.def
> $ ls --full-time -tgor autogen.1 opts.def ../autoopts/tpl/agman1.tpl ../autoopts/tpl/agman-lib.tpl stamp-man autogen
> -rw-r--r-- 2  2452 2010-12-09 16:13:33.000000000 -0800 ../autoopts/tpl/agman-lib.tpl
> -rw-r--r-- 1 28403 2010-12-09 19:39:42.000000000 -0800 opts.def
> -rw-r--r-- 1 16250 2010-12-09 19:40:34.000000000 -0800 ../autoopts/tpl/agman1.tpl
> -rwxr-xr-x 1  4154 2010-12-09 19:40:40.000000000 -0800 autogen
> -rw-r--r-- 1   528 2010-12-09 19:44:41.000000000 -0800 stamp-man
> -r--r--r-- 1 19141 2010-12-09 19:44:42.000000000 -0800 autogen.1
> $ make stamp-man
> make: `stamp-man' is up to date.

I have no idea why it fired.  "autogen.1" depends upon "stamp-man"
explicitly in Makefile.am.  I have carefully ensured that the
sentinel file's time lies between autogen.1 and the source files.
I believe that with enough debug info and patience wading through
it, you can get make to tell you.

Re: [Autogen-users] make install problem w/ 5.11.4

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

On 12/09/10 18:46, Geof Sawaya wrote:
> Well, why does it need to rebuild stamp-man anyway
> (at the make install phase)?  Also, there is no file
> with the suffix you mentioned above after 'make'.
> I am running make install: 'sudo make install', which
> would explain write issues with stamp-man . . .
> 
> ?

In adding group/other read permissions I stumbled into it:
Because there is no clear way of saying "autogen.1 does not
depend upon the executable, but you have to create the
executable in order to re-create autogen.1", there is a
phony dependency of autogen.1 on autogen (the executable).
I am open to suggestions on a reasonable fix, but I don't
think "make" has the appropriate expressiveness.

Meanwhile, two solutions:

1.  configure && make && make && sudo make install
2.  configure && make && make install DESTDIR=$HOME/stage
    cd $HOME/stage
    sudo cp -fr $f /.

the latter is "more correct", but more bother, too.

Re: [Autogen-users] make install problem w/ 5.11.4

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

On 12/09/10 18:46, Geof Sawaya wrote:
>> The "-4lRijc" suffix is there only until the command completes correctly.
>> At that point, it is renamed to stamp-man.
> 
> Immediately after make, there is a stamp-man file in agen5, and stamp-man
> looks ljust like you described. (also with perms 600).

Yeah, it starts life as a temp file with limited access permissions.
Now that you've stubbed your toe, it is clear I should add go+r
permissions to it.  Thanks.

>> Two suggestions:
> 
>> 1. make sure "make" finishes before kicking off "make install"
>> 2. when you are building stuff, make sure ${top_builddir}/agen5
>>   is a writable directory.
> 
> Alas, neither of these is the case.
> 
>> If that is not the issue, then more analysis would be needed.
> 
> Well, why does it need to rebuild stamp-man anyway (at the make
> install phase)?  Also, there is no file with the suffix you
> mentioned above after 'make'.  I am running make install:
> 'sudo make install', which would explain write issues with stamp-man . . .
> 
> ?
> 
> Let me know what to check and / or info to give you.

It should not need to rebuild stamp-man.  "Makefile" should
be including that file and that file should correctly set the
dependencies so it is not rebuilt.  Another common dependency
question though:  are all your clocks in sync?  NFS causes
lotsa funny stuff when clocks are awry.  Come to think of it,
you have to be using NFS because root can do whatever it wants
on local directories.

Re: [Autogen-users] make install problem w/ 5.11.4

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

On 12/09/10 17:14, Geof Sawaya wrote:
> Hi Bruce and everyone,
> 
> I'm having an error with make install for this version on a particular machine.
> 
> One line of my output stands out in particular:  "fserr 13: cannot fopen for write stamp-man-4lRijc:  Permission denied"
> 
> Anyone have a guess?

I suspect a permission issue in the
/home/sawaya/temp/autogen/autogen-5.11.4/agen5
directory.  It looks like you are in the install phase, meaning
that the man pages ought to have been built by this time.

> make[3]: Nothing to be done for `install-data-am'.
> make[3]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/agen5/test'
> make[2]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/agen5/test'
> make[2]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/agen5'
> Re-building stamp-man
> /home/sawaya/temp/autogen/autogen-5.11.4/agen5/autogen -L/home/sawaya/temp/autogen/autogen-5.11.4/autoopts/tpl -L/home/sawaya/temp/autogen/autogen-5.11.4/autoopts/tpl -MFstamp-man -Tagman1 -bautogen ./opts.def
> fserr 13: cannot fopen for write stamp-man-4lRijc:  Permission denied
> bootstrap failure:  FAILED: /home/sawaya/temp/autogen/autogen-5.11.4/agen5/autogen -Tagman1 -bautogen ./opts.def
> make[2]: *** [stamp-man] Killed

"stamp-man" is now a useful file and should contain something like this:

# Makefile dependency file created by autogen
# with the following command:
#   /old-home/bkorb/ag/ag/agen5/.libs/autogen
#   -L/old-home/bkorb/ag/ag/autoopts/tpl
#   -L/old-home/bkorb/ag/ag/autoopts/tpl
#   -MFstamp-man
#   -Tagman1
#   -bautogen
#   ./opts.def
AUTOGEN_stamp_man_TList = \
	autogen.1

AUTOGEN_stamp_man_SList = \
	./opts.def \
	/old-home/bkorb/ag/ag/autoopts/tpl/agman1.tpl \
	/old-home/bkorb/ag/ag/autoopts/tpl/agman-lib.tpl

stamp-man : $(AUTOGEN_stamp_man_SList)

$(AUTOGEN_stamp_man_TList) : stamp-man
	@:

The "-4lRijc" suffix is there only until the command completes correctly.
At that point, it is renamed to stamp-man.

Two suggestions:

1. make sure "make" finishes before kicking off "make install"
2. when you are building stuff, make sure ${top_builddir}/agen5
   is a writable directory.

If that is not the issue, then more analysis would be needed.

[Autogen-users] make install problem w/ 5.11.4

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

Hi Bruce and everyone,

I'm having an error with make install for this version on a particular machine.

One line of my output stands out in particular:  "fserr 13: cannot fopen for write stamp-man-4lRijc:  Permission denied"

Anyone have a guess?

Thanks, as always -- Geof

*****full output******

karma:~/temp/autogen/autogen-5.11.4> sudo make install
Making install in compat
make[1]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/compat'
make[2]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/compat'
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/compat'
make[1]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/compat'
Making install in snprintfv
make[1]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/snprintfv'
make[2]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/snprintfv'
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/snprintfv'
make[1]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/snprintfv'
Making install in autoopts
make[1]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/autoopts'
Making install in test
make[2]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/autoopts/test'
make[3]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/autoopts/test'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/autoopts/test'
make[2]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/autoopts/test'
make[2]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/autoopts'
make[3]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/autoopts'
test -z "/usr/local/bin" || /bin/mkdir -p "/usr/local/bin"
 /usr/bin/install -c autoopts-config '/usr/local/bin'
test -z "/usr/local/lib" || /bin/mkdir -p "/usr/local/lib"
 /bin/sh ../libtool   --mode=install /usr/bin/install -c   libopts.la '/usr/local/lib'
libtool: install: /usr/bin/install -c .libs/libopts.so.25.8.4 /usr/local/lib/libopts.so.25.8.4
libtool: install: (cd /usr/local/lib && { ln -s -f libopts.so.25.8.4 libopts.so.25 || { rm -f libopts.so.25 && ln -s libopts.so.25.8.4 libopts.so.25; }; })
libtool: install: (cd /usr/local/lib && { ln -s -f libopts.so.25.8.4 libopts.so || { rm -f libopts.so && ln -s libopts.so.25.8.4 libopts.so; }; })
libtool: install: /usr/bin/install -c .libs/libopts.lai /usr/local/lib/libopts.la
libtool: install: /usr/bin/install -c .libs/libopts.a /usr/local/lib/libopts.a
libtool: install: chmod 644 /usr/local/lib/libopts.a
libtool: install: ranlib /usr/local/lib/libopts.a
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:/sbin" ldconfig -n /usr/local/lib
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
test -z "/usr/local/share/man/man3" || /bin/mkdir -p "/usr/local/share/man/man3"
 /usr/bin/install -c -m 644 ao_string_tokenize.3 configFileLoad.3 optionFileLoad.3 optionFindNextValue.3 optionFindValue.3 optionFree.3 optionGetValue.3 optionLoadLine.3 optionNextValue.3 optionOnlyUsage.3 optionProcess.3 optionRestore.3 optionSaveFile.3 optionSaveState.3 optionUnloadNested.3 optionVersion.3 strequate.3 streqvcmp.3 streqvmap.3 strneqvcmp.3 strtransform.3 '/usr/local/share/man/man3'
test -z "/usr/local/share/aclocal" || /bin/mkdir -p "/usr/local/share/aclocal"
 /usr/bin/install -c -m 644 autoopts.m4 '/usr/local/share/aclocal'
test -z "/usr/local/share/man/man1" || /bin/mkdir -p "/usr/local/share/man/man1"
 /usr/bin/install -c -m 644 autoopts-config.1 '/usr/local/share/man/man1'
test -z "/usr/local/share" || /bin/mkdir -p "/usr/local/share"
/bin/mkdir -p '/usr/local/share/pkgconfig'
 /usr/bin/install -c -m 644  pkgconfig/autoopts.pc '/usr/local/share/pkgconfig'
test -z "/usr/local/include" || /bin/mkdir -p "/usr/local/include"
/bin/mkdir -p '/usr/local/include/autoopts'
 /usr/bin/install -c -m 644  autoopts/options.h autoopts/usage-txt.h '/usr/local/include/autoopts'
test -z "/usr/local/share/autogen" || /bin/mkdir -p "/usr/local/share/autogen"
 /usr/bin/install -c -m 644 libopts-33.4.8.tar.gz tpl/aginfo.tpl tpl/aginfo3.tpl tpl/agman1.tpl tpl/agman3.tpl tpl/opthead.tpl tpl/options.tpl tpl/optlib.tpl '/usr/local/share/autogen'
test -z "/usr/local/share/autogen" || /bin/mkdir -p "/usr/local/share/autogen"
 /usr/bin/install -c -m 644 autoopts.m4 tpl/aginfodoc.tpl tpl/agman-lib.tpl tpl/agman-mdoc-cmd.tpl tpl/agman5.tpl tpl/agman8.tpl tpl/agmdoc5.tpl tpl/agmdoc8.tpl tpl/aoconf.tpl tpl/bits.tpl tpl/getopt.tpl tpl/man2mdoc.pl tpl/mdoc2man.pl tpl/mdoc2texi.pl tpl/optcode.tpl tpl/optmain.tpl tpl/rc-sample.tpl tpl/stdoptions.def tpl/texi2mdoc.pl tpl/usage-txt.tpl tpl/usage.tpl '/usr/local/share/autogen'
make  install-data-hook
make[4]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/autoopts'
make[4]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/autoopts'
make[3]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/autoopts'
make[2]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/autoopts'
make[1]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/autoopts'
Making install in agen5
make[1]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/agen5'
Making install in test
make[2]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/agen5/test'
make[3]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/agen5/test'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/agen5/test'
make[2]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/agen5/test'
make[2]: Entering directory `/home/sawaya/temp/autogen/autogen-5.11.4/agen5'
Re-building stamp-man
/home/sawaya/temp/autogen/autogen-5.11.4/agen5/autogen -L/home/sawaya/temp/autogen/autogen-5.11.4/autoopts/tpl -L/home/sawaya/temp/autogen/autogen-5.11.4/autoopts/tpl -MFstamp-man -Tagman1 -bautogen ./opts.def
fserr 13: cannot fopen for write stamp-man-4lRijc:  Permission denied
bootstrap failure:  FAILED: /home/sawaya/temp/autogen/autogen-5.11.4/agen5/autogen -Tagman1 -bautogen ./opts.def
make[2]: *** [stamp-man] Killed
make[2]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/agen5'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/sawaya/temp/autogen/autogen-5.11.4/agen5'
make: *** [install-recursive] Error 1

Re: [Autogen-users] "string-pad" not recognised by AutoGen 5.11.4

[Dennis W. <dw...@ma...>]

Hi Bruce,

Am 09.12.2010 18:09, schrieb Bruce Korb:
> These are Guile messages.  It means that the "string-pad"
> function is not defined.  It is probably part of some
> library that has not been loaded.  To use it, you need to
> determine how.  Something like this that _is_ used at
> Guile startup:
>    (use-modules (ice-9 common-list))

I remember seeing these before. Someone else had some Guile trouble, so
I had to hunt these ice-9 guys down on my system.

But then again this ...

> Also, I am not familiar with it because this is equivalent:
> 
>     Print('  <$
>     (sprintf "%-15s%s.%s"
>        thistype (get "inst") (get "name"))
>     $>', 1)

... works like a treat, and allowed me to kick out the whole cruft.
Thanks a ton!

> finally, a little nit:
> 
>> (string-append
>>             (. thistype)
> 
> The dot operator and parentheses are superfluous.

I promise to be good and not use unnecessary dot operators any more :)

Very helpful, thanks a lot!
Dennis

-- 
Zentrum für Technomathematik, AG Optimierung und Optimale Steuerung
 fon: 0421-218.63866   fax: 0421-218.9863866    web: www.worhp.de

Re: [Autogen-users] "string-pad" not recognised by AutoGen 5.11.4

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

On 12/09/10 03:11, Dennis Wassel wrote:
> Hi list,

Hi Dennis,

> Backtrace:
> In foo.tpl:
>   42: 0* [string-append "double" ...
>   44: 1*  (string-pad "" (- 15 (string-length thistype)))
> 
> foo.tpl:44:16: In expression (string-pad "" (- 15 #)):
> foo.tpl:44:16: Unbound variable: string-pad

These are Guile messages.  It means that the "string-pad"
function is not defined.  It is probably part of some
library that has not been loaded.  To use it, you need to
determine how.  Something like this that _is_ used at
Guile startup:
   (use-modules (ice-9 common-list))

Also, I am not familiar with it because this is equivalent:

    Print('  <$
    (sprintf "%-15s%s.%s"
       thistype (get "inst") (get "name"))
    $>', 1)

finally, a little nit:

> (string-append
>             (. thistype)

The dot operator and parentheses are superfluous.

>             (. (string-pad "" (- 15 (string-length (. thistype)))))
>             (get "inst")
>             "."
>             (get "name")
>         )

[Autogen-users] "string-pad" not recognised by AutoGen 5.11.4

[Dennis W. <dw...@ma...>]

Hi list,

a colleague of mine just installed AutoGen 5.11.4 on his machine, like this

autogen -v
autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.11.4

but the following bit of code causes an error on his machine:

    Print('  <$ (string-append
            (. thistype)
            (. (string-pad "" (- 15 (string-length (. thistype)))))
            (get "inst")
            "."
            (get "name")
        ) $>', 1)

(this code uses <$ and $> as markers). thistype is (define )'d above,
and "name" and "inst" are known here. The error message is

autogen --trace templates -b foo.tpl -T foo.tpl foo.def
open_output_file 'foo.f90' mode wb+
Template include.tpl included
out-push-new on temp file
out-push-new on temp file
Backtrace:
In foo.tpl:
  42: 0* [string-append "double" ...
  44: 1*  (string-pad "" (- 15 (string-length thistype)))

foo.tpl:44:16: In expression (string-pad "" (- 15 #)):
foo.tpl:44:16: Unbound variable: string-pad
No backtrace available.
Scheme evaluation error.  AutoGen ABEND-ing in template
    foo.tpl on line 42
Failing Guile command:  = = = = =

(string-append
            (. thistype)
            (. (string-pad "" (- 15 (string-length (. thistype)))))
            (get "inst")
            "."
            (get "name")
        )

This is puzzling because AG should pass "string-pad" down to Guile.
(I know that I am slightly abusing string-pad, but this was the simplest
way to produce 15-n spaces I could come up with; simpler solutions
appreciated, of course).

Guile version is 1.6.7, which according to its own manual

http://www.gnu.org/software/guile/docs/docs-1.6/guile-ref/Procedure-Index.html#Procedure%20Index

should have string-pad.
Any ideas what may be wrong?

Cheers,
Dennis

-- 
Zentrum für Technomathematik, AG Optimierung und Optimale Steuerung
 fon: 0421-218.63866   fax: 0421-218.9863866    web: www.worhp.de

Re: [Autogen-users] autogen gives symbol lookup error . . .

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

>Thank you for that.  This is clumsiness on my part.  libopts is in my
>search path and it normally contains the snv_vasprintf() so I didn't
>notice my goof.  This is fixed in 5.11.3 on gnu.org.  Sorry about that.

>Regards, Bruce

Thank you very much, Bruce.

Geof

Re: [Autogen-users] autogen gives symbol lookup error . . .

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

On 11/22/10 13:57, Geof Sawaya wrote:
> Hello Again,
> 
> I don't know what I've done to my system, but I'm guessing Autogen must be reading some template files by default.
> 
> If I run 'autogen' (no parameters) from anywhere on my system I get:
> 
> autogen: symbol lookup error: autogen: undefined symbol: snv_vasprintf
> 
> This is after removing and reinstalling autogen with Debian apt-get.
> 
> Anyone know how to track this one down?
> 
> You guys are great, I appreciate your help.

Hi Geof,

Thank you for that.  This is clumsiness on my part.  libopts is in my
search path and it normally contains the snv_vasprintf() so I didn't
notice my goof.  This is fixed in 5.11.3 on gnu.org.  Sorry about that.

Regards, Bruce

Re: [Autogen-users] autogen gives symbol lookup error . . .

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

Geof wrote:

> If I run 'autogen' (no parameters) from anywhere on my system I get:
> 
> autogen: symbol lookup error: autogen: undefined symbol: snv_vasprintf
> 
> This is after removing and reinstalling autogen with Debian apt-get.
> 
> Anyone know how to track this one down?

It comes from autogen's libsnprintfv, which should be "included" by your
libopts library.

H

[Autogen-users] autogen gives symbol lookup error . . .

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

Hello Again,

I don't know what I've done to my system, but I'm guessing Autogen must be reading some template files by default.

If I run 'autogen' (no parameters) from anywhere on my system I get:

autogen: symbol lookup error: autogen: undefined symbol: snv_vasprintf

This is after removing and reinstalling autogen with Debian apt-get.

Anyone know how to track this one down?

You guys are great, I appreciate your help.

Geof

Re: [Autogen-users] disable local linking of libopts . . .

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

Hi Geof,

It's pretty easy, we do this:

AC_DISABLE_SHARED
case "${enable_local_libopts+set}" in
 set) ;;
 *) enable_local_libopts=yes ;;
esac
case "${enable_libopts_install+set}" in
 set) ;;
 *) enable_libopts_install=no ;;
esac
LIBOPTS_CHECK([libopts])

(because we do not want to install our local copy, so we need a shared
copy to link against.)