Menu
▾
▴
mesa3d-dev
|
From: Sven M. H. <pe...@gm...> - 2001-03-20 00:59:21
|
On Mon, Mar 19, 2001 at 09:21:00AM -0700, Brian Paul wrote: > > Using that the Makefile error goes away, but you still can't compile on > > Irix. The compiler flag to update dependencies on Irix is '-MDupdate', not > > '-MD'. I don't know anything about autoconf, so I don't know how to change > > the configure parts, but just replacing -MD with -MDupdate in all > > Makefile.in files makes it work. I just don't know if that also works on > > Linux, can somebody try that? If not, can somebody who knows a little more > > about autoconf/configure add that as a platform-dependent option? I've finished this in the CVS trunk (Mesa 3.5). The configure script now checks a platform-dependent list of possible dependency update switches to find one that works. If it finds one that is not -MD it overrides the normal build rules generated by automake. These rules are held in the file $(top_srcdir)/common_rules.make which every Makefile.am includes. Unfortunately there is no way to dynamically turn of dependency tracking alltogether because automake hard-codes it into the build rules. This means if the configure script doesn't find a way to do dependency tracking but you need it (probably because you're building from CVS - dependency information is removed in the distribution package) the build process will blow. Dirk: Can you check out Mesa 3.5 and see if it compiles on your Irix machine now? Hope this helped, Sven -- "Would the All-Seeing Eye please look in my direction?" [ KeyID........: 0xC297FEAB ] [ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ] |
|
From: Dirk R. <re...@ig...> - 2001-03-20 15:53:11
Attachments:
libMesaAC_la_SOURCES
common_rules.make
|
On Mar 20, 2:04am, Sven M. Hallberg wrote:
>
> Dirk: Can you check out Mesa 3.5 and see if it compiles on your Irix
machine
> now?
>
>-- End of excerpt from Sven M. Hallberg
Getting closer. After checking out the current CVS I called bootstrap,
configure and gmake all. The following problems came up:
1) src/array_cache/libMesaAC_la_SOURCES was missing, I recreated it as
shown in the attachment, I hope that's right. At least it compiles. ;)
2) cc-1101 cc: ERROR File = ss_tritmp.h, Line = 159
"quad" has already been declared in the current scope.
static void TAG(quad)( GLcontext *ctx, GLuint v0,
^
quad is already defined in bsd_types.h. Renaming quad to quadfunc in
ss_tritmp.h fixed that.
3) texutil_tmp.h : __FUNCTION__ undefined
Irix CC doesn't define __FUNCTION__. I just killed it by #defining it to
nothing, but that's not a solution.
4) si-glu still used the old ,-MD, for dependencies. Adding the rules for
%.o: %.cc and %.lo: %.cc to common_rules.make fixed that (see attachment).
Doing that it apparently compiled, but didn't create the GLUT lib. gmake
all in src-glut does nothing. No idea whats' wrong here?!? Thus I'm not
sure what else it didn't make and I can't run tests or demos.
I need a hint what to do now...
Thanks
Dirk
--
--
-- Dirk Reiners re...@ig..., Dir...@gm...
-- OpenSG Forum http://www.opensg.org
-- Rundeturmstrasse 6 http://www.igd.fhg.de/~reiners
-- D-64283 Darmstadt All standard disclaimers apply.
-- Truth is stranger than fiction because fiction has to make sense.
|
|
From: Sven M. H. <pe...@gm...> - 2001-03-20 17:25:51
|
On Tue, Mar 20, 2001 at 04:55:24PM +0100, Dirk Reiners wrote:
> 1) src/array_cache/libMesaAC_la_SOURCES was missing, I recreated it as
> shown in the attachment, I hope that's right. At least it compiles. ;)
Completely correct. I had forgotten to add it to the repository. Fixed now.
> 2) cc-1101 cc: ERROR File = ss_tritmp.h, Line = 159
> "quad" has already been declared in the current scope.
>
> static void TAG(quad)( GLcontext *ctx, GLuint v0,
> ^
> quad is already defined in bsd_types.h. Renaming quad to quadfunc in
> ss_tritmp.h fixed that.
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?
> 3) texutil_tmp.h : __FUNCTION__ undefined
> Irix CC doesn't define __FUNCTION__. I just killed it by #defining it to
> nothing, but that's not a solution.
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.
> 4) si-glu still used the old ,-MD, for dependencies. Adding the rules for
> %.o: %.cc and %.lo: %.cc to common_rules.make fixed that (see attachment).
Oh yeah, missed that one, Fixed.
> Doing that it apparently compiled, but didn't create the GLUT lib. gmake
> all in src-glut does nothing. No idea whats' wrong here?!? Thus I'm not
> sure what else it didn't make and I can't run tests or demos.
Hm, seems something messed up here. Fixed two minor mistakes, but I don't see
how these could have caused glut not being built at all:
* Makefile.am: Added src-glut to DIST_SUBDIRS.
* src-glut/Makefile.am: Removed NEED_GLUT check for good.
I assume you don't have another GLUT already installed, do you? In that case
the configure script will use that library instead of the one supplied with
Mesa. Look for a warning message from configure. You can tell configure not to
look for an external GLUT using --without-glut.
Thanks for the feedback,
@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 ]
|
|
From: Dirk R. <re...@ig...> - 2001-03-21 12:44:43
|
OK, next iteration. :) 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, 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. > Hm, seems something messed up here. Fixed two minor mistakes, but I don't see > how these could have caused glut not being built at all: > * Makefile.am: Added src-glut to DIST_SUBDIRS. > * src-glut/Makefile.am: Removed NEED_GLUT check for good. > > I assume you don't have another GLUT already installed, do you? In that case > the configure script will use that library instead of the one supplied with > Mesa. Look for a warning message from configure. You can tell configure not to > look for an external GLUT using --without-glut. OK, looks like that was the problem. I do have another GLUT somewhere, --without-glut worked. >-- End of excerpt from Sven M. Hallberg Nearly. 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. 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. Now everything makes. Woohoo! ;) 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. 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. Hope it helps Dirk -- -- -- Dirk Reiners re...@ig..., Dir...@gm... -- OpenSG Forum http://www.opensg.org -- Rundeturmstrasse 6 http://www.igd.fhg.de/~reiners -- D-64283 Darmstadt All standard disclaimers apply. -- Truth is stranger than fiction because fiction has to make sense. |
|
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 ] |
|
From: Dirk R. <re...@ig...> - 2001-03-22 21:32:21
|
On Mar 21, 5:36pm, Sven M. Hallberg wrote:
> Subject: Re: [Mesa3d-users] configure problem (was Missing GLX
extensions)
>
> Well I guess we'll just change it there for now and leave everything
> else untouched unless it becomes a problem.
OK.
>
> Right. Are those two preprocessor macros or real variables?
I think the former. Does it make a difference and how do I check?
> 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*).
Well, it creates an error on Irix, i.e. no compile. If nobody knows what
it's good for, maybe now is a good time to get rid of it. ;)
> 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.
It's part of the current STL. It contains the little code that is created
and needed by STL, mainly stream stuff, some complex number functions etc.
It is needed on Irix as soon as the 'std' namespace STL is used (BTW, if
that happens you also need the -LANG:std option). You can easily test if
you need by running the following program:
#include <iostream>
int main( int argc, char *argv[] )
{
std::cout;
}
If it works you don't need to do anything special, if it gives an error
you need -lCio. By default the compiler includes it automatically, but
libtool apparently works around that, so you'll have to use libtool to
check it.
I don't really understand why it is needed for si-glu, I couldn't find
streams in there, maybe it was something else. It's just confusing that
you don't need the -LANG:std option, usually it complains if you use the
std namespace, and if you don't use that, why does it need the libCio.so?
Something's fishy here but I'm not sure what it is.
>-- End of excerpt from Sven M. Hallberg
Yours
Dirk
--
--
-- Dirk Reiners re...@ig..., Dir...@gm...
-- OpenSG Forum http://www.opensg.org
-- Rundeturmstrasse 6 http://www.igd.fhg.de/~reiners
-- D-64283 Darmstadt All standard disclaimers apply.
-- Truth is stranger than fiction because fiction has to make sense.
|
|
From: Sven M. H. <pe...@gm...> - 2001-03-23 22:34:13
|
On Thu, Mar 22, 2001 at 10:32:10PM +0100, Dirk Reiners wrote:
> > Right. Are those two preprocessor macros or real variables?
>
> I think the former. Does it make a difference and how do I check?
The difference it makes is that, if they are both preprocessor macros that
expand to _string_ constants, we could simply
#define __FUNCTION__ "unknown function at " __FILE__ ":" __LINE__
However if that's not the case we need to use a function call to create a
single sensable string from them. Some sprintf-like thing that uses and
returns a static buffer for the string would probably be best:
#define __FUNCTION__ mesa_static_sprintf("unknown function at %s:%d", \
__FILE__, __LINE__);
If your compiler/preprocessor docs don't give enough information, running a
test file containing __FILE__ and __LINE__ through the preprocessor should
suffice.
> > 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*).
>
> Well, it creates an error on Irix, i.e. no compile. If nobody knows what
> it's good for, maybe now is a good time to get rid of it. ;)
Right, will remove it right after I send this mail out.
> > 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.
>
> It's part of the current STL. It contains the little code that is created
> and needed by STL, mainly stream stuff, some complex number functions etc.
Oh, so it's your equivalent to what's called libstdc++ on my system?
> It is needed on Irix as soon as the 'std' namespace STL is used (BTW, if
> that happens you also need the -LANG:std option). You can easily test if
> you need by running the following program:
>
> #include <iostream>
>
> int main( int argc, char *argv[] )
> {
> std::cout;
> }
>
> If it works you don't need to do anything special, if it gives an error
> you need -lCio. By default the compiler includes it automatically, but
> libtool apparently works around that, so you'll have to use libtool to
> check it.
OK, thanks, will write the check tomorrow probably.
> I don't really understand why it is needed for si-glu, I couldn't find
> streams in there, maybe it was something else. It's just confusing that
> you don't need the -LANG:std option, usually it complains if you use the
> std namespace, and if you don't use that, why does it need the libCio.so?
> Something's fishy here but I'm not sure what it is.
Right, it's strange. Did the linker give you an indication where the Cio
symbols were referenced?
Regards,
Sven
--
"Would the All-Seeing Eye please look in my direction?"
[ KeyID........: 0xC297FEAB ]
[ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ]
|
|
From: Marcelo E. M. <mar...@bi...> - 2001-03-24 13:58:01
|
>> "Sven M. Hallberg" <pe...@gm...> writes: > The difference it makes is that, if they are both preprocessor macros that > expand to _string_ constants, we could simply __FUNCTION__ (and __PRETTY_FUNCTION__) are string variables. From the gcc manual: > These names are not macros: they are predefined string variables. > For example, `#ifdef __FUNCTION__' does not have any special meaning > inside a function, since the preprocessor does not do anything > special with the identifier `__FUNCTION__'. -- Marcelo |
|
From: Sven M. H. <pe...@gm...> - 2001-03-24 16:11:02
|
On Sat, Mar 24, 2001 at 02:57:56PM +0100, Marcelo E. Magallon wrote: > >> "Sven M. Hallberg" <pe...@gm...> writes: > > > The difference it makes is that, if they are both preprocessor macros that > > expand to _string_ constants, we could simply > > __FUNCTION__ (and __PRETTY_FUNCTION__) are string variables. From the > gcc manual: But what about __FILE__ and __LINE__? -- @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 ] |
|
From: Marcelo E. M. <mar...@bi...> - 2001-03-24 19:23:09
|
>> "Sven M. Hallberg" <pe...@gm...> writes: > But what about __FILE__ and __LINE__? Preprocessor macros. __FUNCTION__ is defined by the compiler because the preprocessor doesn't know about functions. Conversely, the compiler doesn't know about __FILE__ and __LINE__ because its input has been preprocessed (it gets the info via #line directives) -- Marcelo |
|
From: Brian P. <br...@va...> - 2001-03-21 15:49:57
|
Dirk Reiners wrote: > > OK, next iteration. :) > > 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, 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. > > > Hm, seems something messed up here. Fixed two minor mistakes, but I > don't see > > how these could have caused glut not being built at all: > > * Makefile.am: Added src-glut to DIST_SUBDIRS. > > * src-glut/Makefile.am: Removed NEED_GLUT check for good. > > > > I assume you don't have another GLUT already installed, do you? In that > case > > the configure script will use that library instead of the one supplied > with > > Mesa. Look for a warning message from configure. You can tell configure > not to > > look for an external GLUT using --without-glut. > > OK, looks like that was the problem. I do have another GLUT somewhere, > --without-glut worked. > > >-- End of excerpt from Sven M. Hallberg > > Nearly. > > 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. > > 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. > > Now everything makes. Woohoo! ;) > > 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. > > 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 programs under tests/ aren't included in the Mesa distro. They're only intended for us developers. The makefiles aren't too important. -Brian |
|
From: Dirk R. <re...@ig...> - 2001-03-27 18:01:26
|
On Mar 23, 11:37pm, Sven M. Hallberg wrote: > Subject: Re: [Mesa3d-users] configure problem (was Missing GLX extensions) > > If your compiler/preprocessor docs don't give enough information, running a > test file containing __FILE__ and __LINE__ through the preprocessor should > suffice. Hmm, it's a little more complicated. They are preprocessor symbols, but __LINE__ is just a number, not text. Thus __FILE__ ":" __LINE__ doesn't work. Using #__LINE__ doesn't, either, as # only works for function macro arguments. And putting __LINE__ in a function macro gives you "__LINE__", which is not very helpful. You could switch to a printf solution, but I'm tempted to just go the VMS route: ignore it. I guess the whole thing is just for internal developers, very few of which will use an sgi. And those could kludge something themselves. > Right, will remove it right after I send this mail out. Yup, works now. > Oh, so it's your equivalent to what's called libstdc++ on my system? If I knew what libstdc++ did I could tell you, but I guess the answer is yes. ;) > > Right, it's strange. Did the linker give you an indication where the Cio > symbols were referenced? > >-- End of excerpt from Sven M. Hallberg Running the files through nm and grepping gave me the list given below. I guess just including -lCio for the executables should be an acceptable fix. Yours Dirk __dl__GPv is in ./libnurbs/nurbtess/sampledLine.lo ./libnurbs/nurbtess/sampleCompRight.lo ./libnurbs/nurbtess/gridWrap.lo ./libnurbs/nurbtess/sampleMonoPoly.lo ./libnurbs/nurbtess/monoTriangulation.lo ./libnurbs/nurbtess/sampleComp.lo ./libnurbs/nurbtess/primitiveStream.lo ./libnurbs/nurbtess/directedLine.lo ./libnurbs/nurbtess/rectBlock.lo ./libnurbs/nurbtess/monoChain.lo ./libnurbs/internals/slicer.lo ./libnurbs/internals/subdivider.lo ./libnurbs/internals/mesher.lo ./libnurbs/internals/flist.lo ./libnurbs/internals/coveandtiler.lo ./libnurbs/internals/curvelist.lo ./libnurbs/internals/patchlist.lo ./libnurbs/internals/dataTransform.lo ./libnurbs/internals/varray.lo ./libnurbs/internals/uarray.lo ./libnurbs/internals/displaylist.lo ./libnurbs/internals/trimline.lo ./libnurbs/internals/bufpool.lo ./libnurbs/internals/knotvector.lo ./libnurbs/internals/trimvertpool.lo ./libnurbs/internals/bin.lo ./libnurbs/internals/tobezier.lo ./libnurbs/internals/arctess.lo ./libnurbs/internals/hull.lo ./libnurbs/internals/nurbsinterfac.lo ./libnurbs/interface/glinterface.lo ./libnurbs/interface/glrenderer.lo ./libnurbs/interface/glcurveval.lo ./libnurbs/interface/glsurfeval.lo __pure_virtual_called is in ./libnurbs/internals/basicsurfeval.lo __vtbl__9type_info is in ./libnurbs/internals/flistsorter.lo ./libnurbs/internals/sorter.lo ./libnurbs/internals/nurbstess.lo ./libnurbs/internals/basicsurfeval.lo ./libnurbs/internals/arcsorter.lo ./libnurbs/internals/basiccrveval.lo ./libnurbs/internals/cachingeval.lo ./libnurbs/interface/glrenderer.lo ./libnurbs/interface/glcurveval.lo ./libnurbs/interface/glsurfeval.lo -- -- -- Dirk Reiners re...@ig..., Dir...@gm... -- OpenSG Forum http://www.opensg.org -- Rundeturmstrasse 6 http://www.igd.fhg.de/~reiners -- D-64283 Darmstadt All standard disclaimers apply. -- Truth is stranger than fiction because fiction has to make sense. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X