Page 1 of 1

[Solved]Glew should be external to Ogre rather than embedded

Posted: Mon Mar 04, 2013 2:11 pm
by caduceus
When using Ogre statically, I am facing lots of compatibility issues with glew because Ogre uses old version and my application uses new one. It shall be a dependency project rather than part of Ogre. Just my own opinion other than that I am sure there is very good reason that it exits the way it is.

Re: Glew should be external to Ogre rather than embedded

Posted: Mon Mar 04, 2013 6:43 pm
by masterfalcon
What version of GLEW do you need? Of course it would be great if we could just refer to it externally but we have made some changes to it which is why that wouldn't work.

Re: Glew should be external to Ogre rather than embedded

Posted: Tue Mar 05, 2013 12:16 pm
by caduceus
I understand that, I am actually facing issues as I am using static build of Ogre but that includes GLEW with flag GLEW_MX enabled and hardcoded GLEW_STATIC which is conflicting with my application. Why didnt we decide to use it externally, any specific reason?

Re: Glew should be external to Ogre rather than embedded

Posted: Tue Mar 05, 2013 5:57 pm
by masterfalcon
Yes, as I said in my reply, some changes were made to GLEW to integrate it better with Ogre. Whether or not this could be changed, I don't know. I haven't looked into it.

Re: Glew should be external to Ogre rather than embedded

Posted: Wed Mar 06, 2013 11:55 am
by caduceus
Thanks for the clarification. I kind of hit the dead end as I wanted to use Ogre statically and also want to use latest glew in my application. After doing some changes to make it work I am stuck at getting "glewcontextinit()" undefined error.

Is GLEW_MX flag necessary for Ogre?

Re: Glew should be external to Ogre rather than embedded

Posted: Thu Mar 07, 2013 6:03 am
by masterfalcon
I honestly don't know. I've never delved into the the GLEW integration to see.

Re: Glew should be external to Ogre rather than embedded

Posted: Thu Mar 07, 2013 11:03 am
by caduceus
I understand and thanks for taking time to answer my question. Btw, Is it on roadmap somewhere to compile Ogre with glew dynamically or in other words can we put that on roadmap.

Re: Glew should be external to Ogre rather than embedded

Posted: Thu Mar 07, 2013 4:50 pm
by masterfalcon
No it's not on the roadmap. To the best of my knowledge you're the only person who has asked for such a feature. Given that, it's unlikely that it would be made a priority.

Re: Glew should be external to Ogre rather than embedded

Posted: Thu Mar 07, 2013 8:13 pm
by caduceus
I understand and i agree that there are other far more important things to do in Ogre than this. Its all right, Thanks for your help and I will find my way out of this situation, i might end up using dynamic linking for ogre. Thanks for help and patience.

Re: [Solved]Glew should be external to Ogre rather than embe

Posted: Sun Oct 27, 2013 1:45 am
by scrawl
I just had a look at the history for glew.cpp and I'm not sure which changes you mean. There was a windows related change with GLEWAPIENTRY but it was reverted in a later commit, so I assume it's no longer necessary or was wrong to begin with.
Other than that, I don't see any changes that were done on Ogre's side.

Anyway, the reason I am interested in this is that glew.cpp throws a couple hundred warnings when compiled in GCC with Ogre's build settings, so it would be nice to use the system lib instead.

Re: [Solved]Glew should be external to Ogre rather than embe

Posted: Sun Oct 27, 2013 2:43 am
by masterfalcon
Look for changes marked with:

Code: Select all

// SJS

Re: [Solved]Glew should be external to Ogre rather than embe

Posted: Sun Oct 27, 2013 3:01 am
by scrawl
I see now. Seems to have been done pre version control or something so didn't show up in the history I guess.
I'll investigate if we can do this in a better way.

Re: [Solved]Glew should be external to Ogre rather than embe

Posted: Thu Nov 07, 2013 6:14 am
by scrawl
I've come to the conclusion that it's possible, but I'm afraid I don't know the code well enough to do it cleanly. And I'm not really comfortable when changing the low level GLX code that has been untouched for ages and "just works".
So I created a ticket in case a more experienced person wants to do it.