hi, i am unable to emerge x11-base/kdrive packages. compile fails with header files not found. Reproducible: Always Steps to Reproduce: 1. emerge x11/kdrive 2. 3. Actual Results: the sources are fetched, untarred and the compilation starts. after some time it dies with: ... making all in lib/Xss... make[4]: Entering directory `/var/tmp/portage/kdrive-4.3.0-r1/work/xc/lib/Xss' rm -f XScrnSaver.o unshared/XScrnSaver.o gcc -m32 -c -I../.. -I../../exports/include -I/usr/X11R6/include -Dlinux - D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_S OURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 - DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DMALLOC_0_RET URNS_NULL -march=pentium3 -O3 -O3 -O3 -O3 -pipe XScrnSaver.c -o unshared/XScrnSaver.o XScrnSaver.c:33:25: X11/Xlibint.h: No such file or directory XScrnSaver.c:34:23: X11/Xutil.h: No such file or directory In file included from XScrnSaver.c:35: ../../exports/include/X11/extensions/Xext.h:39: parse error before '*' token ../../exports/include/X11/extensions/Xext.h:47: parse error before '*' token ../../exports/include/X11/extensions/Xext.h:55: parse error before '*' token In file included from XScrnSaver.c:36: ... Expected Results: kdrive emerged successfully Portage 2.0.49-r15 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1, 2.4.22) ================================================================= System uname: 2.4.22 i686 Intel(R) XEON(TM) MP CPU 1.90GHz Gentoo Base System version 1.4.3.10 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O3 -pipe -funroll-loops" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/confi g /usr/kde/3/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=pentium3 -O3 -pipe -funroll-loops" DISTDIR="/usr/portage/distfiles" FEATURES="sandbox ccache autoaddcvs" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 apm crypt cups ncurses nls gdbm readline gpm tcpd pam ssl perl python - berkdb -oss -arts -avi -encode -foomaticdb -gif -gtk -imlib -jpeg -kde -gnome - libg++ -libwww -mad -mikmod -motif -mpeg -oggvorbis -opengl -pdflib -png -qt - quicktime -sdl -slang -spell -svga -truetype -X -xml2 -xmms -xv zlib"
why is this bug assigned to kde@gentoo.org ?
i have no idea. i have set it to 'portage' but someone (vapier@gentoo.org) has changed it to kde. probably because of the name? kdrive sounds like a KDE application doesnt it? ;) or maybe there is some other reason ?
Despite the name, kdrive isn't a KDE app. Reassigning.
Do you have xfree on this system? Check for existence of /usr/include/X11/{Xlibint.h,Xutil.h}
no i dont, i thought that this package would give me only the small set of xfree that i need - that is headers, libraries and only one or two x servers. have i misunderstood the description ?
ive done some debug and it seems that wrong include paths are being used during the compilation process - missing Xutil.h and Xlibint.h header files are available in: /var/tmp/portage/kdrive-4.3.0-r1/work/xc/lib/X11. i think it is something that should get fixed :)
adding '-I..' to INCLUDES var in kdrive-4.3.0-r1/work/xc/config/imake/Makefile.ini makes the problem disappear. i guess a tiny patch needs to be created and added to ebuild script of kdrive.
With that patch, you are successfully able to run kdrive on an xfree-free installation? kdrive as it stands in portage will not give you any libraries or headers, just the binaries and man pages. I am working to resolve this, but my answer makes kdrive and xfree exclusive, so they cannot live on the same system. That isn't ideal for me but that's the direction development seems to be headed. If you are interested in that, grab the xserver ebuild (and everything it depends on) from http://dev.gentoo.org/~spyderous/overlay. the xserver is in x11-base/, libraries in x11-libs/ and distfiles in distfiles/. I may commit these things in the next couple of weeks, once some more work is completed upstream and once we get configuration issues ironed out here.
yes, my system is xfree free ;) kdrive ebuild fetches required X sources (X430src-1,2,3.tgz) and builds using these. i'll try your ebuilds in a few days. keep up the interesting work :)
Thanks much, I committed a patch for this and bumped it to -r2, along with some cleanups and allowing -Os and -fomit-frame-pointer. I got Xfbdev down to 692K with -Os and -fomit-frame-pointer with minimal USE flags (notice there are a few new ones, although I need to play with them some more).
Andrew, adding you since there's some work yet to be done on this for -r2. At least it didn't work locally.
Patching Makefile.ini doesnt work here... It appears that Makefile.ini isnt the actual source of the includes, besides this will not fix a futher problem of missing libraries, at the moment i am trying to setup a "fake" project root. Also Xext seems to cause problems, it appears that Xext is linked to by Xss but Xext is not built, this appears to be because of bad makefiles, but the only way to get around this is to perform a recursive makefile sed patching which im still trying to actually get working properly.
Created attachment 21361 [details] New ebuild for non-X builds This ebuild will build and install Xvesa or Xfbdev (or both) depending on your USE, you will also recieve a man page for Xkdrive, Xvesa and Xfbdev. This ebuild also requires a new patch tarball available from here http://www.volutin.net/~andrew/GENTOO/kdrive-4.3.0-gentoo-0.5.tar.bz2
Created attachment 21363 [details] Ebuild for non-X builds argh, picked the wrong file. Use this one
Hi, I just got the parse error below on an XFree86 "free" install. I'll adjust the .ini file and report any success.
What error below?
Excuse me for being a bit ambiguous in my first message. I was referring to the same parse errors that were listed in the original message, which for me eventually lead to failier of the ebuild. I also get several warnings/errors at the start of the emerge, which refer to several definied items being redefined. I can't remember what they are, but if you are interested I can post them later this evening. Another error which sticks in my mind is one regarding excessive "whitespace"? For the past few days I've recompiled the stage1 x86 gentoo install with various USE tags and even tried a stage3 install, but the kdrive emerge still fails after each one. All other emerge's have worked fine on the same including other x11-bases. -Elliott
Could you detail the steps you used in compiling kdrive, as I just tested the ebuild again on a X "free" machine and it is working. Please make sure that you are using the 0.5 version of the kdrive tarball, http://www.volutin.net/~andrew/GENTOO/kdrive-4.3.0-gentoo-0.5.tar.bz2 The mentioning of redefintions is not a big deal. It is a result of our method of defining items using host.def, ultimately this should be changed but requires a sizeable re-work of the xc/config/cf tree.
Hi Andrew, I got the 0.5 patch and new ebuild to work. Feels good, thanks! -Elliott
Just for clarification and tracking (from your email) Did you use the ebuild here or the one that you modified yourself?
My results where from a mod'ed ebuild which exactly mirrored of your source and it worked like a charm. If you'd like I can ebuild your source directly and test it out for ya.
Could you test the ebuild that is provided here please... If it does not work for you could you detail where and what you did differently that made kdrive build without XFree installed at your location... as the ebuild provided here has worked for me on three seperate systems now...
Yes your orig. ebuild compiles on my machine. I didn't test it out for very long, just peeked at Xvesa and man pages.
Created attachment 21540 [details] New features Updated ebuild - Does not build against own libraries if they exist locally
Andrew, not sure if I get your logic there... If best_version returns true, then it does the fakeroot stuff. Shouldn't it be doing that only if best_version returns false?
Yes thats my mistake... I wrote the config.def best_version check with a negative logic at first and then that part. In the end I decided that the section dealing with config.def wasnt intuitive enough so changed it back to how it is now, mustve forgotten that one :)
kdrive-4.3.0-r3 has just been commited to portage under ~x86 this version contains the fixes listed in this bug. Resolving.
