Debian 12 install issue

[Frank Sneeringer]

Hi All,

I posted a github issue but was suggested to ask here - please excuse the long post. 

I am having trouble installing OpenVSP on Debian 12.  

When using the .deb installer I get this error:  

:~/Downloads$ sudo dpkg -i OpenVSP-3.35.3-Ubuntu-22.04_amd64.deb Selecting previously unselected package openvsp. (Reading database ... 244741 files and directories currently installed.) Preparing to unpack OpenVSP-3.35.3-Ubuntu-22.04_amd64.deb ... Unpacking openvsp (3.35.3) ... dpkg: dependency problems prevent configuration of openvsp: openvsp depends on libpython3.10 (>= 3.10.0); however: Package libpython3.10 is not installed. dpkg: error processing package openvsp (--install): dependency problems - leaving unconfigured Errors were encountered while processing: openvsp

I then run:

sudo apt install python3-dev Reading package lists... Done Building dependency tree... Done Reading state information... Done python3-dev is already the newest version (3.11.2-1+b1). You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: openvsp : Depends: libpython3.10 (>= 3.10.0) but it is not installable E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

This shows a newer version (>= 3.10.0) installed but not recognized.

Is there some way to allow install with newer than called out dependency? I figured this would be allowed due to the dependency message I'm getting.

When compiling following the guide (https://openvsp.org/wiki/doku.php?id=ubuntu_instructions) I get this error:

From step 4 make -j8 finishWKS24266WKS24266ing lines are:

-- Set runtime path of "/home/frank/OpenVSP/buildlibs/STEPCODE-prefix/src/STEPCODE/../sc-install/bin/lazy_sdai_ap203" to "/usr/local/lib:$ORIGIN/../lib" -- Installing: /home/frank/OpenVSP/buildlibs/STEPCODE-prefix/src/STEPCODE/../sc-install/bin/lazy_sdai_ap203-static -- Set runtime path of "/home/frank/OpenVSP/buildlibs/STEPCODE-prefix/src/STEPCODE/../sc-install/bin/lazy_sdai_ap203-static" to "/usr/local/lib:$ORIGIN/../lib" -- Installing: /home/frank/OpenVSP/buildlibs/STEPCODE-prefix/src/STEPCODE/../sc-install/share/man/man1/fedex.1 -- Installing: /home/frank/OpenVSP/buildlibs/STEPCODE-prefix/src/STEPCODE/../sc-install/share/man/man1/exp2cxx.1 [ 97%] Completed 'STEPCODE' [ 97%] Built target STEPCODE make: *** [Makefile:91: all] Error 2

From cmake in step 5:

buildlibs -DCMAKE_BUILD_TYPE=Release -- The C compiler identification is GNU 12.2.0 -- The CXX compiler identification is GNU 12.2.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /usr/bin/cc - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found Doxygen: /usr/bin/doxygen (found version "1.9.4") found components: doxygen dot -- CMINPACK_LIBRARY /usr/lib/x86_64-linux-gnu/libcminpack.so -- Found CMINPACK: /usr/include/cminpack-1 -- Found Code-Eli version 0.3.6, and requested version 0.3.6 -- Found CodeEli: /home/frank/OpenVSP/buildlibs/CODEELI-prefix/src/CODEELI-build/include;/home/frank/OpenVSP/buildlibs/CODEELI-prefix/src/CODEELI/include (Required is at least version "0.3.6") -- Found CPPTest: /home/frank/OpenVSP/buildlibs/CPPTEST-prefix/include CMake Error at cmake/Finddelabella.cmake:10 (FIND_PATH): Could not find DELABELLA_INCLUDE_DIR using the following files: delabella.h Call Stack (most recent call first): external/CMakeLists.txt:18 (FIND_PACKAGE)

Please let me know if there's other info or logs that would be helpful for me to post. I'm very much a beginner at building programs so I'm not familiar with good troubleshooting methods.

Thanks,

Frank

[Rob McDonald]

Try re-running make in the buildlibs directory (step 4).

Do not run with -j8, just run make.  If it errors, try to run it again with 'make -k'

The -j8 says to run with 8 threads.  Some of the build process is not fully thread safe.  So, running without threads will take longer, but might have a better chance of finishing.

Running with '-k' will ignore errors and will 'keep going' with the process.  This might spew out an excess number of errors, but if some things can succeed after the failure, then it might make more progress.

Finally, when there is an error from a complex build step, it could be back several hundred lines.  It can be hard to tell.  So, getting the compilation to get as far as it can (as much success as it can) is good.  That way, the final error message will be as simple and short as possible.

In cas you didn't realize this, when you type 'make' a second (or third or ...) time, it tries to pick up where it left off.  Anything that succeeded before does not get re-run.  So, if you run 'make -k' (and assume it errors out) and then 'make', the second time should _only_ try to re-compile the files that failed.  I.e. it should only spit out the relevant error messages.

Finally, to create a complete log of a build, you can redirect both stdout and stderr to a file...

make &> buildlog.txt

Try attaching that.

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/f2897308-0ef6-4f2c-91f4-9c395f54261cn%40googlegroups.com.

[Frank Sneeringer]

Rob,

Thank you very much for the detailed explanation.  

I've attached the output from step 3, as well as the output from the make &> buildlog.txt command. After completing the first build/log command I also logged a make -k output to buildlog-k.txt, attached as well in case its helpful - much larger file though.

Is there any site or book you'd recommend to learn about these processes? 

Thanks for your help!

Frank

[Rob McDonald]

OK, I have a fragile workaround for you, but it should get you going...

Normally, in a CMake system, the source is one place and the build files are another very separate place.  This has the advantage that you can easily delete all the build files and start over -- and you haven't messed with your source at all.

For the libraries, the OpenVSP source includes the libs as *.zip files.  These get unzipped into place A in the build directory -- which then acts as a source directory.  The library is then built in place B in the build directory.  So this time, there are kinda two 'source' locations -- one in a 'build' location...

This workaround involves changing a file in the place where the library source is unzipped (in a build directory).  This will work fine, but if you delete the build directory, CMake will unzip the original files again -- and you'll have to make the same change again.  In the longer term, I'll be able to fix the version contained inside the *.zip file and nobody will have this problem again.  Until then, this is the easiest way.

Others have run into this problem and have posted the fix here.  Go to `buildlibs/DELABELLA-prefix/src/DELABELLA/delabella.cpp` and add `#include <time.h>` at the top of the file (without the quotes).

Once you do that, you should be able to run 'make' once more in the libraries build directory.  You should then continue on to the OpenVSP build directory and run cmake followed by make, etc.

No, I don't have a good site or book to recommend for this kind of knowledge.  It is mostly just a pile of stuff you pick up in pieces along the way.

To use a compiled language (say C/C++) you need to be able to work with a compiler and linker (this included when things aren't working).  On a non-trivial program, you need to know how to work with a build system.  On a complex program, you likely need to know how to work with a meta-build system (CMake).  In all situations, the predominance of books out there are written to tell you about things going right.  However, we spend all our time fixing things when they go wrong.

I don't know of any good resource that talks about C++ (language)/compilers/linkers/build/CMake as a stack of tools that work together -- and in particular how to diagnose and fix things when it is broken.

I call these 'toolchain problems' and you always have to fix your toolchain problems before you can set about real work.  I hate toolchain problems...

Rob

[Frank Sneeringer]

Amazing- thank you for the instructions and detailed explanations!  I was able to get everything built and running using the steps you identified.  

Thanks,

Frank