Summary: | sys-devel/autogen-5.10* fails building documentation when no autogen is installed (test: too many arguments) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Maciej Piechotka <uzytkownik2> |
Component: | New packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | bkorb, brant, dabbott, hwoarang, jackdachef, kyron, pchrist, pva, tom.lane0, vikraman, zeev.tarantov |
Priority: | High | ||
Version: | 2008.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 335703 | ||
Bug Blocks: | |||
Attachments: |
full build log
emerge sys-devel/autogen-5.10.1 |
Description
Maciej Piechotka
2010-04-25 21:04:33 UTC
Chances are this is another incompatibility with gcc 4.5 - the changes of handling missing headers in C family. Please attach a complete build log. Created attachment 229579 [details]
full build log
I tried to reproduce this error, and I confirm it. It affects both =autogen-5.10.1 and =autogen-5.10.2_pre1 versions. The stable 5.9.7 version can be emerged flawlessly. I believe that it didn't affect people who had already installed a previous version of autogen because autoopts/options.h already existed for them in /usr/include/autoopts/options.h (eg. if you emerge 5.9.7 and try to reemerge a 5.10* version, it won't fail) Created attachment 230653 [details]
emerge sys-devel/autogen-5.10.1
Confirm.
bug #318833 is a duplicate of this one... PS: thanks for the info about how to get it to work *** Bug 318833 has been marked as a duplicate of this bug. *** *** Bug 321381 has been marked as a duplicate of this bug. *** CC'ing upstream. Guys could you check if 5.10.2 works for you? built fine for me: emerge --info Portage 2.2_rc67 (default/linux/amd64/10.0/desktop, gcc-4.5.0, glibc-2.11.2-r0, 2.6.34-zen2 x86_64) ================================================================= System uname: Linux-2.6.34-zen2-x86_64-Intel-R-_Core-TM-_i7_CPU_860_@_2.80GHz-with-gentoo-2.0.1 Timestamp of tree: Tue, 29 Jun 2010 13:15:01 +0000 app-shells/bash: 4.1_p7 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r2, 3.1.2-r3 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.1-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.4_p6-r1, 1.5-r1, 1.6.3-r1, 1.7.9-r2, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.18-r3, 2.20.1, 2.20.51.0.8, 2.20.51.0.9 sys-devel/gcc: 4.3.4, 4.4.3-r3, 4.4.4-r2, 4.5.0 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 virtual/os-headers: 2.6.34 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* @EULA skype-eula PUEL dlj-1.1 sun-bcla-java-vm googleearth AdobeFlash-10" CBUILD="x86_64-pc-linux-gnu" thanks ! Needs re-titling the bug because the first error is likely the real cause. I'll look into this some more when I get home. The problem is on line 300 of auto-opts.tpl. Full context: + /var/tmp/paludis/sys-devel-autogen-5.10.1/work/autogen-5.10.1/agen5/autogen --base=agdoc -t60 -L/var/tmp/paludis/sys-devel-autogen-5.10.1/work/autogen-5.10.1/doc -L/var/tmp/paludis/sys-devel-autogen-5.10.1/work/autogen-5.10.1 -L/var/tmp/paludis/sys-devel-autogen-5.10.1/work/autogen-5.10.1/autoopts /var/tmp/paludis/sys-devel-autogen-5.10.1/work/autogen-5.10.1/doc/ag-texi-9256.d/agdoc.def /bin/sh: line 3092: test: too many arguments hello.c:8:30: fatal error: autoopts/options.h: No such file or directory compilation terminated. Killing AutoGen: cannot compile hello AutoGen aborting on signal 15 (Terminated) in state EMITTING processing template auto-opts.tpl on line 300 for function EXPR (12) ./mk-agen-texi.sh: line 221: 9409 Aborted ${cmd} Based on comment #10 this bug was fixed. Thank you guys. It isn't fixed. The workaround works - first build version 5.9.7 and then version 5.10 builds. Building 5.10 without a version of autogen installed does _not_ work. Not 5.10.1, nor 5.10.2, nor even 5.11.pre2. The problem is exactly as stated in comment #11: a test of hello.c can't #include autoopts/options.h, probably because autogen messes up the -L flags somehow. reopening per comment #13. This is actually a duplicate of Bug 316583 and will be resolved with autogen 5.11. *** Bug 332655 has been marked as a duplicate of this bug. *** (In reply to comment #15) > This is actually a duplicate of Bug 316583 and will be > resolved with autogen 5.11. > Hem 5.11 is out since 25 Jul. Please bump and fix this and #316583 ``Hem 5.11 is out since 25 Jul'' Yeah, but it has an ugly bug: a shell process is left abandoned. I have a fix in a pre-release, but I have little time to put it through my "qa". It _is_ a one-person project: http://autogen.sourceforge.net/data/index.html (In reply to comment #18) > ``Hem 5.11 is out since 25 Jul'' > Yeah, but it has an ugly bug: a shell process is left abandoned. > I have a fix in a pre-release, but I have little time to put it > through my "qa". It _is_ a one-person project: > > http://autogen.sourceforge.net/data/index.html > Well but grub-9999 depends on it, while your ugly bug is .. what? Memory leak? Some a little bigger problem but if it "works" for grub-9999 i think that's more important. Since grub-9999 doesn't accept 5.9 and this is actually a blocker for that package. Anyways #335703 to talk about 5.11 maybe better.. (In reply to comment #19) > Well but grub-9999 depends on it, while your ugly bug is .. what? > Memory leak? A process table leak. Every time it implements a template that includes shell processing, an orphaned shell will be left waiting for input on a floating pipe. I should have time to deal with it Monday (a US holiday). building texi/info/man/etc... pages on end systems is lame anyways. the upstream package should be including these in their dist target. (In reply to comment #21) > building texi/info/man/etc... pages on end systems is lame anyways. the > upstream package should be including these in their dist target. It should be easier to say that C depends on A but cannot be built without target B. As it stands, "C" transitively depends upon the predecessors of "B" (i.e., docs depend upon executables) Yup, this is duplicate. *** This bug has been marked as a duplicate of bug 316583 *** |