You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Jim Meyering <ji...@meyering.net> on 2006/12/05 11:59:27 UTC
Re: bootstrap problem
Alan Conway <ac...@redhat.com> wrote:
> Hi Jim,
>
> I'm still having problems with bootstrap in a fresh checkout:
>
> [aconway@scooter cpp]$ ./bootstrap
> /bin/sh: AmqpClass.java: command not found
> /bin/sh: line 1: -cp: command not found
> make: *** [timestamp] Error 127
> automake: cannot open < gen/gen-src.mk: No such file or directory
>
> The problem seems to be the use of an undefined variable $(JAVA) in the
> sh-filtered version of gen/Makefile.am. You mentioned this is set by
> autoconf, but at this point we haven't run autoconf, so I don't see how
> it can be set.
Ahh... "in a fresh checkout". Now I see. Sorry it took so long.
Steven, this ought to solve your problem, too.
Here's a patch for that, along with a small fix for gen/Makefile.am:
2006-12-05 Jim Meyering <me...@redhat.com>
* gen/Makefile.am (timestamp): Remove unnecessary "; \",
that could have obscured a failure.
(gen-src.mk): Use echo 'var = '\\, rather than 'var = \'.
Both work, but emacs' font-lock mode mishandles the latter.
* bootstrap: Give JAVA and JAVAC default values, and export them.
Don't define abs_srcdir; no longer needed.
Also filter out gen/Makefile.am's echo warning: ...
Add comments.
Index: gen/Makefile.am
===================================================================
--- gen/Makefile.am (revision 482368)
+++ gen/Makefile.am (working copy)
@@ -15,9 +15,9 @@
timestamp: $(spec) $(java_sources) $(cxx_templates)
if BUILD_IN_MESSAGE_TREE
rm -f $(generated_sources)
- (cd $(gentools_srcdir) && rm -f *.class && $(JAVAC) *.java); \
- $(JAVA) -cp $(gentools_dir)/src org.apache.qpid.gentools.Main \
- -c -o . -t $(gentools_dir)/templ.cpp $(spec)
+ cd $(gentools_srcdir) && rm -f *.class && $(JAVAC) *.java
+ $(JAVA) -cp $(gentools_dir)/src org.apache.qpid.gentools.Main \
+ -c -o . -t $(gentools_dir)/templ.cpp $(spec)
else
echo "warning: failed to regenerate gen/*.{cpp,h}" 1>&2
endif
@@ -28,15 +28,15 @@
DISTCLEANFILES = gen-src.mk
gen-src.mk: timestamp
- ( echo 'generated_sources = \' \
+ ( echo 'generated_sources = '\\ \
&& ls *.cpp *.h | sort -u | sed 's/.*/ & \\/;$$s/ \\//' \
) > $@-t
if BUILD_IN_MESSAGE_TREE
( echo if BUILD_IN_MESSAGE_TREE; \
- echo 'java_sources = \' \
+ echo 'java_sources = '\\ \
&& find $(gentools_srcdir) -name '*.java' \
| sort -u | sed 's/.*/ & \\/;$$s/ \\//'; \
- echo 'cxx_templates = \' \
+ echo 'cxx_templates = '\\ \
&& find $(gentools_dir)/templ.cpp -name '*.tmpl' \
| sort -u | sed 's/.*/ & \\/;$$s/ \\//'; \
echo endif \
Index: bootstrap
===================================================================
--- bootstrap (revision 482368)
+++ bootstrap (working copy)
@@ -4,13 +4,22 @@
autoheader
libtoolize --automake
+# These are needed only if you don't already have the gen/*.{h,cpp} files.
+: ${JAVA=java}
+: ${JAVAC=javac}
+export JAVA JAVAC
+
# If we're building in the qpid tree, we can generate
# some Makefile snippets:
if test -d ../gentools && test -d ../specs; then
+ # Transform gen/Makefile.am, removing automake-constructs and the
+ # contents of the sole automake-else clause (the warning), then
+ # use the result to run the rules that create gen-src.mk, a file
+ # that must be created before we run automake.
(cd gen && rm -f gen-src.mk
- perl -ne '/^(abs_srcdir|if|else|endif|include)\b/ or print' Makefile.am \
- | make -f - abs_srcdir=`pwd` srcdir=. gen-src.mk > /dev/null )
+ perl -ne '/warning:|^(if|else|endif|include)\b/ or print' Makefile.am \
+ | make -f - srcdir=. gen-src.mk > /dev/null )
fi
# Generate (for automake) lots of repetitive parts of tests/Makefile.am.
Re: bootstrap problem
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2006-12-05 at 16:27 +0000, Steven Shaw wrote:
> On 05/12/06, Daniel Kulp <da...@iona.com> wrote:
> > However, why does all the README's and such say:
> >
> > * CppUnit 1.10.2: http://cppunit.sourceforge.net
>
> That's not quite fair. You didn't read all the READMEs! Methinks you
> only read README-dev.
Yup, there's a typo in README-dev, will fix.
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 05/12/06, Daniel Kulp <da...@iona.com> wrote:
> However, why does all the README's and such say:
>
> * CppUnit 1.10.2: http://cppunit.sourceforge.net
That's not quite fair. You didn't read all the READMEs! Methinks you
only read README-dev.
Re: bootstrap problem
Posted by Daniel Kulp <da...@iona.com>.
On Tuesday 05 December 2006 10:54, Steven Shaw wrote:
> On 05/12/06, Daniel Kulp <da...@iona.com> wrote:
> > checking for APR... yes
> > checking for CPPUNIT... configure: error: Package requirements (cppunit
> > >= 1.10.2) were not met:
> >
> > No package 'cppunit' found
>
> Probably because it required >=1.11.4 but if you install one yourself
> be sure to use 1.11.6 as that one has a .pc file.
OK. Unmasking cppunit and re-emerging it got 1.11.6 which does work.
However, why does all the README's and such say:
* CppUnit 1.10.2: http://cppunit.sourceforge.net
Should those be updated?
Also, after a bootstrap/config cycle, I've noticed that it modified a bunch of
svn checked in files:
M build-aux/config.guess
M build-aux/config.sub
M build-aux/ltmain.sh
Is that bad? Wouldn't a commit then include those things. Would that
screw everybody up?
Anyway, "make" now works. "make check" passes. That's 64bit build as well
BTW. :-)
My summary for Gentoo:
1) You need to unmask dev-util/cppunit and dev-libs/apr:
echo ">=dev-libs/apr-1.0.0" >> /etc/portage/package.unmask
echo "dev-libs/apr" >> /etc/portage/package.keywords
echo "dev-util/cppunit" >> /etc/portage/package.keywords
2) Run "emerge cppunit apr" to install the new versions.
3) ./configure will fail the first time , but will give instructions on how to
run libtoolize to fix it. Run that once and re-run configure.
All is fine after that.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
Re: bootstrap problem
Posted by Jim Meyering <ji...@meyering.net>.
Daniel Kulp <da...@iona.com> wrote:
> checking for CPPUNIT... configure: error: Package requirements (cppunit >=
> 1.10.2) were not met:
>
> No package 'cppunit' found
>
>
> I'm stumped on that one as I DO have cppunit installed.
> dkulp@dilbert ~/working/qpid/cpp $ cppunit-config --version
> 1.10.2
> dkulp@dilbert ~/working/qpid/cpp $ cppunit-config --libs
> -L/usr/lib64 -lcppunit -ldl
> and /usr/include/cppunit exists and has a bunch of headers and such.
In retrospect, not having the latest version of cppunit
shouldn't make configure fail. It's not a build dependency,
after all. However, if you don't have something recent enough,
running "make check" may well fail.
I'll submit a patch to make it so configure merely warns about this.
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 05/12/06, Daniel Kulp <da...@iona.com> wrote:
> checking for APR... yes
> checking for CPPUNIT... configure: error: Package requirements (cppunit >=
> 1.10.2) were not met:
>
> No package 'cppunit' found
Probably because it required >=1.11.4 but if you install one yourself
be sure to use 1.11.6 as that one has a .pc file.
Re: bootstrap problem
Posted by Daniel Kulp <da...@iona.com>.
On Tuesday 05 December 2006 10:14, Alan Conway wrote:
> On Tue, 2006-12-05 at 15:00 +0000, Steven Shaw wrote:
> > Oh. I backed the AC_PREREQ to 2.57 and automake requirement to 1.6.3
> > in Makefile.am. From bootstrap I get:
>
> Maybe Jim can help here.
>
> > Thanks for the hand. It's be a few years since I did any serious C/C++
> > development and I didn't have the pleasure of meeting the autotools -
> > not from the dev side anyhow.
>
> I'm new to them also - been living in proprietary software land till
> recently. Thanks for your perseverance, I really want to get this all to
> the point where it Just Works on any reasonably recent linux distro that
> Qpid users are likely to be on.
>
> Cheers,
> Alan
Just FYI: it all fails on a brand new Gentoo x86_64 install.
When I run ./configure:
......
configure: error:
*** [Gentoo] sanity check failed! ***
*** libtool.m4 and ltmain.sh have a version mismatch! ***
*** (libtool.m4 = 1.5.22, ltmain.sh = "1.5.22 Debian 1.5.22-4") ***
Please run:
libtoolize --copy --force
If I then run the libtoolize thing and rerun configure, I get:
.....
checking for APR... configure: error: Package requirements (apr-1 >= 1.2.2)
were not met:
No package 'apr-1' found
Looking through Gentoo stuff, it looks like apr >= 1.0 is hard masked both by
version number and keyword. Thus, it requires a bit of overriding defaults
to get apr-1.2.7 installed. (editing some files in /etc/portage to unmask
it and allow the keyword) Once I got that installed in a new slot, it now
complains about:
checking for APR... yes
checking for CPPUNIT... configure: error: Package requirements (cppunit >=
1.10.2) were not met:
No package 'cppunit' found
I'm stumped on that one as I DO have cppunit installed.
dkulp@dilbert ~/working/qpid/cpp $ cppunit-config --version
1.10.2
dkulp@dilbert ~/working/qpid/cpp $ cppunit-config --libs
-L/usr/lib64 -lcppunit -ldl
and /usr/include/cppunit exists and has a bunch of headers and such.
Any ideas?
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 05/12/06, Alan Conway <ac...@redhat.com> wrote:
> I'm new to them also - been living in proprietary software land till
> recently. Thanks for your perseverance, I really want to get this all to
> the point where it Just Works on any reasonably recent linux distro that
> Qpid users are likely to be on.
Well at home I'm on Ubuntu Edgy so I'll be trying that from time to time.
Re: bootstrap problem
Posted by Jim Meyering <ji...@meyering.net>.
Alan Conway <ac...@redhat.com> wrote:
> On Tue, 2006-12-05 at 15:00 +0000, Steven Shaw wrote:
>> Oh. I backed the AC_PREREQ to 2.57 and automake requirement to 1.6.3
>> in Makefile.am. From bootstrap I get:
>
> Maybe Jim can help here.
>
>> Thanks for the hand. It's be a few years since I did any serious C/C++
>> development and I didn't have the pleasure of meeting the autotools -
>> not from the dev side anyhow.
>
> I'm new to them also - been living in proprietary software land till
> recently. Thanks for your perseverance, I really want to get this all to
> the point where it Just Works on any reasonably recent linux distro that
> Qpid users are likely to be on.
IMHO, the "it" that should `Just Work' is be the distribution tarball
or the per-distro RPM.
Anyone who is working as a developer can be expected to run
./configure --prefix=/somewhere && make && make install
(once for each of the three tools in question), and then adjust
their PATH to include /somewhere/bin at the front.
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 05/12/06, Alan Conway <ac...@redhat.com> wrote:
> On Tue, 2006-12-05 at 15:00 +0000, Steven Shaw wrote:
>
> > Oh. I backed the AC_PREREQ to 2.57 and automake requirement to 1.6.3
> > in Makefile.am. From bootstrap I get:
>
> Maybe Jim can help here.
Well I managed to fix it by reading the error message. I changed the
usage of AC_CONFIG_HEADERS with AM_CONFIG_HEADER. It then complained
about the mkinstalldirs program so I downloaded one and random and
that was it. bootstrap now runs cleanly :D.
Re: bootstrap problem
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2006-12-05 at 15:00 +0000, Steven Shaw wrote:
> Oh. I backed the AC_PREREQ to 2.57 and automake requirement to 1.6.3
> in Makefile.am. From bootstrap I get:
Maybe Jim can help here.
> Thanks for the hand. It's be a few years since I did any serious C/C++
> development and I didn't have the pleasure of meeting the autotools -
> not from the dev side anyhow.
I'm new to them also - been living in proprietary software land till
recently. Thanks for your perseverance, I really want to get this all to
the point where it Just Works on any reasonably recent linux distro that
Qpid users are likely to be on.
Cheers,
Alan
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
s/Oh/Ok/;
:)
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 05/12/06, Alan Conway <ac...@redhat.com> wrote:
> Steve, I did this with the initial patch from 2.60->2.59 can you try it
> with RHEL 3 versions? I changed the AC_PREREQ(2.59) in configure.ac, and
> a couple other things - if you run with the default RHEL 3 tools the
> error messages will tell you what needs changing. If we're lucky it'll
> just work with lower versions. If not, post the errors and we'll try to
> make it work unless there's some showstopper. That would be better than
> requiring a bunch of special versions of the tools to be installed every
> time someone wants to build Qpid.
Oh. I backed the AC_PREREQ to 2.57 and automake requirement to 1.6.3
in Makefile.am. From bootstrap I get:
--begin--
~/build/qpid-trunk/cpp
> ./bootstrap
+ aclocal -I m4
+ autoheader
+ libtoolize --automake
+ : java
+ : javac
+ export JAVA JAVAC
+ test -d ../gentools
+ test -d ../specs
+ cd gen
+ rm -f gen-src.mk
+ perl -ne '/warning:|^(if|else|endif|include)\b/ or print' Makefile.am
+ make -f - srcdir=. gen-src.mk
+ cd tests
+ rm -f gen.mk
+ perl -ne '/^include / or print' Makefile.am
+++ pwd
++ dirname /home/pyramid/r015530/build/qpid-trunk/cpp/tests
+ make -f - abs_srcdir=/home/pyramid/r015530/build/qpid-trunk/cpp gen.mk
+ automake
configure.ac:20: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER'
configure.ac: required file `build-aux/mkinstalldirs' not found
--end--
Thanks for the hand. It's be a few years since I did any serious C/C++
development and I didn't have the pleasure of meeting the autotools -
not from the dev side anyhow.
Cheers,
Steve.
Re: bootstrap problem
Posted by Jim Meyering <ji...@meyering.net>.
Alan Conway <ac...@redhat.com> wrote:
> On Tue, 2006-12-05 at 13:35 +0000, Steven Shaw wrote:
>> I'm trying to build from a fresh checkout on RHEL3. Because the
>> default autoconf version is not support (2.57)
>
> Jim, is there any reason not to downgrade our autoconf requirement to
> 2.57? I'd like this to Just Work on an up-to-date RHEL 3 since JMPC are
> on that platform and they're our only C++ users that I know of to date.
Hi Alan and Steven,
The whole idea of using autoconf, automake, and libtool is to
make the final, configured package portable. The primary goal
is not to make the development environment ultimately portable.
That's just not necessary.
If JPMC are _using_ qpid, then we should try to supply them
with RPMs or tarballs from which to build the required tools.
Those RPMs and tarballs should build on a system with *no* autotools
installed at all.
If someone is doing active development, then they should be able
to install the latest versions of the required tools. I'll be happy
to walk people through it, if some *developer* is having trouble.
Non developers should not need the development tools.
Investing effort in making older versions of autoconf/automake/libtool
work with a newly-autoconfiscated project is counterproductive.
Let's not go there.
> Steve, I did this with the initial patch from 2.60->2.59 can you try it
> with RHEL 3 versions? I changed the AC_PREREQ(2.59) in configure.ac, and
> a couple other things - if you run with the default RHEL 3 tools the
> error messages will tell you what needs changing. If we're lucky it'll
> just work with lower versions. If not, post the errors and we'll try to
> make it work unless there's some showstopper. That would be better than
> requiring a bunch of special versions of the tools to be installed every
> time someone wants to build Qpid.
The goal is to let people build from a distribution tarball or RPM.
Then this won't be an issue.
Re: bootstrap problem
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2006-12-05 at 13:35 +0000, Steven Shaw wrote:
> I'm trying to build from a fresh checkout on RHEL3. Because the
> default autoconf version is not support (2.57)
Jim, is there any reason not to downgrade our autoconf requirement to
2.57? I'd like this to Just Work on an up-to-date RHEL 3 since JMPC are
on that platform and they're our only C++ users that I know of to date.
Steve, I did this with the initial patch from 2.60->2.59 can you try it
with RHEL 3 versions? I changed the AC_PREREQ(2.59) in configure.ac, and
a couple other things - if you run with the default RHEL 3 tools the
error messages will tell you what needs changing. If we're lucky it'll
just work with lower versions. If not, post the errors and we'll try to
make it work unless there's some showstopper. That would be better than
requiring a bunch of special versions of the tools to be installed every
time someone wants to build Qpid.
Cheers,
Alan.
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 06/12/06, Jim Meyering <ji...@meyering.net> wrote:
> Are you sure?
Yes I am certain.
> autoconf, 2.61 is the latest stable release,
I was using the default on RHEL3 which is 2.57.
> but 2.60 should work. Maybe even 2.59, but please don't.
> I've been trying hard to encourage people not to try to push
> the envelope on the dev tools. Just use the latest.
I've now tried RHEL3 with automake-1.10 and autoconf-2.61. No dice.
Back to the libtool error. but I do have a libtool.m4 in my automake
installation.
No to worry. I am giving up generating a ./configure on RHEL3. It is a
waste of time.
I managed to get a ./configure generated on RHEL4 also available here
at JPMC. I had to change the required version of automake back to
1.9.2 (it was 1.9.6).
However, I don't expect that ./configure to enable a build to succeed
on RHEL3 (as I've already tried a ./configure generated under Ubuntu).
Any idea about the linking problem? Maybe it's a libtool version
problem?
> People building from a tarball can expect things to work with
> truly minimal prerequisites, *not* developers running ./bootstrap.
I know. You are singing to the choir.
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 06/12/06, Robert Greig <ro...@gmail.com> wrote:
> However we are able to install whatever versions of the build tools
> are required. Are we happy that we have established a list of versions
> that should all work together?
I think so. IIRC I already have the following installed at the office
automake-1.10 autoconf-2.61 m4-1.48. Forget which version of libtool.
Hopefully all that is required is to rebuild with m4 in the PATH first
and run 'make check'. Should see tomorrow.
Re: bootstrap problem
Posted by Robert Greig <ro...@gmail.com>.
On 06/12/06, Steven Shaw <st...@gmail.com> wrote:
> This whole process has been very frustrating for you and me both. I
> got a build to work today briefly but when I tried again from a fresh
> checkout it was broke because of subsequent patches. It's not my call
> to generate the ./configure on RHEL3 or RHEL4. It's something that
> JPMC want to be able to do in order to be able to build at least a
> qpid-cpp-client distribution (with examples) for an internal team who
> are trying that out. It all worked fine prior to autoconf/automake.
>
> Heck. At home I can now quite happily build qpid-cpp. That's just not
> convenient for the JPMC guys though.
>
> I'll suggest to them that they ought to order a build PC and put Fedora on it.
Well we could do that but we wouldn't be allowed to connect it to the
network, which might cramp our style a bit :-)
However we are able to install whatever versions of the build tools
are required. Are we happy that we have established a list of versions
that should all work together?
RG
Re: bootstrap problem
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> On 06/12/06, Jim Meyering <ji...@meyering.net> wrote:
>> P.S. If you build your own auto* tools, you should be sure to get
>> the latest stable m4 version, 1.4.8, and build and install *it*
>> (and put it first in your path) before building autoconf or automake.
>
> I may not have done that. I did install m4-1.4.something but probably
> not before I built automake/autoconf.
That is the key.
m4 must be installed, and in your path when building autoconf (and
maybe automake, too), otherwise, some of autoconf's machinery won't work
properly. I think you'd see the failure if you run "make check", but
not at configure time.
> You'd expect that the ./configure would fail if it need m4 1.4.8 though, right?
The notes in m4's HACKING file make me think m4-1.4.5 is new enough.
> This whole process has been very frustrating for you and me both. I
> got a build to work today briefly but when I tried again from a fresh
> checkout it was broke because of subsequent patches. It's not my call
> to generate the ./configure on RHEL3 or RHEL4. It's something that
> JPMC want to be able to do in order to be able to build at least a
> qpid-cpp-client distribution (with examples) for an internal team who
> are trying that out. It all worked fine prior to autoconf/automake.
Sorry for the hassle, but rest assured it's for a good cause.
You're just having to endure the get-the-kinks-out phase.
Would another tarball help?
Or even regularly-built/published snapshot tarballs?
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 06/12/06, Jim Meyering <ji...@meyering.net> wrote:
> P.S. If you build your own auto* tools, you should be sure to get
> the latest stable m4 version, 1.4.8, and build and install *it*
> (and put it first in your path) before building autoconf or automake.
I may not have done that. I did install m4-1.4.something but probably
not before I built automake/autoconf.
You'd expect that the ./configure would fail if it need m4 1.4.8 though, right?
This whole process has been very frustrating for you and me both. I
got a build to work today briefly but when I tried again from a fresh
checkout it was broke because of subsequent patches. It's not my call
to generate the ./configure on RHEL3 or RHEL4. It's something that
JPMC want to be able to do in order to be able to build at least a
qpid-cpp-client distribution (with examples) for an internal team who
are trying that out. It all worked fine prior to autoconf/automake.
Heck. At home I can now quite happily build qpid-cpp. That's just not
convenient for the JPMC guys though.
I'll suggest to them that they ought to order a build PC and put Fedora on it.
Re: bootstrap problem
Posted by Jim Meyering <ji...@meyering.net>.
Jim Meyering <ji...@meyering.net> wrote:
> "Steven Shaw" <st...@gmail.com> wrote:
...
>> I have automake-1.10 in my PATH. What are the other "right tools"?
>
> autoconf, 2.61 is the latest stable release,
> but 2.60 should work. Maybe even 2.59, but please don't.
> I've been trying hard to encourage people not to try to push
> the envelope on the dev tools. Just use the latest.
>
> People building from a tarball can expect things to work with
> truly minimal prerequisites, *not* developers running ./bootstrap.
P.S. If you build your own auto* tools, you should be sure to get
the latest stable m4 version, 1.4.8, and build and install *it*
(and put it first in your path) before building autoconf or automake.
Re: bootstrap problem
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> On 06/12/06, Jim Meyering <ji...@meyering.net> wrote:
>> It's probably one of these:
>> - improper installation of autoconf or automake
>> - autom4te directory created by some other version of tools
>>
>> You're not the first to get that diagnostic:
>>
>> http://sources.redhat.com/ml/bug-automake/2004/msg00183.html
>>
>> First try removing autom4te/.
>
> This was on a fresh checkout.
Are you sure?
With a fresh checkout (i.e., no preexisting autom4te*/ dir),
if you run aclocal -I m4, you get that error?
>> If that doesn't work, see if you have the right tools early in your path.
>
> I have automake-1.10 in my PATH. What are the other "right tools"?
autoconf, 2.61 is the latest stable release,
but 2.60 should work. Maybe even 2.59, but please don't.
I've been trying hard to encourage people not to try to push
the envelope on the dev tools. Just use the latest.
People building from a tarball can expect things to work with
truly minimal prerequisites, *not* developers running ./bootstrap.
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 06/12/06, Jim Meyering <ji...@meyering.net> wrote:
> It's probably one of these:
> - improper installation of autoconf or automake
> - autom4te directory created by some other version of tools
>
> You're not the first to get that diagnostic:
>
> http://sources.redhat.com/ml/bug-automake/2004/msg00183.html
>
> First try removing autom4te/.
This was on a fresh checkout.
> If that doesn't work, see if you have the right tools early in your path.
I have automake-1.10 in my PATH. What are the other "right tools"?
At this point I'm only running aclocal after all...
Note that I'm also trying the ./configure that I generated at home on
Ubuntu Edgy but I'm getting the same link error as yesterday when I
fixed it so that autoconf/automake would run on RHEL3 by making a
couple of small changes to configure.ac and Makefile.am.
Cheers,
Steve.
Re: bootstrap problem
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> With automake-1.10 on RHEL3:
>
> $ ./bootstrap
> autom4te: unknown language: Autoconf-without-aclocal-m4
> aclocal: autom4te failed with exit status: 1
>
> $ automake --version
> automake (GNU automake) 1.10
> Written by Tom Tromey <tr...@redhat.com>
> and Alexandre Duret-Lutz <ad...@gnu.org>.
>
> Copyright 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
It's probably one of these:
- improper installation of autoconf or automake
- autom4te directory created by some other version of tools
You're not the first to get that diagnostic:
http://sources.redhat.com/ml/bug-automake/2004/msg00183.html
First try removing autom4te/.
If that doesn't work, see if you have the right tools early in your path.
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
With automake-1.10 on RHEL3:
$ ./bootstrap
autom4te: unknown language: Autoconf-without-aclocal-m4
aclocal: autom4te failed with exit status: 1
$ automake --version
automake (GNU automake) 1.10
Written by Tom Tromey <tr...@redhat.com>
and Alexandre Duret-Lutz <ad...@gnu.org>.
Copyright 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 05/12/06, Jim Meyering <ji...@meyering.net> wrote:
> > I'll try with automake 1.10 and see if it works with the latest stable
> > autotools.
>
> Good! :-)
I will still try tomorrow on rhel3 with automake-1.10 but the good
news is that it now works at home on Ubuntu Edgy with the following
versions:
autoconf (GNU Autoconf) 2.60
automake (GNU automake) 1.9.6
GNU M4 1.4.4
ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365
2005/12/18 22:14:06)
Cheers,
Steve.
Re: bootstrap problem
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
...
>> It is defined by configure.
>> The actual value it gets set to can be seen in lib/common/Makefile.
>> For me it's empty because I turned it off:
>>
>> $ grep APR_LIBS.= lib/common/Makefile
>> APR_LIBS =
>
> Well it's not for me:
>
> $ grep APR_LIBS lib/common/Makefile
> $(APR_LIBS) \
>
> Maybe it's because I'm using these old autotools version.
Exactly. And why I encouraged you to upgrade.
> Tomorrow
> I'll try with automake 1.10 and see if it works with the latest stable
> autotools.
Good! :-)
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 05/12/06, Jim Meyering <ji...@meyering.net> wrote:
> I've tried to explain that there is no point in trying to make
> the bootstrap procedure work for older build environments.
> In fact, doing so would be seriously counterproductive.
I understand that point of view.
It didn't seem to couterproductive though as it hasn't been working
for me on Ubuntu Edgy or on RHEL3. By making a couple of small changes
I have ./bootstap running without error. Now it's just a matter of
figuring out why the APR libraries aren't included in the link
commands!
For what it's worth my original plan had been to build the ./configure
at home on Ubuntu Edgy and email the ./configure script into work to
run on rhel3. That didn't work out because ./bootstrap failed on
Ubuntu Edgy.
> Where did you look? There may well be a page that needs to be updated.
http://www.gnu.org/software/automake/
> FYI, the http://www.gnu.org/software/automake/ page does say
> "See the GNU Automake home page", which is a link to the above URL.
Hah well I didn't noticed that. It didn't say click here to find out
what the stable version is.
> But nothing in lib/client should need libapr.
> libapr should be been linked into the `common' shared library.
Maybe it's not working.
> It is defined by configure.
> The actual value it gets set to can be seen in lib/common/Makefile.
> For me it's empty because I turned it off:
>
> $ grep APR_LIBS.= lib/common/Makefile
> APR_LIBS =
>
Well it's not for me:
$ grep APR_LIBS lib/common/Makefile
$(APR_LIBS) \
Maybe it's because I'm using these old autotools version. Tomorrow
I'll try with automake 1.10 and see if it works with the latest stable
autotools.
Cheers,
Steve.
Re: bootstrap problem
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> On 05/12/06, Jim Meyering <ji...@meyering.net> wrote:
>> Thanks. I did see it. ISTR that one problem is you switched
>> from an AC_ macro to a now-deprecated AM_ one. Support for deprecated
>> bits will likely be phased out in upcoming releases. So it's best not to
>> use them in new projects.
>
> Yes I did do that. That's what the error message told me to do. Alan
> had suggested that I try getting it working with standard tools on
> RHEL3.
I've tried to explain that there is no point in trying to make
the bootstrap procedure work for older build environments.
In fact, doing so would be seriously counterproductive.
>> Remember that people using such packages are typically encouraged
>> to start with an RPM or a tarball. That you're using development
>> tools implies you are more, um... adventurous, progressive, etc.,
>> at least on the build-tools front.
>
> Yeah I remember
>
>> That's why I suggested you get the latest stable version of automake.
>
> Well I could do that but it seems to be working already. Are you sure
> automake 1.10 is the latest stable?
Yes.
> As I said, the GNU Automake site doesn't say so I was left to pick my
> own version...
Where did you look? There may well be a page that needs to be updated.
This is the home page:
http://sources.redhat.com/automake/
It says:
The latest released version of Automake is 1.10 and it can be found
on ftp.gnu.org and its mirrors.
Here's the link:
ftp://ftp.gnu.org/gnu/automake/automake-1.10.tar.bz2
FYI, the http://www.gnu.org/software/automake/ page does say
"See the GNU Automake home page", which is a link to the above URL.
>> > It seems that libapr-1 isn't included as a link parameter for the tests.
>> >
>> > I've tried greping through the Makefiles and whatnot but can only find
>> > something about setting up the APR CXX flags... no the libs...
>>
>> It's in client/Makefile.am: Look for APR_LIBS.
>
> APR_LIBS does seem to be used in lib/common/Makefile.am
> It's not there in lib/client/Makefile.am
But nothing in lib/client should need libapr.
libapr should be been linked into the `common' shared library.
> In addition, APR_LIBS doesn't appear to be defined anywhere.
It is defined by configure.
The actual value it gets set to can be seen in lib/common/Makefile.
For me it's empty because I turned it off:
$ grep APR_LIBS.= lib/common/Makefile
APR_LIBS =
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 05/12/06, Jim Meyering <ji...@meyering.net> wrote:
> Thanks. I did see it. ISTR that one problem is you switched
> from an AC_ macro to a now-deprecated AM_ one. Support for deprecated
> bits will likely be phased out in upcoming releases. So it's best not to
> use them in new projects.
Yes I did do that. That's what the error message told me to do. Alan
had suggested that I try getting it working with standard tools on
RHEL3.
> Remember that people using such packages are typically encouraged
> to start with an RPM or a tarball. That you're using development
> tools implies you are more, um... adventurous, progressive, etc.,
> at least on the build-tools front.
Yeah I remember
> That's why I suggested you get the latest stable version of automake.
Well I could do that but it seems to be working already. Are you sure
automake 1.10 is the latest stable?
As I said, the GNU Automake site doesn't say so I was left to pick my
own version...
> > It seems that libapr-1 isn't included as a link parameter for the tests.
> >
> > I've tried greping through the Makefiles and whatnot but can only find
> > something about setting up the APR CXX flags... no the libs...
>
> It's in client/Makefile.am: Look for APR_LIBS.
APR_LIBS does seem to be used in lib/common/Makefile.am
It's not there in lib/client/Makefile.am
In addition, APR_LIBS doesn't appear to be defined anywhere.
Steve.
Re: bootstrap problem
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> On 05/12/06, Jim Meyering <ji...@meyering.net> wrote:
>> Well, would you please try with the newer version: automake-1.10?
>> I'd rather not debug a problem if it's already been fixed in the latest.
>
> Thing is that I got it bootstrap working using standard RHEL3
> versions. I just had to change a couple of files. You might have
> missed my earlier email about that.
Thanks. I did see it. ISTR that one problem is you switched
from an AC_ macro to a now-deprecated AM_ one. Support for deprecated
bits will likely be phased out in upcoming releases. So it's best not to
use them in new projects.
Remember that people using such packages are typically encouraged
to start with an RPM or a tarball. That you're using development
tools implies you are more, um... adventurous, progressive, etc.,
at least on the build-tools front.
That's why I suggested you get the latest stable version of automake.
...
> It seems that libapr-1 isn't included as a link parameter for the tests.
>
> I've tried greping through the Makefiles and whatnot but can only find
> something about setting up the APR CXX flags... no the libs...
It's in client/Makefile.am: Look for APR_LIBS.
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 05/12/06, Jim Meyering <ji...@meyering.net> wrote:
> Well, would you please try with the newer version: automake-1.10?
> I'd rather not debug a problem if it's already been fixed in the latest.
Thing is that I got it bootstrap working using standard RHEL3
versions. I just had to change a couple of files. You might have
missed my earlier email about that.
However, the make is failing with:
--begin
make[2]: Entering directory `/home/pyramid/r015530/build/qpid-trunk/cpp/tests'
/bin/sh ../libtool --mode=link g++ -Werror -pedantic -Wall -Wno-shadow
-Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long
-Wno-system-headers
-I/home/pyramid/r015530/local/cppunit-1.11.6/include
-I/home/pyramid/r015530/local/boost-1.33.1/include/boost-1_33_1 -o
client_test client_test.o
/home/pyramid/r015530/build/qpid-trunk/cpp/tests/../lib/client/libclient.la
/home/pyramid/r015530/build/qpid-trunk/cpp/tests/../lib/common/libcommon.la
g++ -Werror -pedantic -Wall -Wno-shadow -Wpointer-arith -Wcast-qual
-Wcast-align -Wno-long-long -Wno-system-headers
-I/home/pyramid/r015530/local/cppunit-1.11.6/include
-I/home/pyramid/r015530/local/boost-1.33.1/include/boost-1_33_1 -o
.libs/client_test client_test.o
/home/pyramid/r015530/build/qpid-trunk/cpp/tests/../lib/client/.libs/libclient.so
/home/pyramid/r015530/build/qpid-trunk/cpp/tests/../lib/common/.libs/libcommon.so
-ldl -lrt -Wl,--rpath -Wl,/home/pyramid/r015530/local/qpid-trunk/lib
client_test.o(.text+0x389): In function `main':
../lib/common/sys/Mutex.h:74: undefined reference to `apr_thread_mutex_create'
client_test.o(.text+0x3b6): In function `main':
../lib/common/sys/Monitor.h:63: undefined reference to `apr_thread_cond_create'
client_test.o(.text+0x51b): In function `main':
../lib/common/sys/Mutex.h:82: undefined reference to `apr_thread_mutex_lock'
client_test.o(.text+0x541): In function `main':
../lib/common/sys/Monitor.h:71: undefined reference to `apr_thread_cond_wait'
client_test.o(.text+0x561):../lib/common/sys/Monitor.h:71: undefined
reference to `apr_thread_mutex_unlock'
client_test.o(.text+0x63d):../lib/common/sys/Monitor.h:67: undefined
reference to `apr_thread_cond_destroy'
client_test.o(.text+0x65a): In function `main':
../lib/common/sys/Mutex.h:78: undefined reference to `apr_thread_mutex_destroy'
client_test.o(.text+0xbdd):../lib/common/sys/Mutex.h:78: undefined
reference to `apr_thread_mutex_destroy'
--end--
It seems that libapr-1 isn't included as a link parameter for the tests.
I've tried greping through the Makefiles and whatnot but can only find
something about setting up the APR CXX flags... no the libs...
Re: bootstrap problem
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> On 05/12/06, Jim Meyering <ji...@meyering.net> wrote:
>> This is the same aclocal problem you saw before.
>> perhaps your path is not set right (so you're running
>> some other version of aclocal), or maybe the libtool.am file
>> is installed in the wrong place.
>
> I can assure you that my PATH was set up right. If libtool.am was in
> the wrong place it was the fault of the automake's 'make install' as I
> installed from source. I'm not using yum as this is not my box. I'm
> just doing builds for another development team using RHEL3.
>
> Qpid developers here are generally using RHEL4. I prefer Ubuntu Edgy :).
>
>> BTW, if you're installing your own version of automake,
>> why don't you use automake-1.10?
>
> Well
>
> http://www.gnu.org/software/automake/
>
> didn't specify the stable version so I just downloaded one at "random"
> ;). Actually I Googled up some other page listing versions of libtool
> automake and autoconf and installed those versions. I wanted them to
> all work togther.
Well, would you please try with the newer version: automake-1.10?
I'd rather not debug a problem if it's already been fixed in the latest.
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
On 05/12/06, Jim Meyering <ji...@meyering.net> wrote:
> This is the same aclocal problem you saw before.
> perhaps your path is not set right (so you're running
> some other version of aclocal), or maybe the libtool.am file
> is installed in the wrong place.
I can assure you that my PATH was set up right. If libtool.am was in
the wrong place it was the fault of the automake's 'make install' as I
installed from source. I'm not using yum as this is not my box. I'm
just doing builds for another development team using RHEL3.
Qpid developers here are generally using RHEL4. I prefer Ubuntu Edgy :).
> BTW, if you're installing your own version of automake,
> why don't you use automake-1.10?
Well
http://www.gnu.org/software/automake/
didn't specify the stable version so I just downloaded one at "random"
;). Actually I Googled up some other page listing versions of libtool
automake and autoconf and installed those versions. I wanted them to
all work togther.
Steve.
Re: bootstrap problem
Posted by Jim Meyering <ji...@meyering.net>.
"Steven Shaw" <st...@gmail.com> wrote:
> I'm trying to build from a fresh checkout on RHEL3. Because the
> default autoconf version is not support (2.57), I've installed the
> following:
>
> autoconf-2.61
> automake-1.9.6
> libtool-1.5.22
> m4-1.4.8
>
> I've locally added the "set -x" to bootstrap to make it clearer where
> the problems are coming from. I'm having a similar problem to what I
> was getting at home:
>
> ---begin---
...
> + automake
> lib/broker/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined
...
> ---end---
>
> Note that this version of automake does include the libtool.am file
>
> ~/local/automake-1.9.6/share/automake-1.9/am/libtool.am
>
> Any pointers would be appreciated.
This is the same aclocal problem you saw before.
perhaps your path is not set right (so you're running
some other version of aclocal), or maybe the libtool.am file
is installed in the wrong place.
The bottom line is that when aclocal runs, the AC_PROG_LIBTOOL
macro is not being put into aclocal.m4.
Try running aclocal in verbose mode:
Here's what I get:
/usr/bin/aclocal --verbose -I m4 2>&1 | grep AC_PROG_LIBTOOL|head -n2
aclocal: found macro AC_PROG_LIBTOOL in /usr/share/aclocal/libtool.m4: 25
aclocal: found macro _AC_PROG_LIBTOOL in /usr/share/aclocal/libtool.m4: 60
BTW, if you're installing your own version of automake,
why don't you use automake-1.10?
Re: bootstrap problem
Posted by Steven Shaw <st...@gmail.com>.
I'm trying to build from a fresh checkout on RHEL3. Because the
default autoconf version is not support (2.57), I've installed the
following:
autoconf-2.61
automake-1.9.6
libtool-1.5.22
m4-1.4.8
I've locally added the "set -x" to bootstrap to make it clearer where
the problems are coming from. I'm having a similar problem to what I
was getting at home:
---begin---
$ ./bootstrap
+ aclocal -I m4
+ autoheader
+ libtoolize --automake
+ : java
+ : javac
+ export JAVA JAVAC
+ test -d ../gentools
+ test -d ../specs
+ cd gen
+ rm -f gen-src.mk
+ perl -ne '/warning:|^(if|else|endif|include)\b/ or print' Makefile.am
+ make -f - srcdir=. gen-src.mk
+ cd tests
+ rm -f gen.mk
+ perl -ne '/^include / or print' Makefile.am
+++ pwd
++ dirname /home/pyramid/r015530/build/qpid-trunk/cpp/tests
+ make -f - abs_srcdir=/home/pyramid/r015530/build/qpid-trunk/cpp gen.mk
+ automake
lib/broker/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined
lib/broker/Makefile.am:9:
lib/broker/Makefile.am:9: The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
lib/broker/Makefile.am:9: to `configure.ac' and run `aclocal' and
`autoconf' again.
lib/client/Makefile.am:9: Libtool library used but `LIBTOOL' is undefined
lib/client/Makefile.am:9:
lib/client/Makefile.am:9: The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
lib/client/Makefile.am:9: to `configure.ac' and run `aclocal' and
`autoconf' again.
lib/common/Makefile.am:43: Libtool library used but `LIBTOOL' is undefined
lib/common/Makefile.am:43:
lib/common/Makefile.am:43: The usual way to define `LIBTOOL' is to add
`AC_PROG_LIBTOOL'
lib/common/Makefile.am:43: to `configure.ac' and run `aclocal' and
`autoconf' again.
tests/gen.mk:93: Libtool library used but `LIBTOOL' is undefined
tests/gen.mk:93:
tests/gen.mk:93: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL'
tests/gen.mk:93: to `configure.ac' and run `aclocal' and `autoconf' again.
tests/Makefile.am:78: `tests/gen.mk' included from here
---end---
Note that this version of automake does include the libtool.am file
~/local/automake-1.9.6/share/automake-1.9/am/libtool.am
Any pointers would be appreciated.
Cheers,
Steve.
Re: bootstrap problem
Posted by Gordon Sim <gs...@redhat.com>.
Jim Meyering wrote:
> Ahh... "in a fresh checkout". Now I see. Sorry it took so long.
> Steven, this ought to solve your problem, too.
> Here's a patch for that, along with a small fix for gen/Makefile.am:
>
> 2006-12-05 Jim Meyering <me...@redhat.com>
>
> * gen/Makefile.am (timestamp): Remove unnecessary "; \",
> that could have obscured a failure.
> (gen-src.mk): Use echo 'var = '\\, rather than 'var = \'.
> Both work, but emacs' font-lock mode mishandles the latter.
>
> * bootstrap: Give JAVA and JAVAC default values, and export them.
> Don't define abs_srcdir; no longer needed.
> Also filter out gen/Makefile.am's echo warning: ...
> Add comments.
>
> Index: gen/Makefile.am
> ===================================================================
> --- gen/Makefile.am (revision 482368)
> +++ gen/Makefile.am (working copy)
> @@ -15,9 +15,9 @@
> timestamp: $(spec) $(java_sources) $(cxx_templates)
> if BUILD_IN_MESSAGE_TREE
> rm -f $(generated_sources)
> - (cd $(gentools_srcdir) && rm -f *.class && $(JAVAC) *.java); \
> - $(JAVA) -cp $(gentools_dir)/src org.apache.qpid.gentools.Main \
> - -c -o . -t $(gentools_dir)/templ.cpp $(spec)
> + cd $(gentools_srcdir) && rm -f *.class && $(JAVAC) *.java
> + $(JAVA) -cp $(gentools_dir)/src org.apache.qpid.gentools.Main \
> + -c -o . -t $(gentools_dir)/templ.cpp $(spec)
> else
> echo "warning: failed to regenerate gen/*.{cpp,h}" 1>&2
> endif
> @@ -28,15 +28,15 @@
>
> DISTCLEANFILES = gen-src.mk
> gen-src.mk: timestamp
> - ( echo 'generated_sources = \' \
> + ( echo 'generated_sources = '\\ \
> && ls *.cpp *.h | sort -u | sed 's/.*/ & \\/;$$s/ \\//' \
> ) > $@-t
> if BUILD_IN_MESSAGE_TREE
> ( echo if BUILD_IN_MESSAGE_TREE; \
> - echo 'java_sources = \' \
> + echo 'java_sources = '\\ \
> && find $(gentools_srcdir) -name '*.java' \
> | sort -u | sed 's/.*/ & \\/;$$s/ \\//'; \
> - echo 'cxx_templates = \' \
> + echo 'cxx_templates = '\\ \
> && find $(gentools_dir)/templ.cpp -name '*.tmpl' \
> | sort -u | sed 's/.*/ & \\/;$$s/ \\//'; \
> echo endif \
> Index: bootstrap
> ===================================================================
> --- bootstrap (revision 482368)
> +++ bootstrap (working copy)
> @@ -4,13 +4,22 @@
> autoheader
> libtoolize --automake
>
> +# These are needed only if you don't already have the gen/*.{h,cpp} files.
> +: ${JAVA=java}
> +: ${JAVAC=javac}
> +export JAVA JAVAC
> +
> # If we're building in the qpid tree, we can generate
> # some Makefile snippets:
>
> if test -d ../gentools && test -d ../specs; then
> + # Transform gen/Makefile.am, removing automake-constructs and the
> + # contents of the sole automake-else clause (the warning), then
> + # use the result to run the rules that create gen-src.mk, a file
> + # that must be created before we run automake.
> (cd gen && rm -f gen-src.mk
> - perl -ne '/^(abs_srcdir|if|else|endif|include)\b/ or print' Makefile.am \
> - | make -f - abs_srcdir=`pwd` srcdir=. gen-src.mk > /dev/null )
> + perl -ne '/warning:|^(if|else|endif|include)\b/ or print' Makefile.am \
> + | make -f - srcdir=. gen-src.mk > /dev/null )
> fi
>
> # Generate (for automake) lots of repetitive parts of tests/Makefile.am.
Applied as rev 482637.