Write your own Einstein@home screensaver

Forums › Cruncher's Corner

robertmiles
robertmiles
Joined: 8 Oct 09
Posts: 127
Credit: 29370881
RAC: 23831

In C++, a void function has a

17 Feb 2012 5:07:00 UTC
Message 78198 in response to message 78197
(moderation:
    )

    In C++, a void function has a different meaning. It means that the function returns nothing at all, and therefore no other type is appropriate for describing the format of what it returns.

    Mike Hewson
    Mike Hewson
    Moderator
    Joined: 1 Dec 05
    Posts: 6588
    Credit: 317195357
    RAC: 365082

    RE: In C++, a void function

    17 Feb 2012 5:27:28 UTC
    Message 78199 in response to message 78198
    (moderation:
      )

      Quote:
      In C++, a void function has a different meaning. It means that the function returns nothing at all, and therefore no other type is appropriate for describing the format of what it returns.


      True, there void is the absence of a return value, rather than the type of an existing return value. I am discussing 'pointer to void' or 'void pointer' .... this is one of many confusable uses of that word.

      Cheers, Mike.

      ( edit ) So 'void*' is not the absence of a pointer, but a pointer with insufficient definition of the address space it refers to.

      ( edit ) To be arcane for a moment : C++ destructor syntax will be in error if you indicate void for either arguments or return value, as will void as a return value for a constructor. So for functions that are neither destructors nor constructors you can use void to indicate 'nothing at all', but the only way to indicate 'nothing at all' for constructor returns or destructor arguments and returns is white space ( or no characters whatsoever ). The semantic truth is that constructors and destructors never return values, and you can't give arguments to a destructor.

      I have made this letter longer than usual because I lack the time to make it shorter ...

      ... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

      Oliver Behnke
      Oliver Behnke
      Moderator
      Administrator
      Joined: 4 Sep 07
      Posts: 984
      Credit: 25171438
      RAC: 34

      RE: #2 As mentioned, use

      20 Feb 2012 15:15:33 UTC
      Message 78200 in response to message 78196
      (moderation:
        )

        Quote:


        #2 As mentioned, use wglGetProcAddress sprinkled throughout the code to disclose, at runtime, the needed call targets and preferably after using glGetString(GL_EXTENSIONS) to validate the desired ability at all, plus check for NULL pointer returns etc. Hide this OS dependency behind some class interface, combined with conditional compilation using #ifdef and _WIN32_ et al. Notably this has to be enacted for each distinct OpenGL context, so in our case repeated with every resize event at least.

        #3 Same as #2 but via SDL's SDL_GL_GetProcAddress(). SDL automagically includes the wgl header(s) and uses wglGetProcAddress under it's hood anyway.

        For my money I'd be happiest to go with solution number 3, I can think of a number of suitable variants on that theme to test. Most importantly I wouldn't want to prejudice any current success with non-windows builds.

        ??? Views ???

        Depends, if option 3 is feasible for Win32 builds only, go for it. If not, I'd go for option 2 as well. Another possibility would be to "convince" the compiler/linker to accept the name-mangled version incarnations of those functions. You have no idea what the BRP4/CUDA Win32-build involves in that regard ;-)

        Let me try my usual attack vector on glext.h...

        Oliver

        Einstein@Home Project

        Oliver Behnke
        Oliver Behnke
        Moderator
        Administrator
        Joined: 4 Sep 07
        Posts: 984
        Credit: 25171438
        RAC: 34

        Minor comment: please include

        20 Feb 2012 15:57:17 UTC
        Message 78201
        (moderation:
          )

          Minor comment: please include headers used for the implementation only in the (private) implementation (cpp-file), not the (public) interface (h-file).

          Oliver

          Einstein@Home Project

          Oliver Behnke
          Oliver Behnke
          Moderator
          Administrator
          Joined: 4 Sep 07
          Posts: 984
          Credit: 25171438
          RAC: 34

          Mike, if you have, please

          20 Feb 2012 16:16:40 UTC
          Message 78202
          (moderation:
            )

            Mike, if you have, please push the latest commits. I just tried the solar system branch at 4aa4ce7cf and it exhibits a number of issues. I partly fixed them but it takes too long for me to get the actual stuff I wanna test :-)

            Thanks,
            Oliver

            Einstein@Home Project

            Mike Hewson
            Mike Hewson
            Moderator
            Joined: 1 Dec 05
            Posts: 6588
            Credit: 317195357
            RAC: 365082

            RE: Depends, if option 3 is

            21 Feb 2012 0:16:51 UTC
            Message 78203 in response to message 78200
            (moderation:
              )

              Quote:

              Depends, if option 3 is feasible for Win32 builds only, go for it. If not, I'd go for option 2 as well. Another possibility would be to "convince" the compiler/linker to accept the name-mangled version incarnations of those functions. You have no idea what the BRP4/CUDA Win32-build involves in that regard ;-)

              Let me try my usual attack vector on glext.h...

              Oliver


              Thanks for your assistance on this Oliver. :-)

              Now I'm currently writing along the lines of option 3, with conditional inclusion ( ie. Win32 build ) of a new class that wraps the SDL_GL_GetProcAddress() calls that query the ICD for pointers ( one round per context ), and wraps the indirect calls ( ie. invoking said function pointers ). This static class acquires the functions pointers when asked - for resize/change of context. Other classes that need post v1.1 functions are sprinkled with conditional code for either build type ie. compile a call to the original OpenGL function on linux/mac which later gets a static link to a library export, or compile a wrapped version to be statically linked via this new class on Win32.

              [ It's a bit messy, as every call of this nature ( ~ 25 of them ) in my general code needs fiddling, but ensures that the linux/mac versions don't compile any code that is relevant to the Win32 problem. Alas there's call overheads for Win32 here due to inevitable indirection somewhere in any design that solves this issue. But at least an OO approach can centralise some aspects. None of this is pretty, and I'm effectively faking the GLEW approach on a far more limited scale. No matter what you do, one can't statically ensure the dynamic presence of a feature on a cross-platform .... :-) ]

              Quote:
              Minor comment: please include headers used for the implementation only in the (private) implementation (cpp-file), not the (public) interface (h-file).


              Excellent idea. I remember once having an 'animated' discussion with a tutor on that very point .... :-0

              Quote:
              Mike, if you have, please push the latest commits. I just tried the solar system branch at 4aa4ce7cf and it exhibits a number of issues. I partly fixed them but it takes too long for me to get the actual stuff I wanna test :-)


              Will do shortly. I'll push the repo state which was extant at the time of my Well guys, this cross platform build just ... post, and other commits on my later attempts ( that cleanly compile ).

              Cheers, Mike.

              I have made this letter longer than usual because I lack the time to make it shorter ...

              ... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

              Mike Hewson
              Mike Hewson
              Moderator
              Joined: 1 Dec 05
              Posts: 6588
              Credit: 317195357
              RAC: 365082

              Related observations on a

              21 Feb 2012 2:35:19 UTC
              Message 78204
              (moderation:
                )

                Related observations on a glGetString(GL_EXTENSIONS) query approach :

                - you get a long string of type const GLubyte* returned

                - you have to cast/transform that to something more C/C++-ish

                - then parse the space-separated list of extension names ( thus such names don't contain spaces )

                - look for what you want within that

                However due to the historical progression of a given extension through to ARB approved status - and not all achieve that, survival of the fittest etc - the string representing an enumerant(s) for said extension typically has several variants ( generally denoting such status, who wrote it, system dependencies, is it experimental etc ). My reading suggests one ought assume that this will vary per OpenGL version ie. can you code to account for a given extension's particular development history ?? Is it always good/safe enough to accept a sub-string match ?? Thus my reading also indicates this is now a deprecated technique.

                For that matter using :
                [pre]wglGetProcAddress(someFunctionNameInStringForm)[/pre]
                and by implication SDL_GL_GetProcAddress(), isn't bullet proof either as 'someFunctionNameInStringForm' may have evolved too .... eg. glActiveTextureEXT, glActiveTextureARB and glActiveTexture .... hmmm, I think we will be revisiting the downstream side of Win32 mannerisms for a while yet.

                Cheers, Mike.

                I have made this letter longer than usual because I lack the time to make it shorter ...

                ... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

                Oliver Behnke
                Oliver Behnke
                Moderator
                Administrator
                Joined: 4 Sep 07
                Posts: 984
                Credit: 25171438
                RAC: 34

                RE: For that matter using

                21 Feb 2012 8:46:02 UTC
                Message 78205 in response to message 78204
                (moderation:
                  )

                  Quote:
                  For that matter using :
                  [pre]wglGetProcAddress(someFunctionNameInStringForm)[/pre]
                  and by implication SDL_GL_GetProcAddress(), isn't bullet proof either as 'someFunctionNameInStringForm' may have evolved too .... eg. glActiveTextureEXT, glActiveTextureARB and glActiveTexture

                  Yuk, awful "design"... But maybe I can get us around this issue. I just need to get my hands on the commit you used to start out your option 3 approach...

                  Best,
                  Oliver

                  Einstein@Home Project

                  Mike Hewson
                  Mike Hewson
                  Moderator
                  Joined: 1 Dec 05
                  Posts: 6588
                  Credit: 317195357
                  RAC: 365082

                  RE: RE: For that matter

                  21 Feb 2012 10:55:03 UTC
                  Message 78206 in response to message 78205
                  (moderation:
                    )

                    Quote:
                    Quote:
                    For that matter using :
                    [pre]wglGetProcAddress(someFunctionNameInStringForm)[/pre]
                    and by implication SDL_GL_GetProcAddress(), isn't bullet proof either as 'someFunctionNameInStringForm' may have evolved too .... eg. glActiveTextureEXT, glActiveTextureARB and glActiveTexture

                    Yuk, awful "design"... But maybe I can get us around this issue. I just need to get my hands on the commit you used to start out your option 3 approach...

                    Best,
                    Oliver


                    Yeah, I'll look at seeing if/where ARB publishes a list of the enumerants that describe the evolution of a given extension.

                    OK, my project state that divulged the win32 link issue is 84bd55a978 ..... I've also attended to the header issue and remarked out some of the constellations to speed up the build. This commit builds a linux executable cleanly that behaves as expected. I'm not paying attention to Mac at present.

                    For comparison this is the win32 link failure as logged :

                    [pre]Buffer_OBJ.o: In function `_ZN10Buffer_OBJ7releaseEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Buffer_OBJ.cpp:47: undefined reference to `_glDeleteBuffers@8'
                    Buffer_OBJ.o: In function `_ZN10Buffer_OBJ7acquireEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Buffer_OBJ.cpp:43: undefined reference to `_glGenBuffers@8'
                    Buffer_OBJ.o: In function `_ZN10Buffer_OBJD2Ev':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Buffer_OBJ.cpp:47: undefined reference to `_glDeleteBuffers@8'
                    Buffer_OBJ.o: In function `_ZN10Buffer_OBJD0Ev':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Buffer_OBJ.cpp:47: undefined reference to `_glDeleteBuffers@8'
                    Buffer_OBJ.o: In function `_ZN10Buffer_OBJD1Ev':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Buffer_OBJ.cpp:47: undefined reference to `_glDeleteBuffers@8'
                    Constellations.o: In function `_ZN14Constellations6renderEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:1925: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:1958: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:1941: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:1953: undefined reference to `_glBindBuffer@8'
                    Constellations.o: In function `_ZN14Constellations15loadIndexBufferEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:2088: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:2093: undefined reference to `_glBufferData@16'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:2095: undefined reference to `_glMapBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:2152: undefined reference to `_glUnmapBuffer@4'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:2153: undefined reference to `_glBindBuffer@8'
                    Constellations.o: In function `_ZN14Constellations16loadVertexBufferEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:2037: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:2044: undefined reference to `_glBufferData@16'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:2046: undefined reference to `_glMapBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:2077: undefined reference to `_glUnmapBuffer@4'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Constellations.cpp:2078: undefined reference to `_glBindBuffer@8'
                    Globe.o: In function `_ZN5Globe20loadPolarIndexBufferER10Buffer_OBJNS_4poleE':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:346: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:355: undefined reference to `_glBufferData@16'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:359: undefined reference to `_glMapBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:395: undefined reference to `_glUnmapBuffer@4'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:396: undefined reference to `_glBindBuffer@8'
                    Globe.o: In function `_ZN5Globe20loadWaistIndexBufferEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:307: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:316: undefined reference to `_glBufferData@16'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:319: undefined reference to `_glMapBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:337: undefined reference to `_glUnmapBuffer@4'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:338: undefined reference to `_glBindBuffer@8'
                    Globe.o: In function `_ZN5Globe6renderEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:195: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:211: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:219: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:238: undefined reference to `_glBindBuffer@8'
                    Globe.o:/home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:245: more undefined references to `_glBindBuffer@8' follow
                    Globe.o: In function `_ZN5Globe16loadVertexBufferEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:277: undefined reference to `_glBufferData@16'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:280: undefined reference to `_glMapBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:298: undefined reference to `_glUnmapBuffer@4'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Globe.cpp:299: undefined reference to `_glBindBuffer@8'
                    GridGlobe.o: In function `_ZN9GridGlobe6renderEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:143: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:154: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:164: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:186: undefined reference to `_glBindBuffer@8'
                    GridGlobe.o:/home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:187: more undefined references to `_glBindBuffer@8' follow
                    GridGlobe.o: In function `_ZN9GridGlobe28loadPrimeMeridianIndexBufferEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:336: undefined reference to `_glBufferData@16'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:339: undefined reference to `_glMapBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:361: undefined reference to `_glUnmapBuffer@4'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:362: undefined reference to `_glBindBuffer@8'
                    GridGlobe.o: In function `_ZN9GridGlobe19loadGridIndexBufferEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:251: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:269: undefined reference to `_glBufferData@16'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:272: undefined reference to `_glMapBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:319: undefined reference to `_glUnmapBuffer@4'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:320: undefined reference to `_glBindBuffer@8'
                    GridGlobe.o: In function `_ZN9GridGlobe16loadVertexBufferEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:212: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:218: undefined reference to `_glBufferData@16'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:221: undefined reference to `_glMapBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:242: undefined reference to `_glUnmapBuffer@4'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:243: undefined reference to `_glBindBuffer@8'
                    GridGlobe.o: In function `_ZN9GridGlobe31loadCelestialEquatorIndexBufferEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:378: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:384: undefined reference to `_glBufferData@16'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:387: undefined reference to `_glMapBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:410: undefined reference to `_glUnmapBuffer@4'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/GridGlobe.cpp:411: undefined reference to `_glBindBuffer@8'
                    HUDImage.o: In function `_ZN8HUDImage6renderEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/HUDImage.cpp:112: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/HUDImage.cpp:136: undefined reference to `_glBindBuffer@8'
                    HUDImage.o: In function `_ZN8HUDImage16loadVertexBufferEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/HUDImage.cpp:247: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/HUDImage.cpp:258: undefined reference to `_glBufferData@16'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/HUDImage.cpp:261: undefined reference to `_glMapBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/HUDImage.cpp:280: undefined reference to `_glUnmapBuffer@4'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/HUDImage.cpp:281: undefined reference to `_glBindBuffer@8'
                    Pulsars.o: In function `_ZN7Pulsars6renderEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Pulsars.cpp:2005: undefined reference to `_glBindBuffer@8'
                    Pulsars.o: In function `_ZN7Pulsars7prepareEN18SolarSystemGlobals14render_qualityE':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Pulsars.cpp:1946: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Pulsars.cpp:1952: undefined reference to `_glBufferData@16'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Pulsars.cpp:1956: undefined reference to `_glMapBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Pulsars.cpp:1982: undefined reference to `_glUnmapBuffer@4'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Pulsars.cpp:1983: undefined reference to `_glBindBuffer@8'
                    Supernovae.o: In function `_ZN10Supernovae6renderEv':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Supernovae.cpp:339: undefined reference to `_glBindBuffer@8'
                    Supernovae.o: In function `_ZN10Supernovae7prepareEN18SolarSystemGlobals14render_qualityE':
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Supernovae.cpp:280: undefined reference to `_glBindBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Supernovae.cpp:286: undefined reference to `_glBufferData@16'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Supernovae.cpp:290: undefined reference to `_glMapBuffer@8'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Supernovae.cpp:316: undefined reference to `_glUnmapBuffer@4'
                    /home/mike/projects/E@HSS/windows_build/graphicsframework/src/solarsystem/Supernovae.cpp:317: undefined reference to `_glBindBuffer@8'
                    collect2: ld returned 1 exit status
                    make: *** [solarsystem_Einstein_LVC] Error 1
                    ************************************
                    Error detected! Stopping build!
                    Tue Feb 21 21:38:47 EST 2012
                    ************************************[/pre]
                    Cheers, Mike.

                    ( edit ) Actually that's way more than 25 calls to fiddle with ..... :-(

                    I have made this letter longer than usual because I lack the time to make it shorter ...

                    ... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

                    Mike Hewson
                    Mike Hewson
                    Moderator
                    Joined: 1 Dec 05
                    Posts: 6588
                    Credit: 317195357
                    RAC: 365082

                    The Full Horror ... :-) By

                    22 Feb 2012 23:03:27 UTC
                    Message 78207
                    (moderation:
                      )

                      The Full Horror ... :-)

                      By way of filling in/out the detail of what as been discussed, here is an excerpt from OpenGL SuperBible: Comprehensive Tutorial and Reference ( Fifth Edition ) by Richard S. Wright Jr.; Nicholas Haemel; Graham Sellers; Benjamin Lipchak and published by Addison-Wesley Professional in 2010 ( Print ISBN-13: 978-0-321-71261-5 ). From the start of chapter 13 "OpenGL Implementations on Windows" :

                      Quote:

                      OpenGL Implementations on Windows

                      OpenGL first became natively available for the Win32 platform with the release of Windows NT version 3.5. Later, it was released as an add-on for Windows 95 and then began shipping as part of the Windows 95 operating system with the OSR2 release. OpenGL is now a native API on any full Windows platform (Windows XP, Vista, Win 7, Server 2003, Server 2008, and so on), with its functions exported through the opengl32.dll library. Many different levels of OpenGL hardware are available for Windows platforms, from chipsets with part of OpenGL done in software, to entry level video cards, to screaming fast workstation class cards. You should be aware that your application may be running on any one of these platforms.

                      Microsoft’s OpenGL

                      Microsoft currently ships a generic software implementation of OpenGL as the default version with its operating systems. If no 3D hardware exists on a system or if the appropriate hardware drivers have not been installed, the Microsoft version of the OpenGL implementation is the one you will get. Microsoft has not contributed to OpenGL in many years. The version of OpenGL supported on most Microsoft operating systems is 1.0 or 1.1. This is not sufficient for most modern 3D applications. In addition, a software implementation is often not fast enough to support any meaningful graphics. For this reason, many OpenGL applications will check the supported version of OpenGL and decide to not run if a newer version of the OpenGL specification is not supported.

                      Modern Graphics Drivers

                      The Installable Client Driver (ICD) was the original hardware driver interface provided for Windows NT. The ICD must implement the entire OpenGL pipeline using a combination of software and the specific hardware for which it was written. Creating an ICD from scratch is a considerable amount of work for a vendor to undertake.

                      ICDs drop in and work with Microsoft’s OpenGL implementation. Applications linked to opengl32.dll are automatically passed through by Microsoft to an installed ICD driver for OpenGL calls. Because a common interface exists, drivers and applications do not have to be recompiled to take advantage of OpenGL hardware on a system, even if it changes. The ICD is actually a part of the display driver and does not affect the existing opengl32.dll system DLL. This driver model provides the vendor with the most opportunities to optimize its driver and hardware combination.

                      All major hardware vendors currently use the ICD model. If a given piece of hardware does not support some part of OpenGL natively, the ICD must implement the missing functionality. In this way, all ICD drivers should support the entire feature set for the version(s) of OpenGL exported by that driver.

                      Because the opengl32.dll portion of the OpenGL call stack belongs to the operating system, applications and drivers have to use the library that ships with a given operating system. Because the Microsoft software implementation only supports either OpenGL 1.0 or 1.1, the entrypoints for the opengl32.dll also only support the same versions of OpenGL. This has created a dilemma as OpenGL has grown, evolved, and added new functionality. We have come a long way in the last 18 years since OpenGL 1.1 was released.

                      Because a display driver cannot modify the opengl32.dll to add new features for the current version, OpenGL needed a way to allow applications to access parts that were not exposed by the opengl32.dll. This is done through the extension mechanism and an interface that allows applications to get the entrypoint address for any supported interfaces. Not only does this work for the newer versions of OpenGL, but this mechanism can be used by hardware vendors to extend the feature set of OpenGL as we see in a few pages.

                      OpenGL on Vista and Windows 7

                      OpenGL on Vista and Windows 7 works in much the same way as on earlier operating systems. The operating system still has a version of the opengl32.dll, and applications call OpenGL functions much the same way. But on these newer operating systems, desktop compositing is used to create the final image a user sees. On previous operating systems each window rendered into the desktop pixels it owned. But on Vista and Win7, each window renders into a surface that is handed off a new component of the operating system called the Desktop Window Manager, or DWM.

                      Each window surface is “presented†to the DWM, which directly interfaces with the graphics kernel driver. DWM takes all the windows from each running 2D and 3D application and uses the GPU to combine them together with desktop components to create a final image that the user sees. This new mechanism separates the render surfaces for each window and allows the operating system to take advantage of advanced GPU capabilities to provide cool blending and 3D effects.

                      The version of opengl32.dll on Vista and Win7 still only supports OpenGL 1.1. However, Microsoft has implemented an OpenGL to D3D emulator that supports OpenGL version 1.4. This implementation looks like an ICD, but only shows up if a real ICD is not installed. As of the initial release of Vista, there is no way to turn this implementation on manually. Only a few games (selected by Microsoft) are “tricked†into seeing this implementation. Vista, like XP, does not ship with ICD drivers on the distribution media. Once a user downloads a new display driver from a vendor’s Web site, however, she will get a true ICD-based driver and full OpenGL support in both windowed and full-screen games.

                      Extended OpenGL

                      Before we get into the intricacies of using wgl, let’s look at how to extend the core functionality of OpenGL and wgl. Because the core opengl32.dll only exposes a minimum set of entrypoints, you need to know how to get at the newer functions to really make use of wgl and OpenGL. You learn two ways of dealing with extensions: using the interfaces directly and letting the GLEW library do some of the lifting for you.

                      An extension is any addition to a core version of OpenGL. Extensions are listed in the OpenGL extension registry on the OpenGL Web site. These extensions are written as difference specifications. That means the text of the extensions describes how the core OpenGL specification must be changed if the extension is supported.

                      There are three major classifications of extensions: vendor, EXT, and ARB. Vendor extensions are written and implemented on one vendor’s hardware. Initials representing the specific vendor are usually part of the extension name—“AMD†for Advanced Micro Devices or “NV†for NVIDIA. It is possible that more than one vendor might support a specific vendor extension, especially if it becomes widely accepted. EXT extensions are written together by two or more vendors. They often start their lives as a vendor-specific extensions. ARB extensions are an official part of OpenGL because they are approved by the OpenGL governing body, the Architecture Review Board (ARB). These extensions are often supported by all major hardware vendors and also start as vendor or EXT extensions.

                      This extension process may sound confusing at first. Hundreds of extensions currently are available! But new versions of OpenGL are often constructed from extensions programmers have found useful. In this way each extension gets its time in the sun. The ones that shine can be promoted to core; the ones that are less useful are not considered. This “natural selection†process helps to ensure only the most useful and important new features make it into a core version of OpenGL.

                      Using Extensions

                      Back in Chapter 2, “Getting Started,†you learned how to find out about what extensions are available on a given system. Extensions can have many different effects on OpenGL functionality. They can simply remove some restrictions currently in place. They can introduce new enumerants that can be used for things such as setting state. They can also add entirely new functions to the API. The only cases that require special attention are those where your application has to use new entrypoints.

                      On the Windows platform, you do not have direct access to the OpenGL driver. The OpenGL function calls in OpenGL 3.2 that were part of OpenGL 1.1 are routed through the opengl32.dll library. Because this DLL understands only OpenGL 1.1 entrypoints (function names), OpenGL drivers provide a way for you to get pointers to all of the newer OpenGL functions supported directly by the driver. The Windows OpenGL implementation has a function named wglGetProcAddress that allows you to retrieve a pointer to an OpenGL function supported by the driver:

                      PROC wglGetProcAddress(LPSTR lpszProc);

                      This function takes the name of an OpenGL function or extension function and returns a function pointer that you can use to call that function directly. For this to work, you must know the full function prototype for the function so you can create a pointer to it and subsequently call the function.

                      The number of extensions is large, especially when you add in the newer OpenGL core functionality and vendor-specific extensions. Complete coverage of all OpenGL extensions would require an entire book in itself (if not an encyclopedia!). When you have some time, take a look at the extension registry; a link is provided in Appendix A, “Further Reading.â€

                      Fortunately, the following two header files give you programmatic access to most OpenGL extensions:

                      #include
                      #include

                      These files can be found at the OpenGL extension registry Web site, but they are also maintained by most graphics card vendors (see their developer support Web sites) ... ... The wglext.h header contains a number of extensions that are Windows-specific, and the glext.h header contains both standard OpenGL extensions and many vendor-specific OpenGL extensions.


                      BTW - I see a potential Vista specific scenario/problem here.

                      Cheers, Mike.

                      I have made this letter longer than usual because I lack the time to make it shorter ...

                      ... and my other CPU is a Ryzen 5950X :-) Blaise Pascal

                      Comment viewing options

                      Select your preferred way to display the comments and click "Save settings" to activate your changes.

                      Forums › Cruncher's Corner