Re: What's the right way to build XFree86-4 now?
At 4:00 AM -0400 7/3/02, Garance A Drosihn wrote: >I started up XDM, and that also worked. Not only that, but my >machine didn't instantly reboot when XDM started, which had been >happening to me for the last few days... Bah humbug. I went to log into XDM, and the machine sat there for awhile, and then rebooted. That might have been because the -libraries were only partially installed, though... Still, it's a step forward. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
At 3:18 AM -0400 7/3/02, Garance A Drosihn wrote: >At 4:57 PM +0200 6/26/02, Sheldon Hearn wrote: >>c) ports/x11-servers/XFree86-4-Server: >> >>Add the attached patch-gcc31, taken from Motoyuki Konno's post to >><[EMAIL PROTECTED]> with the following Message-ID: >> >> <[EMAIL PROTECTED]> > >I thought I'd pretend that #b worked perfectly, and try this too. >In my case, I also wanted the matrox drives, so I have > export WITH_MATROX_GXX_DRIVER=yes > >but that still died with "internal compiler error in failed_reload, >at reload1.c:5050", while compiling translate.c, while processing >included file ../../../../extras/Mesa/src/trans_tmp.h. > >So, no joy in mudville just yet... So As I mentioned in another thread, [EMAIL PROTECTED] had been telling me that compiles under gcc3 go faster when he sets CPUTIME. So just for the fun of it I added CPUTIME=i686 in my /etc/make.conf, and tried to recompile the XFree86-4-Server. This time it compiled. I tried a 'make install', and that also worked. I started up XDM, and that also worked. Not only that, but my machine didn't instantly reboot when XDM started, which had been happening to me for the last few days... [this on a dual-CPU, 650 MHz, Pentium 3 machine. No gnome, no KDE, just plain X with twm as the window manager...] So, mudville is a bit tired, but this is a definite step forward! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
At 4:57 PM +0200 6/26/02, Sheldon Hearn wrote: >Here's what I did to get XFree86-4 to build with the base system's >toolchain in -CURRENT: I thought I'd try this out. Before starting, I did a cvsup of all my ports tree. >a) ports/devel/imake-4: > >Replace files/patch-d and files/patch-xthreads with the attached >patch-config::cf::FreeBSD.cf. > >Add the attached patch-config::cf::bsdLib.tmpl. In both of these, I had to change the header lines (the lines which specify the file to patch) from: config/cf/FreeBSD.cf.orig to cf/FreeBSD.cf.orig I was then able to 'make patch' and 'make install' (I did a 'make extract' before touching any patches in imake-4/files). Without changing those lines, the 'make patch' would fail. >b) ports/x11/XFree86-4-libraries: > >Replace files/patch-z45 with the attached patch-z45. > I made the above switch, and it compiled fine. It then died in the middle of my 'make install' attempt: - - - - - installing in lib/GL/GL... /usr/bin/install -c -m 0644 libGL.a /usr/X11R6/lib ranlib /usr/X11R6/lib/libGL.a + /usr/bin/install -c -m 0755 libGL.so.1.2 /usr/X11R6/lib/libGL.so.1 + true + rm -f /usr/X11R6/lib/libGL.so + ln -s libGL.so.1 /usr/X11R6/lib/libGL.so install in lib/GL/GL done installing in lib/GL/mesa/src/OSmesa... /usr/bin/install -c -m 0644 libOSMesa.a /usr/X11R6/lib ranlib /usr/X11R6/lib/libOSMesa.a rm -f ../../../../../lib/GL/mesa/src/translate.o unshared/../../../../../lib/GL/mesa/src/translate.o LD_LIBRARY_PATH=../../../../../exports/lib cc -c -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -I../../../../../exports/include/X11 -I../../../../../include/extensions -I../../../../../extras/Mesa/src/OSmesa -I../../../../../extras/Mesa/src -I../../../../../extras/Mesa/include -I../../../../.. -I../../../../../exports/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI -DMALLOC_0_RETURNS_NULL ../../../../../lib/GL/mesa/src/translate.c -o unshared/../../../../../lib/GL/mesa/src/translate.o Assembler messages: FATAL: can't create unshared/../../../../../lib/GL/mesa/src/translate.o: No such file or directory *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc/lib/GL/mesa/src/OSmesa. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc/lib/GL. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc/lib. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries/work/xc. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-libraries. - - - - - (note that this means the package didn't get registered...) I did not even try to guess what this problem might be (hey, it's pretty late at this point!). >c) ports/x11-servers/XFree86-4-Server: > >Add the attached patch-gcc31, taken from Motoyuki Konno's post to ><[EMAIL PROTECTED]> with the following Message-ID: > > <[EMAIL PROTECTED]> I thought I'd pretend that #b worked perfectly, and try this too. In my case, I also wanted the matrox drives, so I have export WITH_MATROX_GXX_DRIVER=yes but that still died with "internal compiler error in failed_reload, at reload1.c:5050", while compiling translate.c, while processing included file ../../../../extras/Mesa/src/trans_tmp.h. So, no joy in mudville just yet... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
On Sun, Jun 30, 2002 at 11:58:51PM -0400, Garance A Drosihn wrote: > Have many people had a chance to test this? I wanted to try it out > this weekend, but I lost most of the weekend due to other problems > with compiling current on my test machine. I finally got by those > problems, but now it's midnight on Sunday and I can't really afford > to start on this right now... Sorry, me not. I also was struggling with -CURRENT buildworld during the weekend and my machine is slow. I rebuilt X with the most recent patch to libGLU from this list and libGLU now seems working. (with the system compiler) The machine freezes under X quite frequently however, but I don't know what is causing it. (and X freezes have the disgusting property of locking up the system solid: no console, no network, nothing in the logs.) Life is sometimes hard in -CURRENT land, but hey, we should never loose our sense of humour. (And yes, maybe I really should get another graphics card... the S3 Virge GX2 may also take part of the blame for the lockups...) -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
On (2002/06/30 00:46), Jeremy Lea wrote:
> +#ifndef SharedDepCplusplusLibraryTarget
> +#define SharedDepCplusplusLibraryTarget [...]
This patch would fix the build. Did it also fix the linking problems
involving -lstdc++ for glxinfo, or were the patches that handle
${CXXLIB} still required?
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
At 4:57 PM +0200 6/26/02, Sheldon Hearn wrote: >Here's what I did to get XFree86-4 to build with the base system's >toolchain in -CURRENT: > >a) ports/devel/imake-4: > >Replace files/patch-d and files/patch-xthreads with the attached >patch-config::cf::FreeBSD.cf. > >Add the attached patch-config::cf::bsdLib.tmpl. > >b) ports/x11/XFree86-4-libraries: > >Replace files/patch-z45 with the attached patch-z45. > >Note that this isn't quite right, because the linking gets done with >cc as a front-end, not c++. But the job gets done, all the same, >and I'm not writing a SharedDepCplusplusLibraryTarget rule myself. >:-) > >c) ports/x11-servers/XFree86-4-Server: > >Add the attached patch-gcc31, taken from Motoyuki Konno's post to ><[EMAIL PROTECTED]> with the following Message-ID: > > <[EMAIL PROTECTED]> Have many people had a chance to test this? I wanted to try it out this weekend, but I lost most of the weekend due to other problems with compiling current on my test machine. I finally got by those problems, but now it's midnight on Sunday and I can't really afford to start on this right now... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
Hi, On Wed, Jun 26, 2002 at 04:57:45PM +0200, Sheldon Hearn wrote: >Note that this isn't quite right, because the linking gets done with >cc as a front-end, not c++. But the job gets done, all the same, >and I'm not writing a SharedDepCplusplusLibraryTarget rule myself. >:-) How about: --- config/cf/bsdLib.rules.orig Sun Jun 30 00:30:05 2002 +++ config/cf/bsdLib.rules Sun Jun 30 00:31:06 2002 @@ -306,6 +306,34 @@ #endif /* SharedDepLibraryTarget */ +/* + * SharedDepCplusplusLibraryTarget - generate rules to create a shared library. + */ +#ifndef SharedDepCplusplusLibraryTarget +#define SharedDepCplusplusLibraryTarget(libname,rev,deplist,solist,down,up)@@\ +AllTarget(Concat(lib,libname.so.rev)) @@\ + @@\ +Concat(lib,libname.so.rev): deplist @@\ + $(RM) $@~ @@\ + @SONAME=`echo $@ | sed 's/\.[^\.]*$$//'`; set -x; \ @@\ + (cd down; $(CXX) -o up/$@~ $(SHLIBLDFLAGS) -Wl,-soname,$$SONAME solist +$(REQUIREDLIBS) BaseShLibReqs); \ @@\ + $(RM) $$SONAME; $(LN) $@ $$SONAME; \@@\ + LinkBuildSonameLibrary($$SONAME)@@\ + $(RM) $@@@\ + $(MV) $@~ $@@@\ + $(RM) Concat(lib,libname.so)@@\ + $(LN) $@ Concat(lib,libname.so) @@\ + LinkBuildLibrary($@)@@\ + LinkBuildLibrary(Concat(lib,libname.so))@@\ + @@\ +clean::@@\ + @SONAME=`echo Concat(lib,libname.so.rev) | sed 's/\.[^\.]*$$//'`; \ @@\ + set -x; $(RM) $$SONAME @@\ + $(RM) Concat(lib,libname.so)@@\ + $(RM) Concat(lib,libname.so.rev) + +#endif /* SharedDepCplusplusLibraryTarget */ + #ifndef SharedDepModuleTarget #define SharedDepModuleTarget(name,deps,solist)@@\ AllTarget(name)@@\ Just copied from the SharedDepLibraryTarget above it, and replaced the CC with CXX... I built libGLU.so.1 with this, and it seemed to fix the glxinfo linking problem. I'm currently testing... Regards, -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
On Wed, 26 Jun 2002 16:57:45 +0200 Sheldon Hearn <[EMAIL PROTECTED]> wrote: > # if (OSRelVersion >= 500016) > +# define ThreadsLibraries -lc_r > +# else > +# define SystemMTDefines -D_REENTRANT -D_THREAD_SAFE > +# define ThreadsLibraries -pthread > +# endif Sheldon, AFAIK _REENTRANT has to be defined on -CURRENT too. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
On Wed, 26 Jun 2002 13:25:57 +0200, Sheldon Hearn wrote:
> I think I have a handle on this now. If you fix it before you hear back
> from me, let me know so I can stop wasting time on it. XF84-4 test
> builds are slow. :-)
Okay, it looks like a bit of a mess.
I've copied the XFree86-4 maintainer.
I think there are three problems causing the XFree86-4 installation to
fail on -CURRENT:
*) Our imake-4 port doesn't arrange for a SharedDepCplusplusLibraryTarget
rule. I _think_ such a rule would, by default, add $(CXXLIB) to the
deplist for -CURRENT.
*) Our imake-4 port doesn't arrange for a CXXLIB definition. It should
be -lstdc++ on at least -CURRENT. The stock bsdLib.tmpl explicitly
sets CplusplusLibC empty, Imake.tmpl sets it to /**/ if not defined
and FreeBSD.cf doesn't set it at all.
*) The XFree86-4 distribution contains some bad C++ code.
Here's what I did to get XFree86-4 to build with the base system's
toolchain in -CURRENT:
a) ports/devel/imake-4:
Replace files/patch-d and files/patch-xthreads with the attached
patch-config::cf::FreeBSD.cf.
Add the attached patch-config::cf::bsdLib.tmpl.
b) ports/x11/XFree86-4-libraries:
Replace files/patch-z45 with the attached patch-z45.
Note that this isn't quite right, because the linking gets done with
cc as a front-end, not c++. But the job gets done, all the same,
and I'm not writing a SharedDepCplusplusLibraryTarget rule myself.
:-)
c) ports/x11-servers/XFree86-4-Server:
Add the attached patch-gcc31, taken from Motoyuki Konno's post to
<[EMAIL PROTECTED]> with the following Message-ID:
<[EMAIL PROTECTED]>
That's all.
Ciao,
Sheldon.
patch-config::cf::FreeBSD.cf
--- config/cf/FreeBSD.cf.orig Wed Jun 26 15:44:29 2002
+++ config/cf/FreeBSD.cfWed Jun 26 16:21:18 2002
@@ -80,7 +80,6 @@
/*
* math.h uses _REENTRANT and stdio.h uses _THREAD_SAFE, so define both.
*/
-# define SystemMTDefines -D_REENTRANT -D_THREAD_SAFE
/*
* FreeBSD has tread-safe api but no getpwnam_r yet.
*/
@@ -91,8 +90,12 @@
# else
# define BuildThreadStubLibrary YES
# define NeedUIThrStubs YES
-# define ThreadsCompileFlags -pthread
-# define ThreadsLibraries -pthread
+# if (OSRelVersion >= 500016)
+# define ThreadsLibraries-lc_r
+# else
+# define SystemMTDefines -D_REENTRANT -D_THREAD_SAFE
+# define ThreadsLibraries-pthread
+# endif
# define SharedX11Reqs$(LDPRELIB) $(XTHRSTUBLIB)
# define SharedXtReqs $(LDPRELIB) $(XLIBONLY) $(SMLIB) $(ICELIB)
$(XTHRSTUBLIB)
# endif
@@ -151,6 +154,7 @@
# define CcCmd cc
# define CplusplusCmd c++
#endif
+#defineCplusplusLibC -lstdc++
#define CppCmd /usr/bin/cpp
#define PreProcessCmd CppCmd
patch-config::cf::bsdLib.tmpl
--- config/cf/bsdLib.tmpl.orig Wed Jun 26 16:19:42 2002
+++ config/cf/bsdLib.tmpl Wed Jun 26 16:20:34 2002
@@ -39,7 +39,9 @@
#define XawClientLibs $(XAWLIB) $(XMULIBONLY) $(XTOOLLIB) $(XPMLIB) $(XLIB)
#endif
-#define CplusplusLibC
+#ifndef CplusplusLibC
+#define CplusplusLibC $(CXX)
+#endif
#define FrescoSysLibs CplusplusLibC MathLibrary
/* Allow for libpthread, as overridden by OS definitions */
patch-z45
--- lib/GLU/Imakefile.orig Wed Jun 6 01:03:20 2001
+++ lib/GLU/Imakefile Wed Jun 26 15:27:14 2002
@@ -103,6 +103,7 @@
#undef _LinkBuildLibrary
#define _LinkBuildLibrary(lib) LinkBuildLibrary(lib)
+#if !defined(LibInstall) || LibInstall
#if NormalLibGlu
NormalDepLibraryTarget($(LIBNAME),$(SUBDIRS) $(DONES),$(STATIC_OBJS))
InstallLibrary($(LIBNAME),$(USRLIBDIR))
@@ -110,9 +111,9 @@
#if SharedLibGlu
#ifdef SharedDepCplusplusLibraryTarget
-SharedDepCplusplusLibraryTarget($(LIBNAME),$(SOREV),$(SUBDIRS)
$(DONES),$(SHARED_OBJS),.,.)
+SharedDepCplusplusLibraryTarget($(LIBNAME),$(SOREV),$(SUBDIRS)
+$(DONES),$(SHARED_OBJS) $(CXXLIB),.,.)
#else
-SharedDepLibraryTarget($(LIBNAME),$(SOREV),$(SUBDIRS) $(DONES),$(SHARED_OBJS),.,.)
+SharedDepLibraryTarget($(LIBNAME),$(SOREV),$(SUBDIRS) $(DONES),$(SHARED_OBJS)
+$(CXXLIB),.,.)
#endif
InstallSharedLibrary($(LIBNAME),$(SOREV),$(SHLIBDIR))
#endif
@@ -126,6 +127,7 @@
ProfiledDepLibraryTarget($(LIBNAME),$(SUBDIRS) $(DONES),$(PROFILE_OBJS))
InstallLibrary($(LIBNAME)_p,$(USRLIBDIR))
#endif /* ProfileLibFont */
+#endif
ForceSubdirs($(SUBDIRS))
patch-gcc31
--- lib/XThrStub/UIThrStubs.c.old Mon Nov 19 06:13:26 2001
+++ lib/XThrStub/UIThrStubs.c Tue Jun 4 11:39:19 2002
@@ -99,6 +99,21 @@
#else
#include
typedef pthread_t xthread_t;
+#if __GNUC__ >= 3
+xthread_t pthread_self()__attribute__ ((weak, alias ("_Xthr_self_stub_")));
+int pthread_mutex_init()__attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+int pthread_mutex_destroy() __attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+int pthread_mutex_lock()__attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+i
Re: What's the right way to build XFree86-4 now?
On (2002/06/25 22:02), Szilveszter Adam wrote: > > I've tried `make install' and `make CXX=/usr/local/bin/g++31 install', > > where that g++31 comes from the lang/gcc31 port, and either way, > > XFree86-4-clients fails with: > > There is another problem, however, and this is that the libGLU built is > parctically unusable anyway, although there the correct compiler is used > (g++), one alway needs to link -lstdc++ with it for it to work. I do not > know why this is. Other parts of X appear to work ok. Thanks for the great response! You really gave me useful stuff to think about. I think I have a handle on this now. If you fix it before you hear back from me, let me know so I can stop wasting time on it. XF84-4 test builds are slow. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
Hello Sheldon, On Tue, Jun 25, 2002 at 09:21:57AM +0200, Sheldon Hearn wrote: > Hi folks, > > Could someone put me out of my misery and show me "the right way" to > build XFree86-4 on -current at the moment. > > I've tried `make install' and `make CXX=/usr/local/bin/g++31 install', > where that g++31 comes from the lang/gcc31 port, and either way, > XFree86-4-clients fails with: <...> This must be glxinfo. This shows btw, that the make World was not successful, therefore the install fails. The problem here, as verified by my build logs, is that glxinfo (really, xc/programs/glxinfo) is built using gcc since it is C, but tries to link against -lGLU, which is C++. Specifying -lstdc++ explicitly on the link line works in this case. Changing the compiler was not trivial here, since the Imake framework generated Makefiles decide on which compiler to use based on the source file suffices, and since here it is .c, they use gcc for both building and linking. The quick way out I found is to hack the Makefile by hand and including the extra lib, but this both ugly and wrong. There is another problem, however, and this is that the libGLU built is parctically unusable anyway, although there the correct compiler is used (g++), one alway needs to link -lstdc++ with it for it to work. I do not know why this is. Other parts of X appear to work ok. As an aside, this is a rather interesting way of building, but both XFree and OpenMotif use it: the build does not stop at build failures so you only notice the problems upon install time when it tries to build the missing pieces again. THerefore, before installing, one should always grep the build logs for "all not remade because of errors". Also see xc/programs/Xserver/hw/xfree86/doc/BUILD. Also as an aside, the current way of building the X4 port with its slave port sucks royally. The libs are built no less than 3 times, and the whole shebang is untarred at least as many times, which means that 1 gig is not enough for building it! Let's face it, the X build is like ours: "make World" was not designed to be used sliced up like this. There should be one "full build" port for XFree-4 just like there is one for the old X, and the now slave ports should only be there for people who for some reason need them. Duplicated code in the Makefiles certainly does not justify this nightmare that a full build of XFree-4 from ports now is. At least that's my opinion. -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
On Tue, Jun 25, 2002 at 07:33:27PM +0200, Sheldon Hearn wrote: > Was that advice based on the fact that you've built XFree86-4 > successfully with lang/gcc31, or was it an educated guess? Just a guess. I wonder if C++ code is being compiled with `gcc' rather than `g++'. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
On (2002/06/25 10:06), David O'Brien wrote: > On Tue, Jun 25, 2002 at 09:21:57AM +0200, Sheldon Hearn wrote: > > Could someone put me out of my misery and show me "the right way" to > > build XFree86-4 on -current at the moment. > > > > I've tried `make install' and `make CXX=/usr/local/bin/g++31 install', > > where that g++31 comes from the lang/gcc31 port, and either way, > > XFree86-4-clients fails with: > > Try building all of the dependancies with g++31 also. Makes no difference. I'm using a dependecy manager to ensure that all dependencies are built first, in the appropriate order. Was that advice based on the fact that you've built XFree86-4 successfully with lang/gcc31, or was it an educated guess? -- Sheldon Hearn Postmaster - Gambling.com In systems administration, a change is NOT as good as a holiday! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
On Tue, Jun 25, 2002 at 09:21:57AM +0200, Sheldon Hearn wrote: > Could someone put me out of my misery and show me "the right way" to > build XFree86-4 on -current at the moment. > > I've tried `make install' and `make CXX=/usr/local/bin/g++31 install', > where that g++31 comes from the lang/gcc31 port, and either way, > XFree86-4-clients fails with: Try building all of the dependancies with g++31 also. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
What's the right way to build XFree86-4 now?
Hi folks, Could someone put me out of my misery and show me "the right way" to build XFree86-4 on -current at the moment. I've tried `make install' and `make CXX=/usr/local/bin/g++31 install', where that g++31 comes from the lang/gcc31 port, and either way, XFree86-4-clients fails with: /usr/X11R6/lib/libGLU.so: undefined reference to `operator new[](unsigned)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__si_cl ass_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete(void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `__gxx_personality_v0' /usr/X11R6/lib/libGLU.so: undefined reference to `__cxa_pure_virtual' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__class _type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete[](void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__vmi_c lass_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator new(unsigned)' Looks like bad linkage to me, but I'm all out of foo. :-( Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
