Build failed because autoconf 2.62 man file not found about build-couchdb HOT 33 OPEN

same problem:
stderr: http://pastebin.com/yT9ckhjh
stdout: http://pastebin.com/rmWeuDYX

Fedora 16.

from build-couchdb.

Same here, several file's in the autoconf-2.62/man/ weren't found, all following the $filename{,.t} pattern. I copied those 5 files manually after which the rake was able to continue.

Ubuntu 11.10 i386

from build-couchdb.

Also got same error.
Ubuntu 10.10 i386

According above, copied error files manually like:
cp dependencies/autoconf-2.62/man/config.sub.1 dependencies/autoconf-2.62/man/config.sub.1.t
...
Rake continues.

from build-couchdb.

Interesting. I am on Ubuntu 10.04 LTS and it's working. It looks like you all may be using a newer autoconf than me. I will test on a VM.

@kika, I am concerned that you are building from a dirty (modified) checkout. Stuff in dependencies/* that uses autotools (curl, the auto* stuff, etc.) should never be modified. Rake should be making a temporary directory where the configure and build output goes.

What happens when you build from a clean checkout? If you are not familiar with Git, you can simply move the old checkout somewhere, or delete it entirely. Then clone things fresh.

Thanks, everybody, for your feedback. This project has grown past the phase where we can all build from master. I will begin tagging it with builds known to be highly bug-free, and I also created issue #27 so people can build from a tarball instead of the additional complexity that Git creates.

from build-couchdb.

@jhs, I'm building completely from scratch.

from build-couchdb.

Building from scratch here too. Git is great, just seems like some dependency is misbehaving. It's not even critical, just man file(s).

from build-couchdb.

same here, building from scratch on ubuntu 11.10. I had to run the following commands before it worked successfully:

cp dependencies/autoconf-2.62/man/config.sub.1{,.t}
cp dependencies/autoconf-2.62/man/autoconf.1{,.t}
cp dependencies/autoconf-2.62/man/autoheader.1{,.t}

from build-couchdb.

@adebree, @gfxmonk, @bohongjian:

I just installed a pristine Ubuntu 11.10 and the build from the master branch ran with no errors. Would you please update and let me know if you still have this issue. In the meantime I will check the build logs and see if there is a clue.

If the build still works, please let me know the output of dpkg --list. Thanks.

from build-couchdb.

also line:

cp dependencies/autoconf-2.62/man/autom4te.1{,.t}

was necessary for me after "gfxmonk" commands

(centos 6.2)

from build-couchdb.

Would you please make a completely clean clone, and run rake and
post the rake.log file to pastebin or gist? That would help
tremendously! I noticed some discrepancies with mine and some of
others' logs. Also the output of dpkg --list would help. Thanks.

On Fri, Feb 17, 2012 at 9:43 PM, jkubos
[email protected]
wrote:

also line:

cp dependencies/autoconf-2.62/man/autom4te.1{,.t}

was necessary for me on top of "gfxmonk" commands

---

Reply to this email directly or view it on GitHub:
#25 (comment)

Iris Couch

from build-couchdb.

Hi jhs,

I tried to reproduce (clean clone, ...) yesterdays behaviour, but today it works. Even with un-installed make (I mean - there appears the second error I replied yesterday). I think I reproduced steps correctly.

Here is list of my packages: https://gist.github.com/1857935

Unfortunately I don't have yesterdays rake.log. Btw. I used "rake install=/opt/couchdb".

Jarek

from build-couchdb.

@jkubos Thanks. That was my suspicion. It is now working for some reason. I think it could be possibly.

1. The distros were shipping something buggy in the toolchain which is now fixed (least likely)
2. I fixed it by accident in the last few eeks (more likely)
3. The bug remains but it is tricky to reproduce (most likely)

I am installing Fedora 16 to try to get it happening there. Otherwise, enjoy the Couch!

from build-couchdb.

@jhs still getting it, on a fresh checkout, with all packages up to date (ubuntu 11.10).

Here's my output: https://gist.github.com/1861925

I honestly have no idea why it claims that stuff has been modified up the top of rake.log, I ran the instructions as specified (clone; submodule init; submodule update) and did not modify any files after that.

from build-couchdb.

@gfxmonk I wonder if it is this: http://help.github.com/line-endings/

Do you get any output to the command: git config --global core.autocrlf true?

In the meantime I will investigate if those files have the wrong line endings. Hopefully that is triggering Make to try to rebuild from them or something and producing this error.

from build-couchdb.

@jhs I didn't get any output from that. Does that command set it globally? (I didn't used to have it set to anything).

From the sounds of that github page, I don't want it, so I've removed it from my ~/.gitconfig. Does build-couchdb need it, and if so is there a less invasive way to do so?

If you're curious as to my changes (note that I did not change anything myself, so these must have been made by the build), here's the output of git status after the build that I posted the rake.log for:

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   dependencies/autoconf-2.59/configure
#   modified:   dependencies/autoconf-2.62/configure
#   deleted:    dependencies/autoconf-2.62/doc/autoconf.info
#   modified:   dependencies/autoconf-2.62/doc/stamp-vti
#   deleted:    dependencies/autoconf-2.62/doc/standards.info
#   modified:   dependencies/autoconf-2.62/doc/version.texi
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   dependencies/autoconf-2.59/autom4te.cache/
#   dependencies/autoconf-2.62/autom4te.cache/
#   dependencies/autoconf-2.62/man/autoconf.1a.t
no changes added to commit (use "git add" and/or "git commit -a")

from build-couchdb.

Yes, I had never even heard of that feature until just now. It sounds like trouble to me but I'm sure there's some reason for it. Anyway, I've never tested build-couchdb in that scenario.

Let's push forward. Would you please delete the autom4te.cache files, and autoconf.la.t (the untracked files) and run git reset --hard. Let's try a build from the situation where git status says there are no changes whatsoever. I am unsure if that will fix it but either way, that will be a clue (maybe the newline thing is a red herring).

Thanks for your help on this bug!

from build-couchdb.

okay, reset and clean -fdx, git status shows no changes. After a rake, I have status:

#   deleted:    dependencies/autoconf-2.62/doc/autoconf.info
#
# Untracked files:
#
#   dependencies/autoconf-2.62/man/autoconf.1a.t

I've updated the above gist with the new rake.log ( https://raw.github.com/gist/1861925/9d173a67f0fb422b3d9d40c362a298bd6cfb6bf6/rake.log )

from build-couchdb.

I think there are two bugs. One is that build-couchdb is not cleaning up correctly after a failed build. But then there is the deeper bug. I am pretty sure I was able to reproduce this on Fedora 16, so hopefully it is a matter of time. I am optimistic that the fix will work on Ubuntu too. In the meantime, do I have your most recent rake.log output? (I'm beginning to lose track, sorry.)

from build-couchdb.

I had to add

cp dependencies/autoconf-2.62/man/autoreconf.1{,.t}
cp dependencies/autoconf-2.62/man/autoscan.1{,.t}

to the previously listed copy commands to get the build to run on CentOS 6.2

from build-couchdb.

Ahh good, hopefully you can find the underlying reason. Yep, the gist I've linked to above has my most recent rake.log (I've only made one gist, the original rake.log is tucked away in a previous revision of that gist).

from build-couchdb.

@gfxmonk would you please clean up your checkout (or do a fresh clone) and try from the latest master branch. The last commit I made enables me to build on my F16 machine and I am optimistic that it will fix Ubuntu too. (It may have broken Fedora 13 but I'll deal with that later if ever.)

If it works, I would like to close this ticket. At any rate, I have a pretty good idea what is wrong (some faux-commands that build-couchdb made to trick autotools).

Thanks very much for your persistence and patience!

from build-couchdb.

@jhs looks like it may now be hitting crlf issues, not sure if that's before or after it used to fail. I've updated my rake.log on the gist:
https://gist.github.com/1861925

Not sure if you can see it easily there, but the end of the log has lots of lines saying "^M: not found" just before it fails, and the syntax error it mentions is in dependencies/spidermonkey/js/src/configure, on a line that looks like

some_variable=^M

I tried setting the autocrlf to true as you mentioned, but I'm not sure exactly how to get that to do anything - it didn't change the configure file mentioned above, for example.

from build-couchdb.

I think I copied and pasted the wrong thing. I was hoping to disable autocrlf. It seems like nothing but trouble to me. The objective is to run git status and there are no changes before a build.

It seems like crlf was a red herring but I expect once we can get back to normal you will find that the bug is fixed.

from build-couchdb.

ahh. I didn't have autocrlf on in the first place when running the latest build, I only enabled it after the build failed with mentioning ^M stuff, and it didn't seem to do anything. Git status shows a clean checkout, so perhaps that file is checked in with the wrong line endings?

Not sure if I should start a different issue for this, as it's diverging from the original problem and it sounds like you've fixed the autoconf one...

from build-couchdb.

Well, I like the momentum we have. Have you tried just blowing it completely away and doing a fresh git clone and git submodule update --init --recursive? If that doesn't work then yeah let's make a new ticket about the newline thing. I'm unsure if it's checked in wrong because, firstly, I have it building on several different (Linux) systems, but also those files have not changed in a while (especially the Javascript stuff) so I'm not certain what's going on yet.

from build-couchdb.

Hmm, seems to be a fresh problem each day. I just cleaned everything out and re-cloned, and now I'm getting something completely different:

/home/tim/dev/web/couchdb/build-couchdb/head/dependencies/autoconf-2.62/build-aux/missing: line 52: help2man: command not found
WARNING: `help2man' is missing on your system.  You should only need it if
     you modified a dependency of a manual page.  You may need the
     `Help2man' package in order for those modifications to take
     effect.  You can get `Help2man' from any GNU archive site.
make[2]: *** [/home/tim/dev/web/couchdb/build-couchdb/head/dependencies/autoconf-2.62/man/config.guess.1] Error 1
make[2]: Leaving directory `/tmp/autoconf-2.62_build20120221-6111-1xpdms3/man'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/autoconf-2.62_build20120221-6111-1xpdms3'
make: *** [all] Error 2
rake aborted!
Command failed with status (2): [make ...]

Not sure if help2man is really a dependency, or if it's trying to rebuild something it shouldn't. Full rake.log updated in the gist ( https://gist.github.com/gists/1861925 ).

from build-couchdb.

No that's progress! Please run apt-get install help2man and let me know if it works. If so, the easiest thing might be to simply add that to the dependencies.

from build-couchdb.

btw. help2man is missing also on my centos 6.2

from build-couchdb.

@jkubos Does the build work if you yum install it? Thanks!

from build-couchdb.

It works for me even without this package...can it be that something is pre-processed in sources and re-process is required just under random conditions during build?

from build-couchdb.

Oh, yes, it works for me too (on Fedora 16). I think there is a bug somewhere with the build's handling of a missing help2man program. The original bug which I think I fixed is that build-couchdb actually made a faux help2man but now it looks like autoconf 2.62 is expecting that program to actually output a file. Thus I removed this papering over but now there is the hard work of making it work on every platform.

However, if a help2man is actually installed, then maybe autoconf will simply use it and build what it needs.

from build-couchdb.

warning is properly printed: https://gist.github.com/1876798

after installation of 'help2man', build proceed completely

from build-couchdb.

installed help2man, build succeeded! (after a clean) Cheers for chasing that down :)

from build-couchdb.