Date: Thu, 18 Feb 1999 03:21:45 +0100 From: Palle Girgensohn <girgen@partitur.se> To: David Wolfskill <dhw@whistle.com> Cc: freebsd-ports@freebsd.org Subject: Re: KDE status w/ 3.1-R? Message-ID: <36CB7939.7A7A1B63@partitur.se> References: <199902180049.QAA12093@pau-amma.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi David! I have seen this error, but unfortunatley I cannot remember what the problem is... However, I have a working set of kde & 3.1 here, and here's what I did: Do not use -O2 with the FreeBSD gcc (not sure this applies here...). I use egcs-1.1.1 (from ports/lang/egcs) to compile most ports, and it works great. You must compile kde and qt with the same compiler, though... use kde11 instead of kde. It is newer, and works better. It is stable and released now, not beta. here's an excerpt from my make.conf: CFLAGS= -O -pipe CC= /usr/local/bin/gcc CXX= /usr/local/bin/g++ While this does not answer your questions, I hope it might help anyway. Oh, by the way, the clean up process is just fine, it the way it works. It goes through all dependencies and clean them up recursively. Since many x11 ports depends on XFree86, it gets cleaned a lot... Regards, Palle David Wolfskill wrote: > > My apologies if I managed to mis-direct this query; redirection accepted. > > We had a pressing need to migrate a bunch of desktops to 3.0 before 3.1-R > was available. Thus, we managed to start wit the 3.0-SNAP of 19990201, > and tweak it a little so that the result seemed to work OK for us. > > Accordingly, I switched nearly all the desktops from 2.2.6-R to that 3.0- > SNAP over the last 10 days or so. > > Most of the folks are reasonably content with this; at least no one's > been chasing me with torches & pitchforks (so far).... :-} > > One particular colleague, though, had managed to become accustomed to > using the KDE stuff. > > And when I tried to build the kde port, make figured out dependencies, > and worked on various pieces, but when it got to Mesa3, the following > whimper ensued (after a significant amount of building & churning): > > ... > ../mklib.freebsd libMesaGLU.a 14 0 glu.o mipmap.o nurbs.o nurbscrv.o nurbssrf.o nurbsutl.o project.o quadric.o tess.o tesselat.o polytest.o > mv libMesaGLU.a* ../lib > if [ -d src-glut ] ; then cd src-glut ; make freebsd-elf ; fi > make targets "GL_LIB = libMesaGL.a" "GLU_LIB = libMesaGLU.a" "GLUT_LIB = libglut.a" "CC = gcc" "CFLAGS = -O2 -fPIC -pedantic -I/usr/X11R6/include -DSHM -DHZ=100" "MAKELIB = ../mklib.freebsd" "XLIBS = -Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib -lXext -lXmu -lXi -lX11" > gcc -c -I../include -O2 -fPIC -pedantic -I/usr/X11R6/include -DSHM -DHZ=100 glut_8x13.c > gcc -c -I../include -O2 -fPIC -pedantic -I/usr/X11R6/include -DSHM -DHZ=100 glut_9x15.c > ... > gcc -c -I../include -O2 -fPIC -pedantic -I/usr/X11R6/include -DSHM -DHZ=100 glut_winmisc.c > gcc -c -I../include -O2 -fPIC -pedantic -I/usr/X11R6/include -DSHM -DHZ=100 layerutil.c > ../mklib.freebsd libglut.a 3 7 glut_8x13.o glut_9x15.o glut_bitmap.o glut_bwidth.o glut_cindex.o glut_cmap.o glut_cursor.o glut_dials.o glut_dstr.o glut_event.o glut_ext.o glut_fullscrn.o glut_gamemode.o glut_get.o glut_glxext.o glut_hel10.o glut_hel12.o glut_hel18.o glut_init.o glut_input.o glut_joy.o glut_key.o glut_keyctrl.o glut_keyup.o glut_menu.o glut_menu2.o glut_mesa.o glut_modifier.o glut_mroman.o glut_overlay.o glut_roman.o glut_shapes.o glut_space.o glut_stroke.o glut_swap.o glut_swidth.o glut_tablet.o glut_teapot.o glut_tr10.o glut_tr24.o glut_util.o glut_vidresize.o glut_warp.o glut_win.o glut_winmisc.o layerutil.o > mv libglut.a* ../lib > if [ -d demos ] ; then cd demos ; make freebsd-elf ; fi > make targets "GL_LIB = libMesaGL.a" "GLU_LIB = libMesaGLU.a" "GLUT_LIB = libglut.a" "CC = gcc" "CFLAGS = -O2 -fPIC -pedantic -I/usr/X11R6/include -DSHM -DHZ=100" "MAKELIB = ../mklib.freebsd" "XLIBS = -Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib -lXext -lXmu -lXi -lX11" > gcc -I../include -O2 -fPIC -pedantic -I/usr/X11R6/include -DSHM -DHZ=100 bounce.c -L../lib -lglut -lMesaGLU -lMesaGL -lm -Wl,-rpath,/usr/X11R6/lib -L/usr/X11R6/lib -lXext -lXmu -lXi -lX11 -o bounce > collect2: ld returned 1 exit status > /usr/libexec/elf/ld: cannot open crt0.o: No such file or directory > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > *** Error code 1 > > Stop. > ... > > (There were a *lot* of these "*** Error code 1\n\nStop" line pairs -- about > 30 of them.) > > So, I recently was able to install 3.1-RELEASE on a box to try it out. > After doing the initial set-up, the only "bizarreness" I noticed was a > need to make a symlink in /usr/lib/compat/aout called "libc.s0.2.2", > pointing to ../libc.so.2.2 (which is where that a.out compatability > library got put; I had selected "All" when it came time to select > distributions for this test). > > And I then tried building KDE on the test box... with the same result. > > Now, I dimly recall from some years ago (when I used to help support gcc > & friends) that crt0.o was code that got control before the main() of > the loaded program did, in order to set up the environment to be what a > C program might reasonably expect from a hosted system. It seems > curious that such a thing, if needed, would have trouble being found -- > or (conversely) that it would be looked for if it weren't needed. > > I would appreciate suggestions for attacking this; my colleague has (so > far) withstood his lack of access to KDE with good grace, but I'd rather > not push it. :-} > > I'm not too sure what sort of information is likely to be of use; this > was a clean install (not an upgrade from a.out). Although there are > a.out programs (and libraries) available via NFS, I set PREFIX to > /tmp/local for my experiment, in an effort to localize any damage that > might be done. > > And a "find" for crt0.o turns up empty: > > dhw-test1[12]% find /usr -name crt0.o\* -ls > find: /usr/games/hide: Permission denied > dhw-test1[13]% > > One thing that I note that may be (vaguely?) related is that if I attempt > a "make clean" after this happens, make seems to re-visit directories that > have already been cleaned... with no apparent intent to terminate the > process: > > dhw-test1[8]% sudo make clean > Password: > ===> Cleaning for kdemultimedia-1.0 > ===> Cleaning for giflib-3.0 > ===> Cleaning for XFree86-3.3.3.1 > ===> Cleaning for jpeg-6b > ===> Cleaning for qt-1.42 > ===> Cleaning for gmake-3.77 > ===> Cleaning for Mesa-3.0 > ===> Cleaning for XFree86-3.3.3.1 > ===> Cleaning for XFree86-3.3.3.1 > ===> Cleaning for kdelibs-1.0 > ===> Cleaning for giflib-3.0 > ===> Cleaning for XFree86-3.3.3.1 > ===> Cleaning for jpeg-6b > ===> Cleaning for qt-1.42 > ===> Cleaning for gmake-3.77 > ===> Cleaning for Mesa-3.0 > ===> Cleaning for XFree86-3.3.3.1 > ===> Cleaning for XFree86-3.3.3.1 > ===> Cleaning for kdegames-1.0 > ===> Cleaning for kdesupport-1.0 > ===> Cleaning for qt-1.42 > ===> Cleaning for gmake-3.77 > ===> Cleaning for Mesa-3.0 > ===> Cleaning for XFree86-3.3.3.1 > ===> Cleaning for XFree86-3.3.3.1 > ===> Cleaning for giflib-3.0 > .... > > Lastly, I am not on the -ports list, so I'd appreciate direct responses. > I'm certainly willing to summarize, should that prove desirable. > > Thanks, > david > -- > David Wolfskill UNIX System Administrator > dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ports" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36CB7939.7A7A1B63>