Paul J wrote:
> I wish to produce a library from two xdr files, datarpc.x and
> visualrpc.x. Originally, the following GNU make commands produced the
> correct output files which, by means of a hand crafted makefile (using
> g++ as the compiler), compiled the rpcgen produced files into .o's:
Auto
David Bacher wrote:
>
> Hi Bruce,
>
> I'm having a problem building the latest autogen 5.4.6 on Mac OS X,
> while the old autogen is installed.
>
> When linking the new autogen executable, it finds the old (installed)
> verison of libopts instead of the new (local) libopts library. This
> causes
Ralf Corsepius wrote:
>
> Am Mit, 2002-11-13 um 19.08 schrieb Earnie Boyd:
> > I need to add a library specific to a target_os. I've tried several
> > possible techniques and can't get cooperation from the tools.
> >
> > What I want is something similar to:
> >
> > target_os := @target_os@
> >
>
Alexandre Duret-Lutz wrote:
> >> /bin/sh ../libtool --mode=link gcc -g -O2 -L/sw/lib -o autogen \
> >> -export-dynamic -lguile *.o -L/sw/lib -lguile -lm \
> >> -L../autoopts/.libs -lopts -ldl
> >> ld: Undefined symbols:
> >> _aopts_alloc
> >> _aopts_realloc
> >> _aopts_strdup
> >> make[1
Earnie Boyd wrote:
> Thanks Bruce,
>
> I used a modification of your suggestion:
>
>
> if test x$target_os == xmingw32; then
>WINSOCK=-lws2_32
> fi
> AC_SUBST(WINSOCK)
>
>
>
> LDADD := @LTLIBINTL@ @WINSOCK@
>
Actually, your "Makefile.in" will contain the line:
WINSOCK = @WINSOCK@
Alexandre Duret-Lutz wrote:
> What do people thinks about Automake's removal of core dumps?
>
> I tend to think it's a misfeature.
Only 'cuz it's implemented for the wrong target.
> For one thing, this doesn't match the documentation.
> Quizz: which of the following targets do you think
> Autom
> Why doesn't Automake support wildcards?
> ===
>
>Developers are lazy. People often they would like to use wildcards
> in `Makefile.am's so they don't need to remember they have to update
> `Makefile.am's every time they add, delete, or rename a file.
>
>
Alexandre Duret-Lutz wrote:
>
> Hi Bruce!
Hi, ALexandre! :-)
> I think we agree. The last sentence in this section was meant
> to imply such a patch would be considered, would someone mind
> enough to work it out.
I missed that nuance. :)
> Bruce> We have philosophical differences.
>
> F
At the end of this log, you'll see lines like this:
cp: cannot create regular file \
`blocksort-1.4.2/libopts/.deps/save.Plo': Permission denied
It used to work, of course, but I was persuaded to "upgrade"
automake/autoconf/libtool again. Silly me. I should learn.
It's as aggravating as heck
Alexandre Duret-Lutz wrote:
> Bruce> cp: cannot create regular file \
> Bruce> `blocksort-1.4.2/libopts/.deps/save.Plo': Permission denied
>
> Simply don't distribute these files.
Distributing files marked read-only or in read-only directories
really ought not cause a distribution failure. It
"Dr. David Kirkby" wrote:
>
> Hi,
> I've found in the past bugs in software are often found on one
> platform that don't seem to get noticed on another. For this reason I
> just tried to build gcc-2.0 on an old Sun SPARCstation 20 running
> SunOs 4.1.4 (ie hardware/software about 10 years
Paul Eggert wrote:
>
> Alex Hornby <[EMAIL PROTECTED]> writes:
>
> > On a related note, does the restriction of not using shell functions in
> > autoconf macros still remain,
>
> For Autoconf itself, we still avoid shell functions. But of course
> you can use shell functions in your own macros,
Charles Wilson wrote:
> I think the "winning" argument was as follows:
>for archaic systems whose shell does not support shfuncs, 'somebody'
> should create a snapshot of bash with a frozen autotool version
That's the argument that has been put forth over and over for years.
I couldn't re
Harlan Stenn wrote:
>
> I guess it's time for me to chime in.
>
> Dave Mills expect NTP to compile on anything he can get his hands on.
That's very nice. Why does he need to do this? I mean, the
compelling reason?
> I've been lucky so far in that some of the older gear he has is breaking. I
Richard Dawe wrote:
> > The problem, with html, is that nobody agree about what the
> > ouput should be. I'd say that if we support html, we should
> > use the default makeinfo output (which is to split on nodes),
> > and let the user say `AM_MAKEINFOFLAGS = --no-split' when wanted.
> > This is w
"Dr. David Kirkby" wrote:
>
> Hi,
> I'm hoping some king sole can help me here, as I am stuck. The only
> solution I can think of is rather messy.
>
> I have a configure.ac which sets a variable 'mpirun_found' to yes or
> no, depending on whether or not it can find a program called 'mpiru
Bob Friesenhahn wrote:
>
> On Thu, 4 Dec 2003, Gary V. Vaughan wrote:
> > I would be happy if I could do this:
> I tend to disagree with you on this point. I will agree if the system
> has three levels plus a way to provide overrides..
>
> Automake should support
>
> o inheritance of sta
Mohan Embar wrote:
>
> Hi Alexandre,
>
> >I'm not all that surprised your C program is much faster that the
> >shell script. For starters, it fails to support all of libtool's
> >configure-time options, such as --disable-static, --disable-shared,
> >--with-pic, as well as their per-compilation e
"Gary V. Vaughan" wrote:
> Hi Paolo,
>
> (Hi Bruce, how's it going?)
Hi, again, Gary - another autogen is pending -- i18n & getopt_long stuff
> Paolo Bonzini wrote:
> | I've finally managed to put on CVS the last 1.1 prerelease,
Hi Paolo,
I can't get it. I keep getting "invalid data from serv
Paolo Bonzini wrote:
>
> I understood the problem was with snprintfv, not with autogen. What are you using
> INFO_DEPS for? I think it is undocumented and internal to automake, maybe
> autogen_texi_DEPENDENCIES or something like that works (but I do not know if it
> actually exists...).
My gues
Laurence Finston wrote:
> The problem is that make makes certain assumptions that don't apply when CWEB
> is used. `ctangle .web' creates .c. Additional files can
> also be written. In 3DLDF, each .web also writes .h.
> [...] However, not all changes
> to a .web file cause the .c or .h file to dif
Earnie Boyd wrote:
> No, it is not an automake or autoconf bug. Autoconf and Automake are
> about portability and spaces in path names are not portable.
Explain that to some ported-to-unix programs that create
files with spaces in them. It is a matter of custom. On Unix,
the custom is to not d
Ben Elliston wrote:
>
> Automake will currently include a file called "ChangeLog" in the
> distribution. Many large projects use a scheme of appending a number
> to ChangeLogs when the files are rotated. For example, GCC uses:
>
> ChangeLog
> ChangeLog.0
> ...
> ChangeLog.10
>
> Can I
Alexandre Duret-Lutz wrote:
> How many people would be annoyed by this?
Not me :-)
> Is there any reason why this would be a very bad idea?
It is inconsistent? The auto* tools (viz. autoconf) still
assumes a shell that has no functions. This makes the config
script incredibly larger and slow
Karl Berry wrote:
>
> Hi folks,
> The obvious directory would be $(datadir)/html by analogy with
> $(datadir)/info, but it seems a bit arrogant to use such a generic name
Not arrogant so much as conflicting with where folks might want to
stash their own stuff.
> for something which only relates
Bob Friesenhahn wrote:
> I am against having separate install targets because GNU makefiles
> normally install everything by default and that is what users should
> expect. Installing everything is not a problem for distribution
> maintainers since they decide which files to package using their
>
Karl Berry wrote:
>
> We seem to be operating from different starting places.
Always true ;-), but I also understood your intent
> Having configure options such as --enable-doc-html is fine, if for some
> reason installers want to (re)generate the files.
Maybe I'm overloading the meaning of tha
Karl Berry wrote:
> 1. Please shorten to "html" (as is done for "ps")
>
> I'm not sure. By Bob's argument, `html' could be useful to stand for
> any sort of HTML generation, if there is non-Texinfo documentation involved.
Yeah! That's the idea! Type in, ``make html'' and any html-making
e contrib/gcc_update script does: handles the shortcomings
of CVS. Package distributors cannot distribute a package with out of date
stamps and folks that draw generated sources from CVS have to understand
that CVS has some limitations. Nothing new.
Ralph wrote:
> Bruce Korb writes:
> >
Simon Richter wrote:
> > I don't think this is true in general, a texinfo file could @include a
> > file that is built during the build phase.
>
> True, however that's a bad thing IMO, as it requires the user to have a
> working texinfo installation.
>
> > (For example, I generate Texinfo code do
John Ling wrote:
>
> Hello, I want to be able to read/check the value of an environment
> variable in my Makefile.am. This would be a variable that I set as part
> of the an [action-if-found] in the AC_SEARCH_LIBS method, that I set in
> configure.ac.
>
> How do I reference such a variable?
>
>
John Ling wrote:
>
> I think I've figured out the way to do it:
>
> In my Makefile.am I put in a line like 'export CONFIGURE-TIME_LIBS=$(LIBS)'
>
> Then in my Makefile.loader I put in my LIBS definition:
>
> LIBS = $(CONFIGURE-TIME_LIBS) ...
You might have better luck with CONFIGURE_TIME_LIBS
"Deneys S. Maartens" wrote:
>
> Hi Bruce
>
> When compiling the autogen source without having libxml2 available, and
> then doing a `make dist' creates a broken distribution package which
> does not include the xml2ag/ subdirectory.
>
> A configure of the broken dist package fails with the follow
Bob Friesenhahn wrote:
> Any recipient of the package should have the ability to become a
> package "maintainer" without removing site/developer specific hacks.
I hadn't considered a "make dist" for copying around a locally "fixed"
version. Certainly, one cannot really maintain a package for whi
"Gary V. Vaughan" wrote:
> Here's another:
And another:
``The following specific files are hereby deemed "public domain" and
you may use them any way you see fit.''
After all, these things are only useful with the Auto* tools and
I do not believe that any of them are state secrets, so why spend
Scott James Remnant wrote:
>
> On Wed, 2004-11-10 at 14:57 -0800, Paul Eggert wrote:
>
> > As a special exception to the GNU General Public License, if you
> > distribute this file as part of a package that automatically derives
> > from this file a configuration script (and perhaps some associat
Hi all,
This is new behavior with the latest released automake, and it happens
on Solaris but not Linux. The "Makefile.in" produced causes Solaris
"make" to choke and GNU make to think it is happy but do the following:
> /bin/ksh ../libtool --mode=link /net/megami/opt/apps/forte62/SUNWspro/bin/
Hi Alexandre!
Alexandre Duret-Lutz wrote:
> >> gmake[5]: Warning: File `autogen' has modification time 1.8 s in the
> future
> [...]
>
> I suggest you complain to your system administrator.
I have. They don't want to set up the ntpd. In any event, even
when I build on the NFS server, I get t
I decided to see what would happen when I changed:
man_MANS = autogen.1
into:
nodit_man_MANS = autogen.1
I got some curious stuff:
> install-man1: $(man1_MANS) $(man_MANS)
> @$(NORMAL_INSTALL)
> test -z "$(man1dir)" || $(mkdir_p) "$(DESTDIR)$(man1dir)"
> @list='$(man1_MAN
Leonardo Boiko wrote:
> Maybe you could add a small clarification: that LDADD and LIBADD are
> automake-specific variables. As far as I understand, there is a
> mumble_LDADD and a LDADD, but not an AM_LDADD, and plain LDADD is not
> from the user. Thus LDADD and LIBADD are entirely different fro
Maybe someone can figure out a better error message, please?
For those that found *this* message because of the subject line:
http://lists.gnu.org/archive/html/bug-automake/2004-07/msg00083.html
> Stephan> although AC_PROG_LIBTOOL _is_ present in configure.ac.
>
> Therefore it means AC_PROG_L
On Monday 06 December 2004 01:18 pm, Stepan Kasal wrote:
> Hi,
>
> On Mon, Dec 06, 2004 at 12:57:50PM -0800, Bruce Korb wrote:
> > Subject: 29,
> > 900 English pages for "Libtool library used but LIBTOOL is undefined"
>
> google is exaggerating, of co
Hi Stepan,
The solution is to not list the file in the list of files to be configured.
Instead, in your Makefile.am:
mumble-sh.in : $(mumble_PREDECESSORS)
create-mumble-sh-in
mumble.sh : mumble-sh.in
$(SHELL) $(top_builddir)/config.status --file mumble.sh:mumble-sh.in
Someon
The problem is is that XXX *DOES* actually appear in an AM_CONDITIONAL.
Right in the "configure.ac" file, actually. So, obviously, it is having some
problem actually finding the AM_CONDITIONAL not not being clear enough
for me to fix the issue. Is it necessary to macroize the text and only use
th
RTFM:
The shell CONDITION (suitable for use in a shell `if' statement)
is evaluated when `configure' is run. Note that you must arrange
for _every_ `AM_CONDITIONAL' to be invoked every time `configure'
is run - if `AM_CONDITIONAL' is run conditionally (e.g., in a
shell `i
On Saturday 08 January 2005 01:53 pm, Alexandre Duret-Lutz wrote:
> >>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes:
>
> Bruce> The problem is is that XXX *DOES* actually appear in an
> AM_CONDITIONAL.
>
> But these macros are not evaluated be
Hi Stepan,
On Monday 10 January 2005 06:00 am, Stepan Kasal wrote:
> So it's usually enough to write
> Well, I'd use
>
> if [some-shell-script-test]
> then
> ...
> AM_CONDITIONAL([XXX], [true])
> else
> ...
> AM_CONDITIONAL([XXX], [false])
> fi
This is more-or-less exactly what is
> $ autoreconf
> autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not
> AM_GNU_GETTEXT_VERSION
> autoreconf: cannot empty /tmp/ar0.4849: Is a directory
> $ find /tmp/ar0.4849
> /tmp/ar0.4849
> /tmp/ar0.4849/am4tu48Whq
> /tmp/ar0.4849/am4tCpTneD
> /tmp/ar0.4849/am4tiZINdq
> /tmp/ar0.4849/ahAqZ
On Tuesday 25 January 2005 01:37 am, Noah Misch wrote:
> On Sun, Jan 23, 2005 at 09:28:36AM -0800, Bruce Korb wrote:
> > > $ autoreconf
> > > autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not
> > > AM_GNU_GETTEXT_VERSION
>
> > 1. The automake
On Tuesday 25 January 2005 01:47 pm, Alexandre Duret-Lutz wrote:
> Bruce> Um, okay, but if automake is going to emit the message, then it only
> Bruce> makes sense (to me) that automake include the documentation.
>
> That would make sense to me too. However automake is not
> emitting the mess
What does this mean? I went and updated to a full SuSE 9.2 distribution.
Thanks! - Bruce
+ aclocal -I config
NONE:0: /usr/bin/m4: `m4_symbols' from frozen file not found in builtin table!
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal: autom4te failed with exit status: 1
+ exit 1
er
On Saturday 29 January 2005 11:31 am, Alexandre Duret-Lutz wrote:
> On Sat, Jan 29, 2005 at 11:12:49AM -0800, Bruce Korb wrote:
> > What does this mean?
>
> The same as the last time you asked, I guess.
> http://lists.gnu.org/archive/html/autoconf/2003-06/msg00085.html
You ar
On Tuesday 25 January 2005 01:47 pm, Alexandre Duret-Lutz wrote:
> >> > > $ autoreconf
> >> > > autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not
> AM_GNU_GETTEXT_VERSION
> >>
> >> > 1. The automake example of AM_GNU_GETTEXT does not show
> >> > AM_GNU_GETTEXT_VERSION being use
That section says:
>Many packages come with a script called `bootstrap.sh' or
> `autogen.sh', that will just call `aclocal', `libtoolize', `gettextize'
> or `autopoint', `autoconf', `autoheader', and `automake' in the right
> order. Actually this is precisely what `autoreconf' can do for you.
On Sunday 30 January 2005 03:53 pm, Andreas Schwab wrote:
> Bruce Korb <[EMAIL PROTECTED]> writes:
>
> > In fiddling with sharutils, I discovered that it is too early to encourage
> > the dropping of bootstrap scripts just yet. "autoreconf" does not provide
&
On Monday 21 February 2005 04:08 am, Gary V. Vaughan wrote:
> Hallo Bruce!
>
> Cc:ing automake list incase I need to be corrected here...
> Automake generates the -rpath flags for libtool automagically, so you
> shouldn't try to add your own. The key is in how the libraries are linked,
> and whe
I have now changed the Makefile.am thus:
autogen_LDADD = $(top_builddir)/autoopts/libopts.la $(LIBGUILE_LIBS)
and autogen_LDFLAGS = -export-dynamic. The net result:
> + /home/bkorb/ag/ag/agen5/autogen \
> -L/home/bkorb/ag/ag/autoopts argument.def
> /home/bkorb/ag/ag/agen5/.libs/lt-autogen: s
Hi Gary!
The solution is at the bottom. I stumbled onto it by playing
around with "env -" prefixes on various commands.
On Wednesday 23 February 2005 04:15 am, Gary V. Vaughan wrote:
> Hallo Bruce!
> You only need -export-dynamic if you are going to use lt_dlopen (NULL)
> to get a reflective m
Hi Aaron,
Aaron wrote:
Hey Bruce,
One more bug in pre12...
Running 'make dist-gzip' or any other 'dist-*' causes a blow up in the
libopts tear off. The problem is that EXTRA_DIST in the Makefile.am
includes the directory 'autoopts' which I think it confuses into
beliving it should build a binary o
Alexandre Duret-Lutz wrote:
"Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes:
>> libopts tear off. The problem is that EXTRA_DIST in the Makefile.am
>> includes the directory 'autoopts' which I think it confuses into
>> beliving it should buil
Hi,
I am sure that this is some config issue, but Google gives no help
on this one. "make" and "make check" are all happy, but when I
get to "make distcheck" it dies in the doc directory doing strange
things that I cannot even speculate about.
make[2]: Entering directory `/home/bkorb/ag/ag/auto
It was the macros going into the *source* directory in order to
build its products. Bad. But anyway, the cause was a minor
misordering of build functions. Thank you. :)
On Saturday 09 July 2005 02:26 pm, Bruce Korb wrote:
> Hi,
>
> I am sure that this is some config issue, but Goo
; does its thing.
On Saturday 09 July 2005 02:44 pm, Bruce Korb wrote:
> It was the macros going into the *source* directory in order to
> build its products. Bad. But anyway, the cause was a minor
> misordering of build functions. Thank you. :)
>
> On Saturday 09 July 2005 02:2
On Sunday 10 July 2005 10:32 am, you wrote:
> Hello,
Hi again :)
> I'm not sure I understand. The file doesn't have to exist, it only has
> to be listed as a distributed file in Makefile.am.
> It should be enough to get the rule in Makefile.in.
Wrong. Sorry :-(
> + automake --gnu --add-missin
On Sunday 10 July 2005 12:40 pm, Bruce Korb wrote:
> > I'm not sure I understand. The file doesn't have to exist, it only has
> > to be listed as a distributed file in Makefile.am.
> > It should be enough to get the rule in Makefile.in.
>
> Wrong. Sorry :-(
P
Antonio Coralles wrote:
I'm currently working on a small library. I only want the contents of
the 'examples' directory to be built if configure .
My toplevel Makefile.am contains:
if EXAMPLES
MAYBE_EXAMPLES = examples
endif
SUBDIRS = $(GENERIC_LIBRARY_NAME) $(MAYBE_EXAMPLES)
SUBDIRS =
Ed Hartnett wrote:
Howdy all!
I am using automake to build my library, and I have a slew of test
programs:
# These programs are all built for make check in this directory.
check_PROGRAMS = tst_h_files tst_h_atts tst_h_vars tst_h_grps \
tst_h_compounds tst_h_wrt_cmp tst_h_rd_cmp tst_h_
Hi,
I need to be able to create a source file and compile the thing
in my "make check" testing. Unfortunately, I have no need for
compiling anything in the "test" directory via "make", so the
Makefile.am has no: mumble_PROGRAMS stuff in it. Consequently,
there are no compile rules in the Makef
d in the test directory:
$(TESTS) : cc.defs
cd .. ; $(MAKE) test/cc.defs
and then use ${COMPILE} and ${LINK} in my test scripts? :)
I don't like it, but I think it ought to work
How reasonable is that? Thanks - Bruce
Bruce Korb wrote:
Hi,
I need to be able to create
Adnan Shaheen wrote:
Hi there,
I want to know how can i define macros in my configure.ac file.
If i can do it how i will define a macro TESTING in the configure.ac
For my code as
#ifdef TESTING
do this
#else // if not defined TESTING
do that
#endif // TESTING
Hi Adnan,
You're speaking the wr
Peter Ekberg wrote:
Hello!
I have the following needs:
1. Extract some data from a list of files using script foo.
2. Process the data further using a second script bar.
3. Concatenate the processed data.
4. Run a third script foobar on the concatenation to
produce a .c file.
5. Distribute t
Stepan Kasal wrote:
That principle could rather be achieved by omitting the *.c file
from the distribution, supposing that every "customer" can install
the tools which are required to generate it.
Not every customer wants to install developer tools. In general,
people who install a project ju
Allan Clark wrote:
>
> Perhaps the tack to sail on this component is not "make rpm" but "make
> package", where a number of files is converted to a ~.spec,
> prototype/pkginfo, ~.cmpnt/~.pkg/~.prod, or whatever:
>
> 1) list of files (source -> target)
> 2) inittab mods
> 3) rc.d mods
> 4) copywr
Akim Demaille wrote:
> >> Is it working for you when you start from a clean just-checked-out
> >> repository?
>
> Alexandre> Nope. The first problem is that autoconf needs itself to
> Alexandre> bootstrap.
>
> Not really, the CVS repository contains the full tarball (with
> configure, Makefile.
Earnie Boyd wrote:
>
> --- Bruce Korb <[EMAIL PROTECTED]> wrote:
> > I made an archive file named "configure" that contains
> > a shar archive of the generated files. It runs, recreating
> > the generated files, deletes itself and then runs autoconf.
>
Earnie Boyd wrote:
> > How about mv'ing itself out of the way (to configure.bak or something
> > similar)?
> >
>
> Can't do that either. A mv is a cp && rm.
1. It is only for developers
2 How about putting at the end:
( ( sleep 3 ; rm -f configure ; autoconf ) & )
exit 0
After 3 se
On 10/14/11 09:31, Dave Goodell wrote:
Having pondered this issue a lot for my playtime toy:
http://www.gnu.org/software/autogen
my solution was to implement -M options, a la gcc.
That's fine for that thing, but it leads me to what is likely
a proper ultimate solution for multi-output tools:
The --header-file=whatever fails to preserve the header file.
ylwrap builds in a subdirectory and removes it. I don't know
what the easiest fix is. For now, I've hacked ylwrap to look
for a header with a name other than y?tab.h and, if it exists,
move it up one directory. Not very satisfactory,
On 10/17/11 10:35, Bruce Korb wrote:
The --header-file=whatever fails to preserve the header file.
ylwrap builds in a subdirectory and removes it. I don't know
what the easiest fix is. For now, I've hacked ylwrap to look
for a header with a name other than y?tab.h and, if it exists,
PING:
The bison accepts the option, --header-file=whatever.h
"ylwrap" is a wrapper script meant to canonicalize the invocation
of yacc and bison. True enough, if you use --header-file you
had better be using bison, but here is the problem:
I am working on a project that will only build in a GNU
Let's see if these are the right lists
It's partly autoconf because autoconf stages dummy dependency files
so the make include function won't choke. It is partly make because
I find it a bit tricky getting the dependencies just right. It is,
I think, mostly an automake question since I thin
My tool versions, an edited transcript with the failure message and then a help
request.
$ for f in autoconf automake libtool ; do $f --version | head -1 ; done
autoconf (GNU Autoconf) 2.68
automake (GNU automake) 1.11.1
libtool (GNU libtool) 2.4
chmod -R a-w autogen-5.16pre15; chmod a+w autog
On 03/29/12 16:37, Bruce Korb wrote:
My tool versions, an edited transcript with the failure message and then a help
request.
I modified the top level Makefile thus:
&& test -f xml2ag/Makefile \
&& $(MAKE) $(AM_MAKEFLAGS) \
&&
On 03/31/12 01:34, Stefano Lattarini wrote:
Is this a known problem or do I need to investigate further?
The issue you're facing sounds new to me, so I say some more investigations
are warranted. Could you maybe post a minimal reproducer of the issue here,
so that we can decide whether it is a
On 03/31/12 09:24, Bruce Korb wrote:
>installcheck-recursive> test -f xml2ag/Makefile
>installcheck-recursive> test no = no
>installcheck-recursive> make installcheck-am
GNU Make 3.82
[]
Must remake target `installcheck'.
Successfully remade target file `installc
On 03/31/12 13:44, Bruce Korb wrote:
I didn't see it at first because of the comment that made it look like
something different from the "installcheck-am" rule. The problem
is a *partially* commented out maintainer-clean rule.
installcheck-am:
#maintainer-clean: maintainer-
On 03/31/12 13:58, Bruce Korb wrote:
On 03/31/12 13:44, Bruce Korb wrote:
I didn't see it at first because of the comment that made it look like
something different from the "installcheck-am" rule. The problem
is a *partially* commented out maintainer-clean rule.
installcheck-a
automake is trying to tell me something, but I cannot make out exactly what.
The literal meaning of the messages is pretty clear, but what they caution
about are things that appear to me to be correct.
> autoreconf --force --install --verbose --symlink
> autoreconf: Entering directory `.'
> autore
Hi Dave, Stefano,
On Thu, Nov 8, 2012 at 11:40 AM, Dave Goodell wrote:
> On Nov 8, 2012, at 1:19 PM CST, Stefano Lattarini wrote:
>
>> On 11/08/2012 07:56 PM, Bruce Korb wrote:
>> I'd expect its definition to be brought in by the 'libtoolize' call
>> issue
a sharutils test. I needed a large tree to archive into a split up
archive that I then unroll and validate. What would be more convenient
than to create a temporary directory and archive all of
cd ${top_builddir}
Worked like a charm. It is huge and has to be split up and has
a mixture of binar
What might induce configure to insert a space after "-g" and before "gdb3"?
configure:15849: result: no
configure:15864: checking whether uname(2) is POSIX
configure:15880: /usr/bin/gcc -std=gnu99 -o conftest -ggdb3 conftest.c -ldl
>&5
+ eval '$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLA
On 01/06/13 10:33, Bruce Korb wrote:
>> diff -r /u/gnu/proj/sharutils-bld/sharutils-4.13.3/_build/tests/shar-3.log
>> shar-3.d/tests/shar-3.log
>> 1d0
>> < Only in
>> /u/gnu/proj/sharutils-bld/sharutils-4.13.3/_build/doc/sharutils.t2d/sharutils.t2d:
>>
On 02/19/13 03:09, Stefano Lattarini wrote:
>> How can I fix this error?
>>
> Automake doesn't have nor provide any 'autogen.sh' file itself; so you'll
> have to report this to the developers of the package you are trying to
> bootstrap.
"Autogen" is also a project that I maintain, so were you to
On 05/06/15 01:58, Michael Haubenwallner wrote:
Trivial patch for fixincludes.
A) sufficiently trivial that explicit permission ought not be required
B) it is now officially blessed that we can coalesce year lists.
Let's do so, okay?
Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:
H
I ask because after printing this:
> =
> autogen-5.18.15 archives ready for distribution:
> autogen-5.18.15.tar.gz
> autogen-5.18.15.tar.xz
> =
I get this message:
> CDPATH="${ZSH_VERSION+.}:" && cd .
An additional data point:
On Sat, Aug 4, 2018 at 12:29 PM Bruce Korb wrote:
>
> I ask because after printing this:
>
> > =
> > autogen-5.18.15 archives ready for distribution:
> > autogen-5.18.15.tar.gz
Hi,
Googling doesn't get me any answers and I cannot rebuild until
autoreconf is gotten working.
The embedded autoreconf step that fails is automake. I have no idea at
all what the message is really trying to say. Help, please?
$ automake --add-missing --no-force
Makefile.am: error: installing '.
', "$libdir/$file", $fullfile))
> {
> $suppress = 0;
> $trailer = "\nerror while copying";
> }
> - Dan
>
> On Sat, Aug 31, 2019 at 5:17 PM Bruce Korb wrote:
> >
> > Hi,
> >
>
2019 at 4:39 PM Bruce Korb wrote:
>
> Long, long ago I learned that the safest thing is to purge my build
> directory and create a new one.
> After that, I link in all of my managed sources and then create any
> derived sources I need.
> After doing that, I run "autoreconf"
So in the years since I last rebuilt my project, it seems the world
has changed. I spent two days pounding on configury stuff just to get
it to the point where bootstrapping once again succeeds and the
project built and ran "make check". With more fiddling, I got it to
roll up a distribution, but t
1 - 100 of 197 matches
Mail list logo
