OpenGL libraries used in VSP

[João Henrique Vasconcelos]

Hi everyone,

Does anyone know what versions of the libglew-dev, libfltk1.3-dev and libglm-dev are needed to properly compile VSP?

I tried using my system's versions:

-> libglew-dev (2.1.0-4)

-> libfltk1.3-dev (1.3.5-3)

->  libglm-dev (0.9.9.8+ds-1)

It didn't work.

I then changed the build script to use the versions bundled with VSP and this yielded:

[393/398] Linking CXX shared library lib/libsdai_ap203.so.2.0.0

[394/398] Creating library symlink lib/libsdai_ap203.so.2 lib/libsdai_ap203.so

[395/398] Linking CXX executable bin/p21read_sdai_ap203

[396/398] Linking CXX executable bin/lazy_sdai_ap203

[397/398] Linking CXX executable bin/p21read_sdai_ap203-static

[398/398] Linking CXX executable bin/lazy_sdai_ap203-static

ninja: build stopped: subcommand failed.

Build using Make

-- Configuring done

-- Generating done

-- Build files have been written to: /home/limajoaohenrique1/OpenVSP/buildlibs

make: *** No targets specified and no makefile found.  Stop.

Any ideas on how to fix this?

[Rob McDonald]

The system libraries should be fine.

Are you on Ubuntu?  Is there a reason the *.deb file from the website doesn't work for you?

It looks like this build script is trying to be excessively clever.  It starts by trying to construct build files with Ninja and then building with Ninja.

