Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

problem of 0.82 samples

Help
Albert
2004-10-14
2013-04-17
  • Albert
    Albert
    2004-10-14

    I tried to run the 0.82 samples, on a windows XP machine, with EVC++4 SP4.

    When I compiled hello.c, it said could not find ug.h.  There is nothing about ug.h on your developer guide page. I found ug.h in 0.82 src folder (should ug files go with 0.82 samples?). However, there is a readme file telling me that ug for X11 is mostly done but for win32 unstarted (is EVC++ running under X11 or win32 only?). I included that ug anyway, and it complied successfully. 

    When I built the hello file, it said could not find libGLES_CM.lib. This time I found a whole bunch of libGLES_CM.lib files in 0.82 bin folder but was not sure which one I should use. I tried to build a file on emulator  using libGLES_CM.lib from /bin/emu/debug/ folder, didn't work,  here is the error message:
    *************************************
    Linking...
    hello.obj : error LNK2019: unresolved external symbol _ugSwapBuffers@4 referenced in function _display
    hello.obj : error LNK2019: unresolved external symbol _ugMainLoop@4 referenced in function _main
    hello.obj : error LNK2019: unresolved external symbol _ugDisplayFunc@8 referenced in function _main
    hello.obj : error LNK2019: unresolved external symbol _ugCreateWindow@28 referenced in function _main
    hello.obj : error LNK2019: unresolved external symbol _ugInit@0 referenced in function _main
    ..\..\bin\emu\Debug/hello.exe : fatal error LNK1120: 5 unresolved externals
    Error executing link.exe.

    hello.exe - 6 error(s), 0 warning(s)
    *************************************
    then I tried to build a file on device using libGLES_CM.lib from /bin/arm/debug/ didn't work either.

    Thanks for any help.

     
    • Hi there,

      You are right, the README is misleading, it's still the original one by David Blythe. I need to remove it.

      Besides that, however, I just tried using the current downloads (ogl-es-bin-0.83.zip and ogles-0.82-samples.zip) and was unable to reproduce the problem. Anyway, here's what I did, maybe you can tell me which part was unclear so I know what to change in the rest of the documentation:

      - unzip the main distribution; this will create a folder structure having bin/ include/ etc. You could also unpack the source distribution and build the OGLES and ug from the workspace, which will create the libraries into bin/

      - unzip the samples distribution. This should result in a folder redbook/ which you can copy at the same level as bin/ and include/ If you look into the README.txt (top level), it shows you how the resulting tree should look like.

      - Now all you have to do is to open the workspace redbook/evc4/redbook.vcw, and all the projects should build without problem. (As said, I just did on a machine different from my dev box)

      If you have ug.h directly inside src there was a problem with either the download or the unzipper you were using. The correct location for ug.h is inside include.

      Hope that helps,
      HM

       
    • Albert
      Albert
      2004-10-14

      It worked. Thanks!
      I think my problem was I used the wrong ug.h under dist/ug/ in src-83a-zip file. Please check it out and remove it if it is of no use.

       
    • Done. Will be updated in next release.