dev-lang/sr-2.3.2 fails to compile due a headers problem. Is that gcc-3.3? Reproducible: Always Steps to Reproduce: 1.Just try to compile dev-lang/sr-2.3.2 Actual Results: cc -g -c -o import.o import.c echo '/* Created mechanically; DO NOT EDIT THIS FILE */' >tkflags.h echo '' >>tkflags.h awk '/^%t[^*]*\*[BEG + END]*\*/{printf("TKFLAGS(%s,%s)\n",$2,$4);}' \ <grammar.y >>tkflags.h cc -g -c -o input.o input.c cc -g -c -o list.o list.c cc -g -c -o names.o names.c cc -g -c -o node.o node.c cc -g -c -o op.o op.c cc -g -c -o output.o output.c In file included from output.c:11: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/varargs.h:4:2: #error "GCC no longer implements <varargs.h>."/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/varargs.h:5:2: #error "Revise your code to use <stdarg.h>." output.c:235: error: syntax error before "va_dcl" output.c:236: error: syntax error before '{' token output.c:245: error: initializer element is not constant output.c:245: warning: data definition has no type or storage class output.c:247: warning: parameter names (without types) in function declaration output.c:247: warning: data definition has no type or storage class output.c:248: error: conflicting types for `fmt' output.c:238: error: previous declaration of `fmt' output.c:248: error: `ap' undeclared here (not in a function) output.c:248: error: syntax error before "char" output.c:260: error: syntax error before '--' token output.c:265: error: syntax error before '--' token output.c:270: error: syntax error before '--' token output.c:335: error: syntax error before string constant output.c:350: error: syntax error before string constant output.c:372: error: conflicting types for `c' output.c:240: error: previous declaration of `c' output.c:372: warning: data definition has no type or storage class output.c:372: error: syntax error before ')' token output.c:382: error: syntax error before string constant output.c:383: error: conflicting types for `cprintf' protos.h:151: error: previous declaration of `cprintf' output.c:383: error: conflicting types for `e' output.c:242: error: previous declaration of `e' output.c:383: error: syntax error before ')' token output.c:408: warning: parameter names (without types) in function declaration output.c:408: warning: data definition has no type or storage class output.c:410: error: syntax error before "if" make[1]: *** [output.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/sr-2.3.2/work/sr' make: *** [all] Error 2 !!! ERROR: dev-lang/sr-2.3.2 failed. !!! Function src_compile, Line 24, Exitcode 2 !!! make failed Expected Results: Succesful compilation of sr Portage 2.0.50_pre16 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20040117-r0, 2.4.22-gentoo-r5) ================================================================= System uname: 2.4.22-gentoo-r5 i686 AMD Athlon(TM)Processor Gentoo Base System version 1.4.3.12 Autoconf: sys-devel/autoconf-2.59 Automake: sys-devel/automake-1.7.8 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-tbird -fforce-addr -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=32 -Os -pipe -fomit-frame-pointer -mmmx" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /opt/resin/conf /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=athlon-tbird -fforce-addr -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=32 -Os -pipe -fomit-frame-pointer -mmmx" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://mirror.gentoo.ru/pub/mirror/gentoo/ gentoo.matrixtelecom.ru http://www.dvo.ru/pub/Gentoo/www.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X alsa apache2 apm arts avi berkdb bonobo cdr crypt cups directfb dvd encode esd foomaticdb gdbm gif gnome gpm gtk gtk2 gtkhtml guile imap imlib java jpeg kde libg++ libwww mad mikmod mmx motif mozcalendar mozilla mpeg mule mysql ncurses nls nptl oggvorbis opengl oss pam pdflib perl png postgres python qt quicktime readline ruby sasl sdl slang spell sse ssl svga tcltk tcpd tetex truetype usb x86 xml2 xmms xv zlib"
Hi Kirill. Thanks for the report. Vah, this package has not been updated since 1999 :(. I wonder if that was just an academic excersise and its creators lost the interest in it since then. Anyway, I can reproduce the problem, which is already good. Apparently the failures are due to gcc-3.3 not taking lightly some programming practices it was accepting earlier on.. (the ebuild was accepted into the tree like 2 years ago already). I've tried to do some fixups and got around two problems. Here are the additions to src_unpack I did: #gcc-3.3 series fix - replacing vararg.h with stdarg.h grep -rle varargs.h .| xargs sed -i -e "s:varargs.h:stdarg.h:g" #fixing apparent syntax error cd sr sed -i -e "s:va_dcl:/*va_dcl*/:" output.c However this is not all, now it complains about malformed macro (which is defined in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include/stdarg.h). SO, this gets quite involved and I don't think I'll be able to fix this right away :(. I 'll try to get back to this bug a bit later. I might resort to reporting the bug upstream if I don't find an easy fix.. Oh, and you are definitely wellcome to take a look at the problem if you have enough interest/motivation ;). George
FInally, I got some time to deal with it. gcc-3.3 makes varargs.h fully obsolete and encourage developers to use stdarg.h and ansi-compliant style of varargs calls. Patch follows.
Created attachment 31017 [details, diff] Patch to deal with gcc-3.3 and standard style of varargs calls
George, please see if you can handle this one. Please also add metadata for this package.
Created attachment 63487 [details] new version is apparently out after all these years of "silence" upstream Still needs work though
(In reply to comment #4) > George, please see if you can handle this one. Well, not too sure what to say. This package has a braindead configuration - you have to modify Configure file with some definitions. Shifted this task to sed in the src_unpack in the ebuild instead of a patch, as it was before. This allows sing all the ${P,S,etc} magic alleviating the need forseparate patches for every version. Still, I am hitting a strange compilation error, here is the tail: make[1]: Entering directory `/var/tmp/portage/sr-2.3.3/work/sr' cc -g -c -o main.o main.c In file included from main.c:7: ../arch.h:147: error: parse error before '--' token main.c:115: error: conflicting types for 'options' main.c:53: error: previous implicit declaration of 'options' was here make[1]: *** [main.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/sr-2.3.3/work/sr' Now, looks like half of the patch proposed in #3 should (theoretically) be unnecessary in this version, as, having looked at the code, it looks to me that the relevant parts of stdarg lib were reimplemented right there. Or at last that was an intention, as this is what may be breaking on me (but see next paragraph as well). Another thing, arch.h at toplevel does not list amd64, even though there are > 10 arches listed besides i386. It is possible that if I were to add some magic words to that file I would be able to resurrect compilation, but I am not sure what I can add there :(, so it seems we need somebody with x86 to test this ebuild as well (I am pure amd64 for the moment, sorry). The compilation problems start right there (with arch.h). Another note, sr has been "obsoleted", in effect, by MPD: http://www.cs.arizona.edu/mpd/ So, if this keeps giving us trouble we may get mpd in and then mask sr. George
George, can you propose any tests? There are none in the ebuild. The merge goes through just fine on x86 though. Btw, the reason I asked you to pick this one up is not because I need sr or anything, but because the bug hadn't had any activity for over a year. So I figured it should either be moved forward or resolved somehow.
> George, can you propose any tests? There are none in the ebuild. > The merge goes through just fine on x86 though. Excellent. Nice to see blind fixes actually working :). As for the tests, you can use this: ftp://ftp.cs.arizona.edu/sr/vs233.tar.Z According to the description this is a collection of tests for the sr. > Btw, the reason I asked you to pick this one up is not because I need sr or > anything, but because the bug hadn't had any activity for over a year. So I > figured it should either be moved forward or resolved somehow. That's why I suggested that we might substitute MPD for sr, as from reading the web site I got the impression that MPD is the one they are working on now mostly. There were not much activity, because I was largely "out" last half a year or so (graduated from Caltech and was moving to a new position, in Europe now :)) and nobody else apparently cared enough.. George
I spoke too soon. It doesn't work perfectly yet; merge, unmerge, merge fails because of collisions. Unmerge doesn't remove: /usr/lib/sr/srlib.a /usr/lib/sr/srx Also there seem to be already quite a few tests in the default installation. I think you'll have to run something like srv/srv -v -p from pkg_test, but check the docs for details. They run fine on my system in any case.
> I spoke too soon. It doesn't work perfectly yet; merge, unmerge, merge fails > because of collisions. Unmerge doesn't remove: > /usr/lib/sr/srlib.a > /usr/lib/sr/srx Hm, this is due to: pkg_postinst() { ranlib /usr/lib/sr/srlib.a strip /usr/lib/sr/srx } in ebuild, the "strip /usr/lib/sr/srx" line should just go. The runlib line is probably unnecessary as well (should just speed things up). I suspect it may be safely moved inside src_install, but I am not that familiar with ranlib and I cannot test this one here.. Sorry for missing this. I did not think it will even go that far on first try :). George
Sorry for double posting, but if this fix works fine, can you please commit the final version and close the bug Maurice? I think this is as much as we can do here anyway. George
I still have a few questions. 1) When you said "and I cannot test this one here..", what did you mean? Can you not test this package at all? 2) Are you going to maintain this package still? If so, I'll add metadata.xml when I check things in. Some tests use ssh, so I had to disable those to make src_test non-interactive.
> 1) When you said "and I cannot test this one here..", what did you mean? > Can you not test this package at all? Well, not at the moment, because it does not build on amd64. Later on I'll setup 32bit chroot and will be able to process pure x86 stuff as well. But I am short on space now, I'll need to bye an external HDD for my laptop. > 2) Are you going to maintain this package still? If so, I'll add metadata.xml > when I check things in. Since it works and is a low activity package I don't see a point of ripping it out at the moment. However please list it belonging to lang-misc herd in metadata. I'll have to issue another call for interested developers soon, but hopefully I'll get somebody else to help me out with that herd. I created that herd in attempt to at least somewhat organize maintenance of various small packages under dev-lang and related. Unfortunately people ignored this herd so far (and I was away to yell enough :)), so there are still multiple packages that might go in it (but we need more devs on it first!). George
So the amd64 keyword should be dropped then?
yes, sorry, I forgot I added it. George
I just committed sr-2.3.3, which should fix this bug. Please give it a try.
*** Bug 119418 has been marked as a duplicate of this bug. ***