That seems to progress for a while, but eventually it fails (can't really tell why).

However, since the failure is detected, it then attempts to start over with CMake to make  Makefiles -- which does not seem to go well.  Likely because there is a 95% complete Ninja build sitting right there.

I would recommend you edit the build script to dumb it down to only use Makefiles (not Ninja).

Some of our libraries have build systems that are subject to race conditions -- not all of their internal dependencies are explicitly marked.  So, when Ninja or Make try to do a parallel build, sometimes thread B progresses to where it needs the result of thread A before thread A is done.  This causes the build to fail.

The easy solution is to go back to the same directory and start 'make' again.  It will pick up where it left off and hopefully make it past the error this time.  Sometimes you have to delete the errant library (I don't know why this works).  Sometimes running with fewer parallel threads works -- say -j2 or -j4 instead of -j8.  The most conservative (and slowest) fix is to not run parallel at all.

Your build above hasn't even gotten to building OpenVSP yet (to know whether the libraries are going to work or fail).  It is failing during the step where we build all non-system libraries.  

Rob

--
You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/008383bf-e631-4b0a-945a-1fb173b8a8dcn%40googlegroups.com.

[cibinj...@gmail.com]

Like Rob said, I wrote up the build script to be a bit too smart. Seems like I hadn't come across these errors during testing.

I've now updated it to use good ol' single threaded Make for building. I've just finished testing it for a large number of threads [32] and it completes without errors, so that may not be the issue. If you wish to build in a parallel manner (using 2 or 4 threads), you can simply set the number of threads, inside the build script, in the variable named NumOfThreads. 

I tested it on an Ubuntu 18.04 system and the library versions I had were:

libglew-dev (2.0.0-5)

libfltk1.3-dev (1.3.4-6)

libglm-dev (0.9.9~a2-2)

These aren't the required versions and are just the ones available on my system for reference. Yours seem to be newer and should be fine.

I would suggest running the updated build script from the wiki in a clean folder. 

If it still doesn't work, the build script logs all output to a file named openvsp-build.log. This log file will have information on what causes the failure. Since it'll be extremely long, you could probably post it in pastebin.com, provide the link here, and we can take a look at it.

PS. I'm also curious about what OS you're running.

- Cibin

[João Henrique Vasconcelos]

Hi Rob and Cibin thanks for the quick response!

Answering the questions:

-  I'm on Debian 11;

- The .deb doesn't work due to libglew2.0 (legacy package) and libpython3.6 (ubuntu only?)

I did try to run the new version of the build script and I believe there's an issue with GLEW, here's the log, sorry for truncating, but it exceeded the size limit of pastebin.

Any idea on how to fix this?

Thank you both so much for the help,

João

[Rob McDonald]

What version of GLEW can you install through your distribution's package manager?

The best approach is to use the system-installed libraries wherever possible on Linux.  Not only is that the preferred way -- but it also means less things to debug for us.  The Debian maintainers have already done the work to get those dependencies to build and install on Debian.  We should use their work instead of duplicating it.

Rob

--

You received this message because you are subscribed to the Google Groups "OpenVSP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openvsp+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/2de4a9e1-9d69-499e-9ad7-db90c58a8c1bn%40googlegroups.com.

[João Henrique Vasconcelos]

Hi Rob,

The latest version of libglew for my system is libglew2.1. Do I have to change anything on the build script apart from setting DVSP_USE_SYSTEM_GLEW=true?

I already tried compiling it like that and it also didn't work. The screen is black (screenshot attached) and I can't see the geometries, despite that, the terminal show no errors.

Any idea on what might be going on?

João

[Rob McDonald]

No, all you need to do is set that flag to true.

Since you have gotten OpenVSP to compile (though it isn't quite working right) before, we should start from that configuration and only change one thing at a time...

Has any past version of OpenVSP worked for you before?  What has changed from there?

Assuming the black screen version is your first attempt...

It is most likely a problem with the OpenGL driver you are using.  Debian is notorious for being unfriendly to proprietary graphics drivers.  However, those are the ones that have the latest support for new hardware.

First, can you test that OpenGL works on your computer at all?  Try running glxgears from the command line -- does it produce a 3D rotating gear set?

Type in glxinfo and share the output here.

Rob

[João Henrique Vasconcelos]

Hi Rob,

This is not my first compilation, version 3.23 worked for me.

OpenGL seams to work fine (screenshots below).

Here's the output from glxinfo.

João

[Rob McDonald]

I'm sorry if you went through this already, but please help me to catch up.

When you compiled 3.23 -- did you use system-installed libraries or build yourself?

We should strive to change as little as possible from the last working situation.  To start with, we should look to make no changes to the build process.

While we updated a lot of libraries in the latest version, most of them should not have had any significant impact on how things work out -- even if the system library is an older version, it shouldn't really matter to OpenVSP.

If you build with the old setup and that results in the black screen, then that helps us narrow the possibilities of the problem.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/a7946c1d-ff3f-42e7-99f2-eaf880223929n%40googlegroups.com.

[João Henrique Vasconcelos]

Hi Rob,

I built 3.23 with the system libraries following the tutorial not using the build script. I then tried updating to 3.24 and have been having these issues.

I have now also tried building VSP with the 3.23 release from github. When using local libs I have the same issue of the black window, using the VSP libs I have the following error:

/usr/bin/ld: /usr/bin/ld: CMakeFiles/visualinfo.dir/src/visualinfo.c.oCMakeFiles/glewinfo.dir/src/glewinfo.c.o: undefined reference to symbol ': undefined reference to symbol 'XDestroyWindowXDestroyWindow''

/usr/bin/ld/usr/bin/ld: : /usr/lib/x86_64-linux-gnu/libX11.so.6/usr/lib/x86_64-linux-gnu/libX11.so.6: error adding symbols: : error adding symbols: DSO missing from command lineDSO missing from command line

collect2: error: ld returned 1 exit status

collect2: error: ld returned 1 exit status

make[5]: *** [CMakeFiles/glewinfo.dir/build.make:106: glewinfo] Error 1

make[4]: *** [CMakeFiles/Makefile2:129: CMakeFiles/glewinfo.dir/all] Error 2

make[4]: *** Waiting for unfinished jobs....

make[5]: *** [CMakeFiles/visualinfo.dir/build.make:106: visualinfo] Error 1

make[4]: *** [CMakeFiles/Makefile2:183: CMakeFiles/visualinfo.dir/all] Error 2

make[3]: *** [Makefile:160: all] Error 2

make[2]: *** [CMakeFiles/GLEW.dir/build.make:132: GLEW-prefix/src/GLEW-stamp/GLEW-build] Error 2

make[1]: *** [CMakeFiles/Makefile2:302: CMakeFiles/GLEW.dir/all] Error 2

make: *** [Makefile:103: all] Error 2

João

[Rob McDonald]

Stop trying to build with the local libraries.

The build worked before with the system libraries -- it is easiest to move forward from there.

The local library build seldom gets tested on Linux because nobody uses them -- they always use the system installed libraries wherever possible.

This is overwhelmingly likely a bug introduced by the OpenVSP team -- it has little or nothing to do with the libraries.

In particular, the new FLTK supports high-DPI support for modern monitors.  To work best, this requires a recent version of FLTK.  However, it should gracefully fall back to normal behavior as required.

Hopefully Justin can try to look at a Linux VM with matching system libraries to try to recreate this.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/d03b0666-928d-4497-8e19-53cc841f70a0n%40googlegroups.com.

[jvgr...@gmail.com]

I'll setup a Debian 11 VM to try to replicate this issue. I may need more details about your system libraries but I'll start by matching the ones you listed above. 

-Justin 

[João Henrique Vasconcelos]

Thank you so much!

Please let me know of any more details about my system libraries you may need. 

João

[jvgr...@gmail.com]

João,

The build I setup on my Debian 11 VM appears to be mostly working as expected. The VSP screen flickers black for a split second when I launch the program but otherwise shows the main window without issue. However, the geometry does appear faint in the main VSP window. This is something that I noticed on another Linux distribution when testing the 3.24.0 release that was likely related to the new graphics library versions. I was able to fix it by selecting a different graphics controller for the VM but all the ones I've tried for this Debian setup result in the same behavior. I'm not sure if this is directly related to the black screen issue but it is strange.  

Here are the system libraries I installed:

• Python 3.9.2
• git 2.30.2
• cmake 3.18.4
• libxml2-dev 2.9.10
• libfltk1.3-dev 1.3.5
• libglew-dev 2.1.0
• g++ 2.10.1
• gcc 2.10.1
• libcpptest-dev 1.0.8
• libjpeg-dev 62.3.0
• libglm-dev 0.9.9.8
• libcminpack-dev 1.3.6
• libeigen3-dev 3.3.9

Do those match what you have? It's possible you have the correct versions installed but VSP can't find them so is using the packages that are bundled with it. If you look in the directory of the libraries you built you will see another folder for each library that is built. 

Thanks,

Justin 

[João Henrique Vasconcelos]

Hi Justin,

The libs should be fine:

• cmake is already the newest version (3.18.4-2).
• libcminpack-dev is already the newest version (1.3.6-4).
• doxygen is already the newest version (1.9.1-1).
• libfltk1.3-dev is already the newest version (1.3.5-3).
• g++ is already the newest version (4:10.2.1-1).
• git is already the newest version (1:2.30.2-1).
• git-gui is already the newest version (1:2.30.2-1).
• libglew-dev is already the newest version (2.1.0-4+b1).
• libglm-dev is already the newest version (0.9.9.8+ds-1).
• graphviz is already the newest version (2.42.2-5).
• libjpeg-dev is already the newest version (1:2.0.6-4).
• libxml2-dev is already the newest version (2.9.10+dfsg-6.7).
• python3-dev is already the newest version (3.9.2-3).
• swig is already the newest version (4.0.2-1).
• texlive-latex-base is already the newest version (2020.20210202-3).

My Buildlibs folder looks like this:

CMakeCache.txt  cmake_install.cmake  CPPTEST-prefix  EXPRPARSE-prefix  Makefile         TRIANGLE-prefix

CMakeFiles      CODEELI-prefix       EIGEN-prefix    LIBIGES-prefix    STEPCODE-prefix  VSP_Libraries_Config.cmake

I'm not seeing any issues here either :|

Could you try running the compiled version I generated on your VM to see if it's a VSP issue or my something in my system?

A possible fix to these install issues would be a docker image for VSP, do you know if one is available? If not I could try setting it up. 

Thanks again for helping me with this, I love the software you guys make!

Best,

João

[jvgr...@gmail.com]

The version you generated works completely fine on my VM as far as I can tell. The main VSP window comes up as expected. It seems like your build is setup correctly so I'm still not sure what is going on here. 

Have you tried compiling 3.23.0 with the libraries you listed above, or did you just have it working before updating each of those to the latest version? If you updated the libraries after you built a working 3.23.0 you may want to retry compiling 3.23.0 to make sure it still works. 

I'm not sure if this would provide us any additional information but it could be worth trying a Debug build instead of Release. You'd just need to set the DCMAKE_BUILD_TYPE flag to "Debug" when building both the libraries and VSP. In a release build, the program will try to just pass through exceptions and keep going as far as possible. If there is an error that occurs when the graphics process fails to initialize the debug build might report something that explains what is happening. 

I'm not particularly familiar with docker images so I don't have any recommendations there. 

Wish I could be more helpful but hopefully we get this solved soon!

-Justin 

  

[João Henrique Vasconcelos]

Thanks for running it!

It seams it's something in my system. 

I had it working and then updated everything (including running sudo apt-get upgrade on the libs) to 3.24. I have also tried installing 3.23 with these current versions and I have the same issue. 

I will try compiling the DCMAKE_BUILD_TYPE=Debug;

Just updating some things I recently found:

- The VSPAero viewer works just fine, which is odd.
- The error is: libGL error: MESA-LOADER: failed to retrieve device information;

- I built a docker image with ubuntu 20.04 using the .deb available in the website and it has the same error.

Is there a way for me to point Mesa to the device information file during install?

Best,

João

[Rob McDonald]

I believe MESA is trying to retrieve the device information from your graphics card -- it is not a file that has anything to do with OpenVSP.

The OpenVSP API has many versions -- they started with 1.0 and have progressed over the last ~30 years as graphics technology has advanced.

In order to deal with this, you need a tool to figure out what capabilities a certain OS, driver, and graphics card have.  OpenVSP does this with GLEW - the GL Extension Wrangler.

When you load OpenVSP, we make a call to GLEW to ask the OS to ask the OpenGL Driver what capabilities it has.  We then check to make sure your system can handle everything we need.  We are very modest in our requirements -- we do not use anything that would be considered new, fancy, or exotic.  However, we do need OpenGL 2.1 (I think)....

That said, if your system fails the test, it should fail to load OpenVSP and should dump out a message that the OpenGL version was not sufficient.

The fact that yours runs anyway -- but fails to display -- is the really weird part.

We need GL_ARB_framebuffer_object to take screen shots -- but we will run without that, only screenshots are disabled.  That option should be available in OpenGL 2.1 or later...

We check for GL_VERSION_2_0 to enable GLSL - the OpenGL Shader Language.  However, I don't think we use shaders for anything other than texture mapping -- again, your main window should work, but textures would not.

We check for GL_ARB_vertex_buffer_object and glGenBuffers -- and OpenVSP should print an error and die if those aren't available.

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/1338f8d2-efe4-4116-b312-7d5b1d17f1c2n%40googlegroups.com.

[João Henrique Vasconcelos]

Hi Rob, Justin and Cibin,

Just an update, Debian and intel upgraded a bunch of drivers and I tried installing VSP again and now it works like a charm!

:)

Thank you all so much for the help! There was something seriously weird on my machine. Looking forward to the 3.25 upgrade -- hopefully it's smooth sailing from here on out.

Best,

João

[Rob McDonald]

Great!  I love when someone else fixes my problems....

Rob

To view this discussion on the web visit https://groups.google.com/d/msgid/openvsp/22124b87-d9bb-4de7-a514-57dc8705dbb6n%40googlegroups.com.