From: Sven M. H. <pe...@gm...> - 2001-03-21 16:36:05
|
On Wed, Mar 21, 2001 at 01:44:31PM +0100, Dirk Reiners wrote: > On Mar 20, 6:31pm, Sven M. Hallberg wrote: > > Subject: Re: [Mesa3d-users] configure problem (was Missing GLX > extensions) > > > > Oh, that's ugly. As far as a quick grep indicated the identifier 'quad' > is > > used in a number of places. It would probably be pretty painful to wade > > through all the source files to eliminate every occurance. > > > > Do you have any way of preventing bsd_types.h from being included or > quad from > > being defined in it? > > It's not really that bad. It's not actually DEFINEd, it's just a typedef. > I just changed it in ss_tritmp.h and could compile everything. As for > avoiding it: it's unconditionally included from sys/types.h, and I guess > that one's is definitely needed. Well I guess we'll just change it there for now and leave everything else untouched unless it becomes a problem. > > Well, if the compiler doesn't support the feature the only way would be > to use > > some sort of preprocessor kludge or hard-code the function names. Both > options > > seem kind of hard to accept. I'd say we check for the feature and in > case it's > > not available #define __FUNCTION__ to something sensable expressing the > lack. > > It does support __FILE__ and __LINE__, maybe using these would be better > than not having any indications of the problem happened. Right. Are those two preprocessor macros or real variables? > The new common_rules.make has a bug in that it uses spaces instead of tabs > for the new rules, make doesn't like that. Argh. Happens when copy-and-pasting from an xterm... Fixed. > Some Makefiles use the linker option -no-install, Irix doesn't know that > one. I don't know what the purpose of that option is, maybe it can just be > removed. Hehe. I've noticed that flag, too. Actually asked about it's purpose on mesa3d-dev. Generates a warning on my system, so I'm ignoring it until someone tells me I can safely remove it (*wink*). > I tried making and running a demo from all the different demo directories. > Compiling works, but they didn't run. Apparently somewhere in si-glu C++ > streams are used. I couldn't actually find it, but the library contains > undefined references to symbols that are used in that context (__dl__GPv, > __iob, __vtbl__9type_info, __pure_virtual_called). Adding -lCio to the > link line fixes that. libCio? Never heard of that. And what does it have to do with C++ streams? Can you give me a description of the circumstances under which this library is needed so I can model a proper check for it? It's not available on my machine. > The last thing I found is tests/. The Makefile there doesn't use automake > yet, and wants to use gcc hardcoded. Don't know how important that is. The comment in the Makefile says that these are not supposed to go into the distribution, so I'll leave them out of autoconf/automake for now. > Hope it helps Oh it does. Regards, @SVEN_M_HALLBERG@ <$(pesco_gmx.de)> -- "Would the All-Seeing Eye please look in my direction?" [ KeyID........: 0xC297FEAB ] [ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ] |